Николай Мохов

Security through obscurity - наихудший вариант. Передавайте пароль через защищённое соединение и не извращайтесь.
А дырка в том, что если кто-то может перехватить пароль, то он может с тем же успехом перехватить и кэш, этого будет достаточно для аутентификации.

Учётная запись, под которой работает пул приложений, в котором крутится ваш проект, должна иметь доступ к папке, куда нужно сохранять.

Можно. Если ваша команда состоит из одного человека (Вас), то:

Любой индивидуальный разработчик может создавать бесплатные или платные приложения с помощью Visual Studio Community.

Если более одного человека:

Visual Studio Community может использовать неограниченное число пользователей в организации в следующих случаях: в учебных аудиториях, для научных исследований или участия в проектах с открытым кодом.

Для всех прочих сценариев использования: В некорпоративных организациях Visual Studio Community могут использовать до 5 пользователей.

Источник: https://www.visualstudio.com/ru/vs/community/

1) Карта развития IT специалиста - CyberBionic Systematics
2) Курсы программирования – каталог
3) Руководство по ASP.NET MVC 5

Учите MVC + Web API + EF.

Все решил проблему:

private void BTN_News_Click(object sender, EventArgs e)
  {
      Form fn = new Form(); // Создаем динамически форму
      WebBrowser WEBNews = new WebBrowser(); // Создаем динамически браузер

      fn.Text = "Project - Новости"; //Устанавливаем название формы
      fn.FormBorderStyle = System.Windows.Forms.FormBorderStyle.FixedSingle; //Изменяем вид формы
      fn.StartPosition = FormStartPosition.CenterScreen; //Делаем форму по центру
      fn.Size = new Size(961, 600); //Устанавливаем размер формы

      WEBNews.Url = new Uri("http://toster.ru"); // Устанавливаем ссылку в браузер
      WEBNews.Dock = DockStyle.Fill; // Делаем браузер на все окно
      WEBNews.IsWebBrowserContextMenuEnabled = false; // Отключаем контексное меню браузера


      WEBNews.Show(); // Показываем браузер
      fn.ShowDialog(); // Показываем форму
      fn.Controls.Add(WEBNews); //Устанавливаем управление браузером
  }

Что-бы журнал не рос нужно делать сохранение лога.
То есть помимо зеркалирования, вы должны периодически сохранять базу данных и лог данных.
Сохранение лога остановит разрастание файла лога. При этом сразу файл не удастся уменьшить, так как конец файла будет использоваться sql-сервером. Когда вы через какое-то время второй раз сохраните лог, то sql-сервер даст вам уменьшить файл.
NB: для сохранения лога вам может понадобиться до 210 ГБ .

Цикл жизни статичных переменных определяется циклом жизни приложения - это уже один минус. При перезагрузках вашего приложения нужно будет их восстанавливать. В случае хранения идентификационных данных в Session, либо в Db - этим моментом управляете Вы, определяя цикл жизни этих данных.

Статичные переменные доступны только на одном сервере. Если Ваше приложение хостится на нескольких машинах, то опредленные переменные на одном сервере не доступны с другого.

Статичные переменные доступны всем, т.е. являются глобальными в рамках App Domain. Думаю, это тоже о многом говорит. Придется делать костыли, боюсь представить какие, по доступу к ним; как-то параллелить клиентские запросы. В то время, как для Session есть Session concurrency

В целом, если говорить об механизме Session, то скажу, что это понятные и широко распостраненные практики хранения идентификационных данных. Думаю, для большинства прикладных задач это вполне применимый подход. Если требуется больше безопасности, то уже смотрим в сторону Server-side для хранения состояния, например, в БД.

Функция "Publish" в VS это всего лишь деталь поставки. Формируй пакет поставки и разворачивай его на FTP.
Подмена файлов, будь то бинарных или текстовых плохая практика, можно что-нибудь отломать и потом долго мучиться восстанавливая предыдущие состояние. Каждая поставка содержит в себе изменения, значит должна быть присвоена версия, которая содержит определенный ченджлог, иначе через цать таких поставок начнется каша.

Опишу общий процесс поставки:

• вносятся финальные изменения в разработческой ветки, тестируются
  
• сливаются изменения разработческой версии с master, исправляются конфликты, тестируются
  
• собирается пакет поставки, содержащий все необходимые конфигурационные, бинарные и прочие файлы и т.д.. Пакет не должен содержать мусорных файлов. Присваивается пакету версия
  
• поставляется пакет на демонстрационный сервер. Если есть БД, то восстанавливается бэкап с продуктовой, либо максимально приближенный к последнему состоянию оригинальной. Применяются миграции.
  
• регистрируется приложение в IIS, тестируется
  
• поставляете пакет на продуктовое окружение
  
• если есть БД, то создается бэкап, применяются миграции
  
• разворачиваете пакет поставки
  
• переключаете IIS на использование поставленной версии
  

Это процесс, к которому мы пришли не сразу. Были и подмена файлов на продакшене и живая правка кода. Иногда это приводило к плачевным последствиям. Потом итеративно выработалась ручная процедура поставки, после для экономии времени эта процедура автоматизировалась. Сейчас самый продолжительным участком поставки является ручное приемочное тестирование на демонстрационном окружении. Автоматизированные приемочные тесты тоже есть - они прогоняются после сборки билда, но как и весь код они могут содержать ошибки, поэтому ручной прогон приемочных тестов исключать не решаемся.