Сергей

Мне например пока не хватает в Core работы с xsd схемами, но core 1.2 будет поддерживать .net standart library 2.0 так, что жду второго квартала 2017.
А так думаю можно почитать roadmap и посмотреть если из планируемого ничего не надо можно пробовать.

Классы StaffReports_ и StaffReports1_ не нужны пишем просто:

в class Staff

public virtual ICollection<Report> StaffReports { get; set; }

в class Report

public virtual ICollection<Staff> Interns { get; set; }

Дальше конфигурируем (см. void OnModelCreating(DbModelBuilder modelBuilder)

Не корректно сравнивать Create и Edit. К Edit вопросов не возникает имхо правильно и понятно.

result1.Except(result2).Union(result2.Except(result1));

Начинать писать в Response.OutputStream хоть что то.

Например при таком подходе клиент начинает получение файла сразу не дожидаясь окончания формирования архива.

Response.ContentType = "application/zip";
Response.AppendHeader("Content-Disposition", "attachment; filename=qqq.zip");
zipFile.Save(Response.OutputStream);

Response.End();

Следует учитывать, что рабочий поток будет занят и одновременно много файлов таким способом вы не отдадите.

Думаю если небольшой, новый проект в котором все данные лежат в базе, которая создается из EF Code First, то использовать репозиторий особой нужды нет. Но например если сегодня я беру данные из базы, а завтра планирую получать от api или какой нибудь NoSQL к которой нет ORM ? А может сущности, которыми оперирует моё приложение ну совсем не похожи на те что лежат в базе или "собираются" из нескольких источников ?
Не надо рассматривать репозиторий как обертку над EF.

Теперь пара замечаний:

вот так

public IEnumerable<Student> GetLogs()
{
      return context.Logs;
}

будет возвращен IQueryable и

GetLogs().Where(...)

будет ограничивать выборку с сервера.

Я бы с удовольствием посмотрел на страницу, где выводятся ВСЕ логи всех админов.
Но если она все же реально нужна я бы формировал её на клиенте так: получил AJAX запросом всех админов для каждого из них параллельно или последовательно запросил топ 100 мессаджей из логов (при необходимости следующие 100). Как следствие отталкиваться надо от UX тогда не будет желания писать репозиторий, который возвращает ВСЕ записи.

ЗЫ Пока ORM обеспечивает 100% данных и хватает мощности DB сервера все окей и без репозиториев, но при высокой нагрузке архитектура в корне другая и JOINы там выполняют отнюдь не DB сервера.

Попробуйте полностью снести студию и зависимости (https://github.com/Microsoft/VisualStudioUninstaller) и установить заново.

ASP.NET обычно state less - не хранит состояний. Приложение может быть остановлено/запущено в любой момент (например IISом) и все статические переменные потеряют свои значения. Если нужно именно хранение (persistence) то на выбор: файлы, базы данных, внешние кэши и т.д.

Счетчики правильнее хранить во внешнем кэше (например в redis).

В ASP.NET Gulp,Grunt, Browserify и так далее в основном используются для сборки Front End, что бы посмотреть готовый пример создайте новый проект ASP.NET Core.

Прикручиваются к существующему проекту они через npm (init, install). Использовать на сервере JavaScript + .NET особо смысла не вижу, но https://github.com/tjanczuk/edge при необходимости позволяет это сделать.

Я так понимаю вывод происходит из другого потока ? Тогда нужно синхронизировать потоки, что то типа

lock(некая глобальная переменная)
{
      var top = Console.CursorTop;
      var left = Console.CursorLeft;

      Console.CursorTop = 0;
      Console.CursorLeft = 0;
                              
      Console.Write(DateTime.Now.ToShortDateString());

      Console.CursorTop = top;
      Console.CursorLeft = left;
}

Прочитайте разницу между асинхнонностью (async\await) и многопоточностью (Task.wait())