Дмитрий Ковальский

В приложение я бы не лез. Если приложение хостится под IIS, то в настройках приложения есть раздел "Перенаправление протокола HTTP".

Сделайте HiddenFor для массива данных, а в JS свормируйте этот массив да запишите в hidden-поле.
Или у вас каждое поле имеет свое назначение, а не просто массив значений?

Материлы в сети по EF потому что он модный, простой и не требует знаний SQL. Если вы хорошо разбираетесь в архитектуре БД и знаете как писать оптимальные SQL-запросы с использованием индексов и query plan-ов. То советую, как сказал mletov писать через ADO.NET.
Мой личный подход - вызов хранимых процедур с помощью SQLConnection и Dapper, позволяющий использовать асинхронность(хотя по факту - псевдоасинхронность)

На первый взгляд - нет в силу специфики жизненного цикла WebForms.
Если чуть задуматься - событие onclick вызывается через Ajax? Тогда на клиентское событие onSuccess останавливайте что хотите.
Если событие вызывается синхронно - то в чем проблема? там страница перезагрузиться должна.

На слух конечно такое решать сложно. Причина почему из разных браузеров работает скореее всего связана с тем что авторизация в разных браузерах инициирует разные идентификаторы сессий и фактически каждый пользователь живет своей жизнью что есть правильно.
Касательно основной задачи - проблема чисто архитектурная. Большие тяжелые SQL запросы нельзя выполнять синхронно с действиями пользователя. Как хотите обходите, но формирование отчета не может и не должно реализовываться через синхронный запрос. И нет - async/await ситуацию не исправит. Хотите делать визуальное представление данных - оптимизируйте запрос,денормализовывайте таблицы, стройте индексы, в общем разбирайтесь по query-plan что работает долго.
Некоторые расчеты можно предрасчитать заранее(хотя это большая редкость, но бывает).

Опять же вопрос - нужно ли пользователю весь набор данных отчета или только некая выжимка(топ-10 от чего-то). Если нужен весь - то может стоит реализовать через выгрузку в файл и почту, а не в интерфейс системы.

У вас все option с одинаковым значением value. Так, для справки. А теперь мой ключевой вопрос - а что происходит в событии onchange, которое вы тут не показали? Предположим у вас есть option:selected. А что вы оттуда берете? название? Или вы хотите на клиентской стороне по названию из ViewBag достать еще какие-то значения? У меня для вас плохие новости - так делать нельзя и на 99% я уверен что невозможно. Это серверный объект.

Между разметкой и базой находится пропасть самого разного секретного кода, о котором вы, судя по постановке вопроса, предлагаете догадаться. В чем проблема?
Под отладкой код проверяли?
Приходит ли файл в handler запроса?
Проходит ли все слои бизнес-логики?
Каким методом пытается сохранить файл в базу? Через вызов хранимой процедуры или прямым Insert или вызовом через некую ORM-прослойку?
Почему вы не используете тип данных бд - байтовый массив?

Если ответ на первый вопрос - нет, то скорее всего правильный ответ дал cicatrix

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

А банальное не помогает?

routes.MapRoute(
                name: "SomeName",
                url: "somePath/example.ascx,
                defaults: new { controller = "Home", action = "Index");

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

Потому что обмен данными должен происходить через типизированные View и модели, а не ViewBag. Если приспичило использовать ViewBag - приводите к конкретным типам и обращайтесь к свойствам. В вашем случае так сделать не выйдет - потому что вы поленились создавать классы и воспользовались анонимными хаками. Как итог - слегка расшибли себе лоб.

Ваш POST запрос ждет входного параметра с именем data. Причем не знает откуда его брать.
1) Определитесь откуда будете извлекать данные и после того как определитесь - добавьте к параметру атрибут "FromBody" или "FromUri".

2) Затем правьте код самого запроса в котором отправите Ajax-запрос в котором будет Json объект структуры {'data':value}

Ваш запрос возвращает разметку, в которой боком/раком примешан Excel-файл.
Хотите понять что написали ересь? Напишите unit-тест на этот функционал и увидите проблему сразу.
Метод должен вернуть не View, а что-то вроде

return File(new MemoryStream(), "applicationd/vnd.ms-excel","fileName")

где вместо MemoryStream должен быть поток с содержимым файла.

Ну вы ASP и Basic то не смешивайте в одну кучу. Ну и так, к слову - ASP или ASP.NET? Разница очень очень не слабая. Почему вы решили что ошибка 500 это неправильное создание Dictionary? Как правило неправильное создание Dictionary приводит к ошибке этапа компиляции. Что показывает отладчик? Вы фактически сказали что написали 2 строчки кода и под вебом получаете ошибку 500. Посередине прорва пустого пространства, которое очень поможет решить вашу проблему.

Касательно архитектуры - тащить репозиторий до уровня контроллера это уровень второй четверти первого класса.
В идеале у вас должен быть уровень bl который проверит пользователя, выдаст ему сессионную куку или еще какой признак авторизации и вернет результат своей работы. В случае успеха - перенаправить куда-нибудь.
Касательно хеширования - SHA512 и какой-нибудь алгоритм засолки повеселее(не надо просто лепить соль сбоку).
Касательно уровня, на котором будет считаться хеш - все зависит от алгоритма авторизации. В вашем случае пахнуло EF и видимо стоит считать хэш на уровне обращения к репозиторию.
Если будете использовать хранимки - придется тащить пароль не трогая до самой бд и считать хеш там. Иначе появится логика извлечения всей базы пользователей с последующим поиском нужного, который не факт что найдется

Можете на onSuccess обновлять статус корзины.

Примечание. У вас нет единого стиля именования методов. AddCart - добавить корзину(???)
RemoveFromCart - Удалить из корзины.

var jsonData = File.ReadAllText(@"C:\Users\EvgenieL\Source\Repos\XO\XO\XO\bin\Debug\stats.json");

-Очень плохая, идея. Просто нереально плохой хард-код.

1)В блок catch добавить логирование(какое угодно, лучше использовать готовое решение вроде log4net или Nlog).
2)

var filePath = "stats.json";
var jsonData = File.ReadAllText(filePath);

Внимание вопрос - что и откуда вы здесь прочитаете?

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