Nik Faraday

Разобрался

При создании объект ClaimPrincipal, который принимает коллекцию объектов ClaimIdentity, все клаймы будут доступны в HttpContext. Когда вам нужно получить текущего пользователя и его клаймы используя HttpContext(Accessor), свойство User.Claims имеет все клаймы из всех объектов ClaimIdentity, который были использованы во время авторизации, по этому необязательно париться по поводу того, какой из объектов Identity вытянуть, а можно сделать выборку из всех клаймов

Логирование используется для записи ошибок в како-то файл. Например, если вы, при чтении из БД получили Exception, тогда вы обращаетесь к логеру и вызываете метод .LogError куда передает ошибку в виде строки. Эта строка будет записана в файл, откуда вы потом сможете это прочитать.

Встроенный интерфейс ILogger<> подойдёт вам вполне. Для настройки места, куда будут сохраняться логи, читайте конфигурацию логера, как его правильно настроить

Да, логи пишутся вручную

Решение:

<style type="text/css">
    th, td {
        white-space: unset;
    }
</style>

Работает только в том случае, если в тексте есть пробелы, если пробелов нет, тогда текст так и будет вылазить за пределы монитора)

Ну, вы движетесь в верном направлении. Создать статический класс в котором будут записаны данные конфигурации и просто вызывать его в тех местах, где это нужно. Если значение нужно только для его получения, можете позначить его readonly (Как вы уже сделали) или public Get; private Set; для свойств.

Ещё как вариант, можете попробовать использовать статические файлы конфигурации

UPD: пример ниже приведён для MVC архитектуры. API выдаёт данные, а не страницы. HttpGet - это получение информации от сервера. HttpPost - отправка информации на сервер. Основная разница в тому, что Post запрос имеет тело запроса, в котором можно передавать сложные структуры. Get запрос может передавать данные через строку запроса. Так же Get запросы кешируются, в отличие от Post запросов

HttpGet и HttpPost это два стандартных типа запроса. Так же есть HttpPut, HttpDelete и некоторые другие, основные из каких я перечислил сначала.

Разница между HttpGet и HttpPost в очень простом виде:
HttpGet - выдача сервером какой-то информации клиенту. Для примера, сервер отдаёт какую-то информацию, допустим, имя и логин пользователя, который зашёл на сайт, для того, что бы отобразить её где-то на странице. Так же Get запрос может отдавать целые страницы в формате HTML или других форматах. По факту, большинство страниц, что вы видите в браузере, включая эту, была передана нам в браузер от сервера путём выполнения запроса. Такая информация передаётся как HttpGet.

HttpPost - это отправка данных на сервер. Любая. Когда вы регистрируетесь на сайте, ваши данные отправляются с использованием HttpPost запроса. Когда вы делаете изменения личной информации, обновлённые данные отправляются как HttpPost, хотя в REST API принято такой запрос помечать как HttpPut. Тут речь идёт об отправке сложных структур данных, возможно, фотографий, видео, аудио, информации о местонахождении, контактные данные. Т.е., другими словами, когда вы сервер уведомляете о какой-то новой информации.

Стоит отметить, что редирект через url является HttpGet запросом. Если вы просто делаете переадресацию на какую-то страницу и в url передаёте id клиента (Для примера), что бы на странице сведений вывести его данные (Опять же, чисто для примера), это НЕ HttpPost запрос, это просто редирект. Потому что вы не обновляете никакую информацию. Когда вы обращаетесь к серверу с просьбой отрисовать/отрендрить страницу и передаёте туда id клиента, сервер отдаёт ответ на HttpGet запрос, который имеет разметку самой страницы.

Иными словами, HttpGet запрос, это то, когда сервер должен отрисовать новую разметку или вернуть какие-то данные в некотором формате (В основном JSON для API). Может выполняться несколько запросов, если вы во время регистрации на сайте отправляете данные, делается сначала HttpPost запрос с отправкой ваших данных, а потом HttpGet, когда у вас рендрится новая страница, на которую вас перекинуло.

Так же есть HttpPut - аналогия HttpPost, разницы нет почти никакой. Обычно используется для обозначения запроса на обновление информации, т.к. HttpPost должен работать как запрос на создание. Тот же пример HttpDelete - когда нужно удалить информацию.

Разобрался. Просто нужно ещё передать какое-то значение моделью и установить его как asp-for=... и тогда оно будет отображаться как стандартное

Разобрался методом "Научного тыка"

UPD: Проблема в том, что модель не может иметь типа enum. Вместо enum лучше поставить int и в сервисах преобразовать в этот тип. Если модель имеет enum и его значение хоть как-то пытается отправиться с фронта, сразу заходит null.

Разобрался сам, вот решение:

Проблема заключалась в том, что я пишу бэк-часть на asp.net. На разметке видно, что у меня кнопка для отправки данных на сервер имеет тип submit. Данный тип кнопки составит вам проблему, если вы захотите реализовать передачу данных через ajax в асинхронном режиме.

Далее объясню решение в том аспекте, как её понимаю я.
Кнопка типа submit сама по себе пытается отправить форму на сервер параллельно запуская ajax скрипт, а так же перегружается страницу. При перегрузке страницы, почему-то полностью пропадает блок success (Есть несколько причин на это), но блок error почему-то остаётся и потом ловит ответ от сервера (Если такой есть). Если же ответ от сервера будет, допустим, статус-код 200, то блока success нет и, логично, нечему просто перехватывать соответствующий ответ.

Решение проблемы заключается в том, что бы просто поменять тип кнопки с submit на button и повешать на кнопку событие ajax.

Небольшой код для считывания данных из файла и записи в список:

List<string> logs = new List<string>();
using(StreamReader reader = new StreamReader("fileName.txt"))
{
   while(!reader.EndOfStream)
   {
      logs.Add(reader.ReadLine());
   }
}

После этого, в списке logs будут все СТРОКИ из файла логов (Если он txt в данном случае). Далее, вы можете попробовать пройтись по этому списку и каждый элемент проверить с помощью метода класса String - IsContain который принимает аргументом строку. Если лог с ошибкой 100% имеет часть строки как Number of errors, вы можете сразу проверить сам лог

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

Или можно применить метод Split(' ') для разбиения строки по пробелу, после чего элемент с индексом 6 будет иметь количество ошибок с точкой в конце (Как часть строки). После этого применить метод TrimEnd('.'), т.е. удалить указанный символ с конца строки и потом этот элемент просто int.Parse(...), что на выходе даст вам целое число ошибок. Но, лучше используйте int.TryParse(...)

Технически, это сделать можно, но для этого вам нужно более детально изучить методы кодирования информации, вот одни из самых простых, которые вы можете реализовать:

• Алгоритм Шеннона — Фано
  
• Алгоритм Хаффмана
  
• Метод LZ77
  
• Метод LZSS
  
• Метод LZ78
  
• Метод LZW
  
• Метод Хэмминга (Сложный)
  

Данный класс, в котором вы пишете (Form1) является partial (Прочитайте об этом). Вторая часть этого класса инициализирует (Т.е. создаёт) всё компоненты (Кнопки, текстБоксы и т.д.) на форме. По этому, до того, как на форме появятся хоть какие-то элементы, их нельзя, т.к. технически, они не будут ещё существовать вообще (т.е. null)

Оказывается проблема была в отсутствии nullable связей между таблицами