День пятьсот седьмой. #CSharp9
C# 9: На Пути к Поддержке Сценариев
Одной из определяющих характеристик языков «сценариев» является то, что им не нужен шаблон. Самой первой строкой файла могут быть объявления и операторы. Тогда как в C# или Java требуется некоторый метод Main, содержащийся внутри класса.

Мэдс Торгерсен из Microsoft предлагает реализовать эту возможность в C# 9. Операторы и функции верхнего уровня можно будет не включать в метод Main класса Program.

Компилятор C # в настоящее время понимает диалект языка, используемого для различных сценариев и интерактивных целей. На этом диалекте операторы могут быть написаны на верхнем уровне (без включения в тело методов), а невиртуальные члены могут быть написаны на верхнем уровне (без включения в объявление типа).

В настоящее время версия C# для сценариев используется не очень интенсивно, но Торгерсен предсказывает, что это изменится в будущем: «Помимо Try.NET, сценарии также набирают популярность в обработке данных и машинном обучении, и там сценарные языки выигрывают от непосредственного режима работы с живыми данными.»

Есть несколько сценариев реализации этого функционала, наиболее вероятный из которых следующий. Операторы будет разрешено размещать перед объявлением пространства имен. Любые такие операторы будут скомпилированы в функцию Main класса Program. Эта функция будет поддерживать асинхронные операции. Если несколько файлов имеют исполняемые операторы вне пространства имен, произойдет ошибка компилятора.

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

static void Main(string[] args)
static int Main(string[] args)
static Task Main(string[] args)
static Task<int> Main(string[] args)

Локальные функции разрешены с использованием обычного синтаксиса.

Другой сценарий. Функции могут быть объявлены в пространстве имен или глобально. По умолчанию они будут internal, хотя public также будет разрешён. Потребители увидят, что функция принадлежит непосредственно к пространству имен. Реализовано это будет через частичный класс, оборачивающий элементы как статические члены. Если какой-либо из членов верхнего уровня будет public, то и класс будет public и помечен таким образом, чтобы потребляющая сборка знала, что к членам этого класса можно будет обращаться напрямую.

Источник: https://www.infoq.com/news/2020/05/CSharp-9-Scripting/

День пятьсот восьмой. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
46. Знайте Свои Пределы
Ваши ресурсы ограничены. У вас есть только определённое количество времени и денег, чтобы выполнять свою работу, включая время и деньги, необходимые для обновления ваших знаний, навыков и инструментов. Вы можете работать только с определённым усердием, скоростью и не бесконечно. Ваши инструменты ограничены по мощности. Машины ваших пользователей тем более ограничены по мощности. Таким образом, вы должны знать ограничения своих ресурсов.

Как соблюдать эти ограничения? Знайте свои способности, знайте способности коллег, знайте свой бюджет и знайте свои инструменты. Особенно, как инженер-программист, вы должны знать пространственно-временную сложность ваших структур данных и алгоритмов, а также архитектуру и характеристики производительности ваших систем. Ваша задача - создать оптимальное сочетание программного обеспечения и систем.

Пространственно-временная сложность задается как функция O(f(n)), которая для n, определяющего объём входных данных, определяет объём затрачиваемых пространства или времени, при росте n. Основные уровни сложности для f(n) включают 1, log(n), n, nlog(n), n^2, 2^n и n!. Как видно из графика этих функций ниже, при росте n: O(log(n)) растёт намного медленнее, чем O(n) или O(nlog(n)), а они - намного медленнее, чем O(n^2) или O(2^n). Как говорит Шон Перент, для доступных значений n можно выделить три класса сложности: константная, линейная и бесконечная.

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

Ёмкость и скорость обращения к различным хранилищам варьируются на несколько порядков. Кэширование и последовательный доступ интенсивно используются на каждом уровне наших систем, чтобы скрыть эту разницу, но они работают только тогда, когда доступ предсказуем. При частых «промахах кэша» система будет тормозить. Например, чтобы в случайном порядке прочитать все байты жесткого диска, может понадобиться 32 года. А чтобы случайно просмотреть всю оперативную память – 11 минут. Случайный доступ непредсказуем. Исходя из этого, следует помнить, что повторный доступ к уже использовавшимся элементам и последовательный доступ практически всегда работают эффективно.

Алгоритмы и структуры данных различаются по тому, насколько эффективно они используют кэш. Например:
- Линейный поиск хорошо использует последовательный доступ, но требует O(n) сравнений.
- Двоичный поиск отсортированного массива требует только O(log(n)) сравнений.
- Поиск по дереву van Emde Boas также требует O(log(n)) сравнений и при этом эффективно использует кэш.

Как выбрать? Только измеряя. Линейный поиск наиболее выгоден для небольших массивов, однако существенно проигрывает при увеличении размера. Алгоритм van Emde Boas выигрывает благодаря предсказуемому доступу к данным.

Источники:
- https://www.oreilly.com/library/view/97-things-every/9780596809515/ Автор оригинала – Greg Colvin
- https://habr.com/ru/post/188010/

День пятьсот девятый. #CSharp9
C# 9: Улучшения Частичных Методов для Генераторов Кода
Генераторы исходного кода в C# 9 позволят расширениям компилятора проверять код, а затем вводить дополнительный исходный код во время компиляции. Этот внедрённый код затем включается в ту же компилируемую сборку. Чтобы упростить эту возможность, Microsoft снимает большинство ограничений с частичных методов.

Частичные методы были введены в 2007 году, чтобы расширить возможности генераторов исходного кода. Основная идея в том, что в сгенерированном коде есть заглушки в виде частичных методов. Если разработчик хочет изменить поведение кода, то он может реализовать частичный метод. В противном случае частичный метод, как и любые его вызовы, удаляются.

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

В настоящее время частичные методы имеют несколько ограничений:
- должны возвращать void,
- могут иметь параметры in или ref, но не out,
- неявно являются закрытыми, и поэтому не могут быть виртуальными,

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

[RegexGenerated("(dog|cat|fish)")]
public partial bool IsPetMatch(string input);

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

При этом получится вторая категория частичных методов, которые не будут удаляться из кода, но не будут ограничены в том, что вы можете с ними делать. Чтобы различать две категории, предлагается два основных правила:
1. Если partial указан с явным модификатором доступа (public, private и т.д.), то метод должен быть реализован, может возвращать значения и может иметь параметры out.
2. Если partial указан без явного модификатора доступа, то метод может быть удалён из кода, должен возвращать void и не может иметь out параметров.

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

Другие члены класса, такие как частичные свойства, частичные конструкторы и частичные операторы, находятся на рассмотрении для C# 10. Поскольку они не являются строго необходимыми для расширения возможностей генераторов кода, вводить их в C# 9 не является критически важным.

Источник: https://www.infoq.com/news/2020/06/CSharp-9-Partial-Methods/

День пятьсот десятый. #ЗаметкиНаПолях
Указатели в C#
Несмотря на то, что в C# 7 добавлены достаточно богатые возможности передачи типов значений по ссылке, иногда требуется использовать небезопасный код и канонические указатели.
Указатель - это переменная, которая содержит адрес хранения значения в памяти. В C# указатели могут быть объявлены только для типов значений.
Указатели объявляются с помощью символа «разыменования» *:

int *p;

либо

int* p;

Это объявление устанавливает в переменную p указатель на адрес начала целого числа в памяти (4 байта).

Оператор & возвращает адрес хранения переменной. В коде ниже p будет указывать на адрес хранения целого числа i:

int i = 5;
int *p;
p = &i;

Если при этом задать

*p = 10;

Это изменит и значение i на 10.

Указатели могут быть объявлены для структур, как в следующем примере:

Coords x = new Coords();
Coords *y = &x;

Затем можно использовать объявленный указатель y для доступа к открытому полю структуры x (например, z):

(*y).z

либо через ->:

y -> z

Небезопасный Код
Основная проблема с использованием указателей в C# в том, что CLR управляет процессом сбора мусора в фоновом режиме. Освобождая память, сборка мусора может изменить расположение объекта без предупреждения и испортить указатель на него. Это может как поставить под угрозу работу программы, так и повлиять на целостность других программ. Из-за этих проблем использование указателей ограничено кодом, который программист явно помечает как «небезопасный» (unsafe).

Чтобы решить эту проблему, можно объявить указатель в выражении fixed. Это «фиксирует» расположение объекта по указателю, поэтому сборка мусора не ломает указатель. Оператор fixed может использоваться только в контексте небезопасного кода. При этом типы значений, объявленные в небезопасном коде, автоматически фиксируются, их не нужно использовать в выражениях fixed.

Указатель может быть объявлен для массива:

int[] a = {4, 5};
int *b = a;

В этом случае b указывает на ячейку памяти с первым элементом массива a. Элементы также должны быть типа значения. Ниже показано, что можно проходить по значениям массива с помощью указателя:

public static void Main() {
  int[] a = {4, 5};
  changeVal(a);
  Console.WriteLine(a[0]);
  Console.WriteLine(a[1]);
}
public unsafe static void changeVal(int[] a) {
  fixed (int *b = a) {
    *b = 5;
    *(b + 1) = 7;
  }
}

Источник: https://codewithshadman.com/csharp-pointer/

День пятьсот одиннадцатый. #CSharp9
C# 9: Упрощённая Проверка Параметров на Null
Эта функция конкурировала с несколькими другими предложениями: атрибуты, флаги компилятора и т.п. Все они были отброшены в пользу узкоспециализированного предложения, которое уменьшает объем кода проверки параметра на null до одного символа.

Оператор ! может быть расположен после любого идентификатора в списке параметров, что заставит компилятор C# выдать стандартный код проверки на null для этого параметра:

void M(string name!) {…}

будет скомпилировано как:

void M(string name) {
  if (name is null)
     throw new ArgumentNullException(nameof(name));
  …
}

Правила довольно очевидны:
1. Проверки на null вводятся в начале функции перед любым другим кодом и выполняются в том же порядке, что и параметры в сигнатуре функции.
2. Выполняется именно проверка на равенство null, игнорируя любые перегрузки оператора ==.
3. В конструкторе проверка произойдет после вызова конструктора базового класса. В Microsoft рассматривали возможность проверки параметров перед вызовом конструктора базового класса. Это всегда было разрешено в .NET и, возможно, это предпочтительнее. Тем не менее, синтаксис C# не позволяет этого, и было решено не генерировать код, который не может быть воссоздан без использования этой функции.
4. В итераторе проверка всегда выполняется при первоначальном вызове.
5. Ошибки компиляции возникнут в случаях:
- проверки параметра, который не может быть null (например, struct, unmanaged),
- проверки параметра метода без реализации (например, абстрактного или частичного метода, делегата, метода интерфейса),
- проверки out параметра.
6. Предупреждения компилятора возникнут в случаях:
- Проверки явно обнуляемого параметра (string? x!). Предположительно это не приводит к ошибке, чтобы позволить подклассу быть более строгим, чем базовый класс.
- Проверки необязательного параметра со значением null по умолчанию.

Предполагаются следующие сценарии для дженериков:

void M<T>(T value!) { } // OK
void M<T>(T value!) where T : struct { } // ошибка
void M<T>(T value!) where T : unmanaged { } // ошибка 
void M<T>(T value!) where T : notnull { } // OK
void M<T>(T value!) where T : class { } // OK
void M<T>(T value!) where T : SomeStruct { } // ошибка 
void M<T>(T value!) where T : SomeClass { } // OK

Недостаток этого подхода в том, что он не поддерживает проверку свойств, поскольку параметр value не задаётся явно, а только подразумевается. Пользователи предложили обходной путь, в котором оператор ! применяется к ключевому слову set:

public Foo Foo {get; set!;}
public Bar Bar {
  get { return bar; }
  set! { bar = value; DoSomethingElse(); }
}

Источник: https://www.infoq.com/news/2020/06/CSharp-9-Null/

День пятьсот двенадцатый. #Оффтоп
5 Качеств Хорошего Программиста
Сегодня предложу вашему вниманию видео от классового врага (шутка) джависта и блогера Сергея Немчинского «5 качеств хорошего программиста». Он избрал несколько необычный подход: качества, которые определяют хорошего программиста с точки зрения бизнеса, как хорошего работника, творца, «решателя проблем». Если спросить любого из вас, то вряд ли вы попадёте хотя бы в 2 качества, указанные в видео. Итак:
1. Интеллект
2. Страсть
3. Настойчивость
4. Любовь к новому и самообучению
5. Гибкость мышления
По-моему, интересная точка зрения. Строго говоря, многие из пунктов пересекаются между собой или связаны, а то и противоречат друг другу. Впрочем, не буду пересказывать, в видео Сергей объясняет каждое из качеств более подробно.
Что скажете? Обсудим в чате?

День пятьсот тринадцатый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
47. Планируйте Свой Следующий Коммит
Я подошёл к трем программистам и спросил, что они делают. «Я делаю рефакторинг этих методов», - ответил первый. «Я добавляю параметры к этому методу действия», - сказал второй. Третий ответил: «Я работаю над этой проблемой пользователя».

Может показаться, что первые двое были поглощены деталями своей работы, тогда как только третий мог видеть более общую картину, и понимал, что он делает. Однако, когда я спросил, когда они закончат и какие изменения сохранят в репозитории, картина резко изменилась. Первые двое достаточно чётко ответили, какие файлы будут задействованы, и что они закончат примерно через час. Третий ответил: «Ну, думаю, что я закончу через пару дней. Скорее всего, я добавлю несколько классов и как-нибудь изменю эти сервисы».

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

Третий программист не смог разобрать проблему на части и работал над всеми аспектами одновременно. Он понятия не имел, что для этого потребуется, в основном занимаясь «предположительным программированием», то есть надеясь в какой-то неопределённый момент в будущем получить что-то работающее, подходящее для коммита. Скорее всего, код, написанный в начале этого длинного сеанса, будет плохо согласован с решением, которое появилось в конце.

Что бы сделали первые два программиста, если бы их задачи заняли более двух часов? Понимая, что они взяли на себя слишком много, они, скорее всего, отбросили бы свои изменения, определили более мелкие задачи и начали сначала. Для продолжения работы не хватало бы сфокусированности, что привело бы к «предположительному программированию» и сохранению в репозитории несогласованного кода. Вместо этого лучше пожертвовать текущими изменениями, но сохранить понимание процесса.

Третий программист может продолжать гадать и отчаянно пытаться собрать все свои изменения во что-то, что может быть сохранено. В конце концов, жалко же выбрасывать кучу изменений, которые уже сделаны, и начинать сначала, не так ли? К сожалению, такая практика приводит к сохранению в репозитории непродуманного кода, которому не хватает чёткой цели.

Иногда даже программисты, сосредоточенные на фиксации сделанных изменений, могут не находить полезного решения, которое по их прикидкам может быть завершено за пару часов. В таком случае можно на время перейти в режим предположений, поиграть с кодом, при этом выбрасывая изменения всякий раз, когда какая-то новая идея возвращает вас в нужное русло. Даже у таких, казалось бы, непродуктивных сессий есть цель: лучше узнать код, чтобы найти способ решить задачу продуктивно.

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

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Dan Bergh Johnsson

День пятьсот четырнадцатый. #ЗаметкиНаПолях
.NET Core или .NET Framework для Серверных Приложений
На данный момент существуют две реализации .NET для серверных приложений: .NET Framework и .NET Core. Они используют одни и те же компоненты, между ними возможен обмен частями кода. Однако есть и фундаментальные различия.

Использование .NET Core
1. Для создания новых кроссплатформенных приложений.
.NET Core поддерживается в Windows, Linux и macOS как для работы приложений, так и на стадии разработки. Visual Studio предоставляется для Windows и macOS.

2. В микросервисной архитектуре.
Архитектура микросервисов позволяет сочетать различные технологии через сервисы. Например, можно смешивать сервисы, разработанные на .NET Framework, Java, Ruby и других технологиях.

3. При использовании Docker-контейнеров.
Контейнеры обычно используются в сочетании с архитектурой микросервисов. Также их можно использовать в качестве окружающей среды для работы веб-приложений или сервисов, соответствующих любому архитектурному шаблону. .NET Framework можно использовать в контейнерах Windows, а модульность и легковесность .NET Core делают его лучшим выбором при использовании контейнеров. Поскольку он кроссплатформенный, возможно, например, развёртывать серверные приложения в контейнерах Linux.

4. В высокопроизводительных и масштабируемых системах.
Когда системе требуется наилучшая производительность и масштабируемость, лучше всего подойдут .NET Core и ASP.NET Core. Производительность и масштабируемость особенно актуальны для архитектур микросервисов. В ASP.NET Core системы работают с гораздо меньшим количеством серверов/виртуальных машин, что экономит затраты на инфраструктуру и хостинг.

5. Если в приложениях используются различные версии .NET.
.NET Core поддерживает параллельную установку различных версий среды выполнения на одном компьютере. Это позволяет использовать несколько служб на одном сервере, каждая из которых имеет свою собственную версию .NET Core, а также снижает риски и экономит деньги.

Использование .NET Framework
.NET Core предлагает значительные преимущества для новых приложений, однако .NET Framework продолжает оставаться естественным выбором для многих существующих сценариев. В большинстве случаев не нужно переносить существующие приложения в .NET Core. Вместо этого рекомендуется использовать .NET Core при расширении существующего приложения, например создать новый веб-сервис в ASP.NET Core.

Сторонние библиотеки быстро переходят на .NET Standard, обеспечивающий совместное использование кода во всех реализациях .NET, включая .NET Core. С .NET Standard 2.0 это еще проще:
- API существенно расширен.
- Введён режим совместимости с .NET Framework, который позволяет проектам .NET Standard и .NET Core ссылаться на библиотеки .NET Framework.

.NET Framework стоит использовать только в тех случаях, когда библиотеки или пакеты NuGet используют технологии, которых нет в .NET Standard или .NET Core. Кроме того, некоторые технологии .NET Framework недоступны в .NET Core:
- ASP.NET Web Forms
- ASP.NET Web Pages
- Сервисы WCF.
- Службы Workflow и службы данных WCF.

Источник: https://docs.microsoft.com/en-us/dotnet/standard/choosing-core-framework-server

День пятьсот пятнадцатый. #юмор

День пятьсот шестнадцатый. #Оффтоп
Старший программный менеджер Майкрософт, Мэдс Кристенсен, выпустил подборку расширений для Visual Studio, назвав её Basic Essentials.

Пакет расширений - это одно расширение, которое установит в Visual Studio одно или несколько других расширений. Пакет расширений очень легко сделать (вот руководство). Примеры пакетов расширений: Web Essentials и Extensibility Essentials. Эти два пакета предназначены для очень специфических типов разработки и не подходят ни для каких других.

Пакет от Мэдса полезен для всех разработчиков. Это самые базовые вещи, облегчающие вашу жизнь:
1. Add New File
Расширение для простого добавления новых файлов в любой проект. Просто нажмите Shift+F2, чтобы создать пустой файл в выбранной папке или в той же папке, что и выбранный файл.
2. Editor Enhancements
Предоставляет дополнительные функции, такие как HTML и URL-кодирование, преобразования и сортировка выделенного текста.
3. EditorConfig Language Service
Помогает разработчикам определять и поддерживать согласованные стили кодирования между различными редакторами и IDE.
4. File Icons
Добавляет значки для файлов, которые не распознаются обозревателем решений.
5. Insert GUID
Вставляет новый GUID, через меню «Правка» или по нажатию CTRL+K,Пробел.
6. Learn the Shortcut
Показывает, как выполнить то же действие, используя только клавиатуру. Отображает в окне Output сочетание клавиш для любой команды, которую вы выполняете, чтобы помочь вам узнать, какие сочетания клавиш вам нужны больше всего.
7. Markdown Editor
Полнофункциональный редактор разметки по типу GitHub с предварительным просмотром в реальном времени и подсветкой синтаксиса.

Исходный код Basic Essentials доступен тут. Это просто файл JSON, созданный определённым образом.

Источник: https://devblogs.microsoft.com/visualstudio/delivering-on-a-promise-the-essential-extension-pack/

День пятьсот семнадцатый. #Оффтоп
Сегодня расскажу про ещё один плейлист на ютуб. На канале Microsoft Visual Studio в серии Visual Studio Toolbox вышел довольно хороший и актуальный обзор Entity Framework Core.
Почему-то авторы решили не выделять эту серию в отдельный плейлист, поэтому я сделал это сам: Плейлист по Entity Framework Core.

Эпизоды серии делятся на 2 части.

Основные понятия:
1. Работа с существующей БД.
2. Отслеживание изменений.
3. Основные запросы.
4. Запросы связанных данных и использование проекций.
5. Обзор CUD (создание/обновление/удаление) в CRUD.
Код примеров из этой части доступен на GitHub.

Расширенное использование:
1. Производительность.
2. Модели представления.
3. Настройки.
4. Построение модели.
5. Глобальные фильтры запросов.
6. Конфликты изменений.
7. Устойчивость подключения.
8. Вычисляемые столбцы.
9. Управление событиями отслеживания.
10. Маппинг полей.
В этой части вышли ещё не все видео, буду добавлять их в плейлист по мере выхода.
Код примеров из этой части также доступен на GitHub.

День пятьсот восемнадцатый. #ЧтоНовенького
dotnet-monitor
При запуске приложений dotnet в различных средах может быть трудно собирать диагностическую информацию (например, логи, трассировки, дампы процессов). dotnet-monitor - это экспериментальный инструмент, который призван упростить этот процесс, предоставляя согласованный REST API независимо от того, где запущено ваше приложение.

REST API предоставляет две группы URL:
- https://localhost:52323 – для доступа ко всем конечным точкам (настраивается через параметр --urls);
- https://localhost:52325 – для доступа к конечным точкам метрики (настраивается через параметр --metricUrls).

dotnet-monitor доступен через два механизма распространения:
- как глобальный инструмент .NET Core,
- как образ контейнера доступный через реестр контейнеров Microsoft (MCR).

Установить инструмент можно, используя следующую команду:

dotnet tool install -g dotnet-monitor --add-source https://dnceng.pkgs.visualstudio.com/public/_packaging/dotnet5-transport/nuget/v3/index.json --version 5.0.0-preview.1.*

После установки запустить dotnet-monitor можно с помощью следующей команды:

dotnet monitor collect

Конечные точки
REST API утилиты предоставляет следующие конечные точки, которые можно вызвать, например, через PowerShell:

PS> Invoke-RestMethod https://localhost:52323/processes

/processes

Возвращает список целевых процессов, доступных через dotnet-monitor.

/dump/{pid?}

Возвращает дамп целевого процесса. Особенность его в том, что его нельзя проанализировать на машине с ОС/архитектурой, отличной от той, где он был захвачен.

/gcdump/{pid?}

Возвращает дамп GC целевого процесса. В отличие от дампа процесса, он может быть проанализирован в Visual Studio и perfview независимо от платформы, на которой он был захвачен.

/trace/{pid?}

Возвращает трассировку целевого процесса по умолчанию за 30 секунд. Диагностические данные, присутствующие в трассировке, можно настроить через параметры запроса:
1. durationSeconds – длительность захвата в секундах,
2. profile – профили для захвата через запятую:
- cpu – профилировка ЦП,
- http – события старта/остановки запросов в ASP.NET Core,
- logs – логи из EventSourceLogger,
- metrics - метрики из EventCounters.

/logs/{pid?}

Будет транслировать логи целевого процесса по умолчанию в течение 30 секунд.

/metrics

Вернёт снимок метрик среды выполнения и ASP.NET Core.

dotnet-monitor в настоящее время используется в экспериментальном режиме до выпуска .NET 5. В этот период в Майкрософт хотят оценить полезность инструмента и решить, что делать с ним дальше. Вы можете попробовать его и описать проблемы или просто следить за ходом проекта в репозитории GitHub.

Источник: https://devblogs.microsoft.com/dotnet/introducing-dotnet-monitor/

День пятьсот девятнадцатый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
48. Большие Объёмы Взаимосвязанных Данных Должны Храниться в Базе Данных
Если ваше приложение обрабатывает большой, постоянный и взаимосвязанный набор данных, не стесняйтесь хранить их в базе данных. В прошлом СУБД были дорогими, дефицитными, сложными и громоздкими монстрами. Это больше не так. В настоящее время системы СУБД легко найти (вполне вероятно, что на вашем компьютере уже используется одна или две). Некоторые очень мощные СУБД, такие как MySQL и PostgreSQL, доступны как ПО с открытым исходным кодом, поэтому стоимость покупки больше не является проблемой. Более того, так называемые встроенные системы баз данных могут быть использованы в виде библиотек непосредственно в вашем приложении, практически не требуя настройки или управления. Две наиболее известные из них - SQLite и HSQLDB.

Если данные вашего приложения больше размера отведённой оперативной памяти, индексированная таблица в СУБД будет работать на несколько порядков быстрее, чем использование коллекций в памяти. Современные базы данных могут легко расти с вашими потребностями. При соблюдении слабой связанности модулей в приложении вы можете при необходимости расширить масштаб встроенной базы данных до более крупной СУБД или перейти от СУБД с открытым кодом к более мощной системе.

Как только вы освоите SQL, написание приложений, использующих БД, не будет вызывать проблем. После того, как вы сохраните свои правильно нормализованные данные в базе, их легко извлекать с помощью понятных SQL-запросов; нет необходимости писать какой-либо сложный код. Аналогично, простая команда SQL может выполнять сложные изменения данных. А использование систем ORM, вроде Entity Framework, делает работу с СУБД невероятно простой. Во многих случаях не потребуется даже глубокого изучения SQL.

Другое преимущество использования СУБД заключается в обработке отношений между элементами данных. Вы можете описать ограничения согласованности данных декларативным способом, избегая риска появления висячих указателей, которые вы получите, если забудете обновить связанные данные. Например, вы можете указать, что если пользователь будет удалён, то сообщения, отправленные этим пользователем, также должны быть удалены.

Вы также можете создавать эффективные связи между объектами, хранящимися в базе данных, в любое время, просто создав индекс. Нет необходимости выполнять обширный рефакторинг полей классов. Кроме того, использование БД позволяет нескольким приложениям безопасно обращаться к вашим данным.

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

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Diomidis Spinellis

День пятьсот двадцатый. #DotNetAZ
Dotnet A-Z. 1
В этой серии постов рассмотрим наиболее распространённые понятия в .NET в алфавитном порядке.

АОТ - ahead-of-time компилятор.
Подобно JIT-компилятору, этот компилятор также переводит IL в машинный код. Но в отличие от JIT-компиляции, AOT-компиляция происходит перед выполнением приложения и обычно выполняется на другом компьютере. Поскольку цепочки инструментов AOT не компилируются во время выполнения, им не нужно минимизировать время, затрачиваемое на компиляцию. Это означает, что они могут тратить больше времени на оптимизацию. Т.к. контекстом AOT-компиляции является всё приложение, компилятор AOT также выполняет межмодульное связывание и анализ всей программы, что означает переход по всем ссылкам и создания одного исполняемого файла.

ASP.NET
Платформа разработки веб-приложений, в состав которой входит: веб-сервисы, программная инфраструктура и модель программирования. Исходная реализация ASP.NET входит в состав платформы .NET Framework.
Иногда ASP.NET - это общий термин, который относится к обеим реализациям ASP.NET в .NET Framework и .NET Core. Значение, которое этот термин несёт в конкретном случае, определяется контекстом.

ASP.NET Core
Кроссплатформенная, высокопроизводительная реализация ASP.NET с открытым исходным кодом, построенная на .NET Core.

Assembly (сборка)
Сборка - это логическая группировка одного или нескольких управляемых модулей или файлов ресурсов. Это самая маленькая единица с точки зрения многократного использования, безопасности и управления версиями. Управляемые модули сборки могут быть файлами dll или exe в зависимости от типа проекта. Файл с исходным кодом, написанном на любом языке поддерживаемым .NET, с помощью соответствующего компилятора, компилируется в сборку. Сборка может включать в себя типы, такие как интерфейсы, классы, структуры, перечисления и делегаты.

Источник: https://docs.microsoft.com/en-us/dotnet/standard/glossary

День пятьсот двадцать первый. #ЧтоНовенького
AWS Поможет Пользователям Перенести Приложения с .NET Framework на Core
Amazon Web Services (AWS) представили инструмент, помогающий пользователям их облачных сервисов перенести свои приложения с .NET Framework на .NET Core.

Porting Assistant for .NET работает на Linux, сканирует приложения и генерирует оценку совместимости с .NET Core, помогая ускорить переход на новую платформу.

«Перенос приложений с .NET Framework на .NET Core помогает клиентам воспользоваться преимуществами производительности, экономии средств и надежностью экосистемы Linux. Однако это может потребовать значительных усилий», - говорят в AWS, - «Владельцам приложений нужно тратить драгоценное время на выявление зависимостей и API, несовместимых с .NET Core, и на оценку количества требуемых на перенос усилий. Porting Assistant для .NET быстро сканирует приложения .NET Framework для выявления несовместимостей с .NET Core, находит известные замены и генерирует подробную оценку совместимости. Это сокращает ручные усилия, необходимые для модернизации ваших приложений под Linux».

Хотя существует несколько утилит Framework-to-Core, в том числе и от Microsoft, AWS заявляют, что их инструмент отличается тем, что способен полностью оценить дерево зависимостей пакетов в дополнение к основным функциям, таким как обнаружение несовместимых API. Кроме того, по словам AWS, в качестве отправной точки используются файлы решений, что упрощает оценку монолитных решений, включающих множество проектов. Это устраняет необходимость анализа и агрегирования информации об отдельных двоичных файлах.

При портировании приложений с .NET Framework разработчикам необходимо искать совместимые пакеты NuGet и обновлять ссылки на эти пакеты в файлах проекта приложения, которые также должны быть обновлены до формата файлов проекта .NET Core. Кроме того, им нужно искать API для замены, поскольку .NET Core содержит лишь часть API, доступных в .NET Framework. По мере продвижения процесса портирования разработчикам приходится разбираться с длинными списками ошибок и предупреждений компиляции, чтобы определить наиболее приоритетные места изменений для продолжения переноса. Излишне говорить, что это сложно, и дополнительные проблемы могут стать сдерживающим фактором для клиентов с большим портфелем приложений.

В качестве цели инструмент использует .NET Core 3.1, который в итоге будет обновлён до .NET 5. Исходные приложения должны быть на .NET Framework 3.5 или выше. Инструмент работает только для сервисов Windows и приложений ASP.NET.

Источник: https://visualstudiomagazine.com/articles/2020/07/02/aws-net-porting-tool.aspx

День пятьсот двадцать второй. #ЗаметкиНаПолях
Настройка ASP.NET Core.
1. Класс Program. Начало
Класс Program содержит метод Main, который является точкой входа приложений ASP.NET Core. Метод Main аналогичен методу Main консольных приложений, т.к. все приложения .NET Core по сути являются консольными приложениями. Веб-приложения, такие как MVC или приложения Razor Pages строятся поверх консольного приложения.

Основное назначение класса Program - настройка инфраструктуры приложения.

Класс Program создаёт веб-хост при запуске. Затем он настраивает ведение журнала, контейнер внедрения зависимостей (DI), систему конфигурации, веб-сервер Kestrel, интеграцию с IIS и т. д. Он также добавляет сервисы инфраструктуры в контейнер DI, чтобы мы могли их использовать. Код для класса программы генерируется автоматически, чего в большинстве случаев достаточно.

Что такое веб-хост (Web Host)?
Веб-хост отвечает за запуск приложения и его выполнение. Он создается при запуске приложения, создаёт сервер, который прослушивает HTTP-запросы, настраивает конвейер запросов (он же конвейер промежуточного ПО). Кроме того, он устанавливает DI-контейнер, в который добавляются сервисы. Управление временем жизни сервисов также является задачей веб-хоста.

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

public class Program {
  public static void Main(string[] args) {
    CreateWebHostBuilder(args).Build().Run();
  }

  public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
      .UseStartup<Startup>();
}

В методе Main создаётся строитель веб-хоста в отдельном статическом методе CreateWebHostBuilder, который отвечает за сего создание и применение настроек, а затем вызывается метод строителя Build, возвращающий веб-хост, и метод веб-хоста Run, запускающий веб-хост.

CreateDefaultBuilder создаёт строитель по умолчанию:
1. Устанавливает корень содержимого в Directory.GetCurrentDirectory.
2. Загружает дополнительную конфигурацию из:
- appsettings.json,
- appSettings.{Имя_Среды}.json,
- секретных данных пользователя,
- переменных среды,
- аргументов командной строки.
3. Включает ведение журнала.
4. Устанавливает DI-контейнер.
5. Настраивает Kestrel в качестве веб-сервера.
6. Настраивает необходимые сервисы в конвейере промежуточного ПО.
7. Интегрирует выполнение Kestrel в IIS.

Веб-хост создан и настроен, но перед сборкой и запуском необходимо дополнительно настроить приложение. Это делается в классе Startup (название класса по соглашению). Строителю веб-хоста сообщается имя класса настройки, используя обобщённый метод UseStartup.

Источник: https://www.tektutorialshub.com/asp-net-core/asp-net-core-program-cs/

День пятьсот двадцать третий. #ЗаметкиНаПолях
Настройка ASP.NET Core.
2. Класс Program. Продолжение
Рассмотрим подробнее, что делает метод CreateDefaultBuilder. Его код можно найти на GitHub.

1. Установка корня содержимого

builder.UseContentRoot(Directory.GetCurrentDirectory());

Устанавливает текущий каталог как корень приложения.

2. Загрузка конфигурации
Из аргументов командной строки используя метод UseConfiguration. Остальные настройки загружаются внутри метода ConfigureAppConfiguration, которому передаётся лямбда-функция, принимающая контекст хоста HostBuilderContext и строитель конфигурации, реализующий IConfigurationBuilder. Конфигурация добавляется, вызовами методов строителя:
- appsettings.json и appSettings.{Имя_Среды}.json через вызовы AddJsonFile,
- секретные данные пользователя через AddUserSecrets,
- переменные среды через AddEnvironmentVariables.

3. Ведение журнала

ConfigureLogging((hostingContext, logging) => {
  logging.AddConfiguration(
    hostingContext.Configuration.GetSection("Logging"));
  logging.AddConsole();
  logging.AddDebug();
  logging.AddEventSourceLogger();
})

Здесь считываются правила ведения журнала из файла конфигурации, указанные в разделе «Logging», и настраивается ведение журнала для вывода на консоль, в журнал отладки и в провайдер EventSource.

4. Установка DI-контейнера
Метод UseDefaultServiceProvider устанавливает DI-контейнер внедрения зависимостей и настраивает проверку области внедрения.

Далее вызывается статический метод ConfigureWebDefaults. Основные его моменты:
5. Настройка Kestrel
В методе UseKestrel выполняется настройка веб-сервера Kestrel параметрами из конфигурационного файла.

6. Настройка необходимых сервисов
В конвейер промежуточного ПО добавляются сервисы HostFiltering (ограничивает имена хостов, на которые откликается приложение) и ForwardedHeaders (настраивает http-заголовки X-Forwarded-For и X-Forwarded-Proto).

7. Интеграция с IIS
Наконец вызываются методы

.UseIIS()
.UseIISIntegration();

Настраиваются два способа размещения приложения:
- In Process запускает приложение внутри процесса IIS (с помощью UseIIS).
- Out of process выполняется в отдельном процессе и использует сервер Kestrel. IIS действует как обратный прокси-сервер, пересылающий запросы в Kestrel (с помощью UseIISIntegration).

Источник: https://www.tektutorialshub.com/asp-net-core/asp-net-core-program-cs/

День пятьсот двадцать четвёртый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
49. Изучайте Иностранные Языки
Программисты должны общаться. Много общаться.

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

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

Помимо общения с машинами программисты должны общаться со своими коллегами. Сегодняшние крупные проекты больше социальные начинания, чем просто прикладное искусство программирования. Важно понимать и уметь выражать больше, чем то, что можно представить в понятных машине абстракциях. Большинство лучших программистов, которых я знаю, также очень свободно говорят на нескольких языках. Это не просто общение с другими: хорошее знание языка также приводит к ясности мышления, что необходимо при абстрагировании проблемы. Этот навык полезен и в программировании.

Помимо общения с машиной, самим собой и коллегами, в проекте есть много заинтересованных сторон, большинство из которых имеют разный уровень технической подготовки или не имеют его вовсе. Они занимаются тестированием, контролем качества и развертыванием, маркетингом и продажами, или же они являются конечными пользователями продукта. Вы должны понимать их и их проблемы. Это почти невозможно, если вы не можете говорить на их языке - языке их мира, их области. Хотя вы можете подумать, что разговор с ними прошёл хорошо, у них может сложиться другое мнение.

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

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

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Klaus Marquardt

День пятьсот двадцать пятый. #юмор