Barada

Вариант Вадим Шандринов хорош. Если нет доступа к изменению схемы и тп можно использовать Cross-Database Queries . Сравнить там вставлено или ещё нет. Работать будет в разы медленнее чем вариант с триггером.

У ажуре нет smtp сервера из коробки. Я брал сторонний сервак тут https://www.zoho.com/mail/ и прикручивал его к домену.

Изучение часто требует погружения. Я использую отпуск за свой счёт для таких дел. После работы понять что хочешь, найти материал, построить план работ. Начать читать. Когда понимаешь что начинаешь упираться в несвежий мозг и отсутствие времени - берёшь недельку отпуска. За неделю берёшь барьер и опять продолжаешь в бекграунде почитывать/пописывать. Через полгода опять недельку.

Совет с изучением на работе trevoga_su - мудрый. Поэтому на работе надо искать лазейки для своих проектов. Предлагать начальству. Перейти в отдел, где более интересная тематика. Сменить работу наконец-то.

Не видел такого справочника. WebApi промежуточный вариант между MVC и WCF. Если серьёзно браться за разработку сервисов - надо читать WCF. Инфы полно. Если не серьёзно - считайте что WebApi это MVC, который заточен под раздачу json/xml а не html.

На будущее в ASP.NET vNext Api и MVC сведены под одну гребёнку. По этому поведение поменялось. Возможно стоит смотреть в будущее и заняться изучением vNext.

https://github.com/rareyman/HTMLBeautify нужен beautify
https://packagecontrol.io/packages/HTMLBeautify

Тут пара слов о статистике www.computerra.ru/90090/mobilnyie-prilozheniya-ubi...

Что я не так делаю? - Кривой код пишете.

Начать можно с Deferred как посоветовал akubintsev . Success колбек в скором времени не будет поддерживаться. Консоль разработчика + fiddler

www.tinymce.com эта штука норм кастомится. И новые функции легко добавляются. Документация в порядке

Я считаю что:

1-1) Проект не стоит делить на несколько веб-проектов. Стоит выделить бизнесс логику в отдельные "сервисы" и вынести их в отдельные проект. То есть веб проект - точка сбора, в которой референсы на Class Library сервисов. Тут поможет IoC. Но тогда все вьюхи и прочее будут в одном проекте. Но такие ресурсы как стили и js стоит держать в одном месте. Поэтому это не плохо.
1-2) Можно разделить на вебные подпроекты и деплоить их в виртульаные папки. То есть проект "форум" будет лежать отдельным приложением в виртуальной папке forum и будет доступен по пути domain.ru/forum

2) Аутентификация в первом варинте будет проходить в едином веб приложении и передевать через какой-нибудь IUserContext во все модули, где они будут решать допускать пользователя к той или иной фиче или нет.
Со вторым варинтом сложнее. Но так как домен 1 а ключом к аутентификации у нас является кука - можно будет докрутить до этого варианта.

3) 1 вариант - всё остаётся как есть. Второй вариант SessionServer и прочее. Отдельные машины шареного состояния.
4) Я считаю что без видимой надобновсти делить не надо. Но если она весит 70Гб, я бы разделил, так как таким объёмом сложно ворочить. Сбекапить и развернуть 70Гб - это несколько часов наверно? Под каждый атомарный сервис я бы выделил. Общие таблицы в общей базе.

В принципе я бы попробовал первый вариант. Так как он всё равно промежуточный перед вторым. Сделать модульную архитектуру. Разобраться с базой. Убрать лишние зависимости. Если этого мало то уже делить на подпроекты.

Проблема не в представлениях. Надо смотреть что происходит при сборке. Может NuGet каждый раз вытягивается. Может какие то initialize задачи виснут. Может стоит переставить студию. Огромные проекты на MVC собираются меньше чем за минуту. Или что-то в IIS.

MVC перспективнее. Стоит ещё знать о ASP.NET MVC 6 или vNext habrahabr.ru/post/242243 . Вероятно оно станет основной технологией.

Стоит отметить, что это не повод переносить логику во вьюхи!

В принципе всё верно сказал velnick .

От себя добавлю, что стоит ещё уделить внимание скринкастам. Когда голова не варит и буквы скачут, можно посмотреть . Плюсы скринкастов, что можно ещё увидеть как люди работают с IDE и прочими инструментами. Всегда можно найти что-то полезное.

Для начала вот это можно code.tutsplus.com/courses/30-days-to-learn-c
И по нарастающей на том же code.tutsplus.com или pluralsight.com/.

И мне больше нравится книга товарища Албахари www.amazon.com/C-5-0-Nutshell-Definitive-Reference... , чем Рихтер (хотя Рихтер хорош ). Она полегче для понимания.

Самый быстрый способ — репетитор (именно тет-а-тет, а не курсы). Из списка желаемых знаний видно, что нужен не 1, а несколько. Денег требует и требует большого усердства — всё равно 70% разбирать самому по книгам.