VanKrock

Этот вопрос очень странный, тут все зависит от вас, если вы хотите показать пользователю ошибку, то вы ее показываете, если не хотите то не показываете. То же самое и с логами, если вам нужна запись об этой ошибке то вы ее записываете в лог, если не нужна то не записываете. Нужно понимать как пользователь будет работать с вашим приложением, что он будет делать в случае возникновения ошибок, к кому он будет обращаться например, кто будет разбираться с этой ошибкой, и какая информация понадобится этому человеку для того чтобы выявить и устранить проблему.

Просто подумайте, а что и кому будет нужно. Если пользователь создает заявку, а у вас на обращении вылетело исключение, то нужно ли ему показать, что при регистрации прошла ошибка? Наверное нужно. Нужен ли ему подробрая информация о подключении и весь стек трейс? Наверное нет. Нужна ли подробная информация службе поддержки вашего приложения? Наверное да. Нужен ли службе поддержки стек трейс если они к коду доступа не имеют? Наверное не особо. А вот разработчику не помешает и стек трейс.

Так что смотрите на свой бизнес-процесс решения проблем с вашим приложением.

Лучше всего использовать IoC контейнеры, который будет управлять временем жизни контекста. Но если вы не используете контейнеры, то лучше создавать контекст на транзакцию.

Почему не слышно? Один React Native чего стоит

Я не совсем понял зачем вы второй запрос делаете через браузер? У OAuth есть несколько видов авторизации: клиентская (приложение должно уметь управлять браузером, например приложение под андроид или декстопный клиент) и серверная (например для сайта, чтобы авторизоваться на вашем сайте при помощи социальных сетей), есть еще но тут не важно. Итак у вас насколько я понял используется второй вид, потому как вы используете code.

Алгоритм работы клиентской авторизации
Отправляете get запрос

https://www.instagram.com/oauth/authorize/

указываете response_type=token
и вас редиректит на указанный redirect_uri, в ссылке будет ваш токен, его нужно будет получить из адреса
по истечению срока токена вы просто авторизуетесь снова и если есть куки, редирект произойдет сразу, можно даже не показывать окно браузера пользователю.

Алгоритм работы для серверной авторизации
Отправляете get запрос

https://www.instagram.com/oauth/authorize/

указываете response_type=code и redirect_uri=адрес_на_вашем_сервере_который_обрабатывает_code
пользователя средиректит на ваш сервер, то есть вам сервер придет get запрос в параметрах которого будет code
а дальше, получив код вы уже с сервера отправляете запрос к instagram указав code и полученный при регистрации secret_key, по истечению срока токена вы отправляете запрос так же с сервера указав refresh_token

https://ulearn.azurewebsites.net/ - видеокурсы от Уральского Федерального Университета + СКБ Контур, очень рекомендую, там видео и тестовые задания на проверку усвоения курса.

Книги:
Рихтер "C# via CLR",
Албахари "C# 5.0 Справочник" - "C# 5.0 in a Nutshell"
Албахари "C# 6.0 Карманный справочник" - "C# 6.0 Pocket Reference"

Ну и конечно документация msdn, а так же: github, stackowerflow и статьи на хабрахабре

права проверяйте на сервере на каждое действие, а когда отрисовываете, то просто ставите visible=none для недоступных пользователю элементов

using(SqlConnection sqlConnection = new SqlConnection(@"Data Source=(LocalDB)\v11.0;AttachDbFilename=|DataDirectory|\mail.mdf;Integrated Security=True"))
{
    using(SqlCommand cmd = new SqlCommand())
    {
    }
}

Никогда не используйте это
catch { }
Так вы помечаете код в блоке try, как бессмысленный и выполнится он или нет для вас не имеет значения

Если хотите передать исключение выше то пишите хотя бы

catch 
{
    throw;
}

когда будете работать c возвращаемым SqlDataReader его тоже надо будет освобождать.

Тут есть несколько вариантов, но если вам требуется держать соединение, посмотрите SignalR его можно использовать с ASP.NET WEB API или вы можете посмотреть в сторону NancyFx так же умеет работать в связке с SignalR

Ну сразу бросается в глаза, что вы не освобождаете стрим, этот как минимум потенциальная ошибка утечки памяти.

StreamReader openfile = new StreamReader(openFileDialog.FileName);

я бы заменил на

using (var openfile = new StreamReader(openFileDialog.FileName))

дальше, вы открыли файл и выполняете операции над ним в вечном цикле - это тоже потенциально опасно утечкой памяти, по мне лучше открыть файл, что-то с ним сделать и закрыть, то есть сделайте OpenFileDialog над объявлением, а создание стрима уже внутри.

SqlConnection и SqlCommand если не ошибаюсь тоже IDisposable их тоже следует обернуть в using, как и StreamReader - Ошибка с утечкой памяти скорей всего здесь.

И еще момент, я бы не стал делать цикл while(true), обычно я делаю private переменную _needStop и цикл while(!_needStop). Это для того, чтобы если понадобится, написать метод Stop()

Upd: немного посмотрел код ( используйте лучше FileStream вместо с StreamReader. Вот даже статью нашел metanit.com/sharp/tutorial/5.4.php FileStream вы хотя бы будете знать что там у вас с кодировками, а то всякое бывает.) хотя я в этом и не так уж уверен и со мной можно поспорить.

Когда вы выбираете статическую страницу, то у вас с index.php редиректит на эту страницу и на той странице в свою очередь редиректит на index.php, возникает циклический редирект. Если вы отображаете последние записи, то они отображаются сразу на index.php и никуда больше не редиректятся.

На сайте wordpress пишут, что если вы обновились с другой версии wordpress, то вам возможно нужен немного другой .htaccess

https://codex.wordpress.org/htaccess

Еще возможно что вас кидает со станицы с www на страницу без www и обратно или наоборот. Тогда нужно посмотреть, какой сайт указан в general settings

Я использовал у себя SpreadsheetLight
Устанавливается через Nuget, есть ньюанс, о котором хоть и написано написано в описании пакета, но я как-то упустил и долго мучался, требует установки (тоже через Nuget) OpenXml причем версии 2.0 (не 2.5) поэтому при установке OpenXml в Nuget выберите версию пакета 1.0 тогда установится OpenXml 2.0.

А какая у вас версия Windows? Если не ошибаюсь, то виртуализация поддерживается в версиях не ниже профессиональной.

Вообще вам подойдет string.IndexOf

Можно засунуть используемый язык пользователя в cookies если от пользователя не требуется работать на сайте с разными языками, если требуется, то как у вас. Названия полей записаны в lables? Можно задать их как переменные и запрашивать с сервера на том языке, на котором нужно. Названия полей хранить в базе. Если нужен будет новый язык, то просто добавите в базу и все. В общей переменная поля и переменная названия поля. Ну и на сервер передавать значения полей и выбранный язык.

У вас последняя это n-1?

Вы рассылаете одинаковое сообщение вк считает такое спамом