День 1264. #ЗаметкиНаПолях
Используем Span Для Производительности. Начало
Сегодня рассмотрим
Другой реализацией
Ограничения
Реализация
Span-подобный класс можно использовать в асинхронном коде. Это классы
Примеры
Мы можем использовать Span для работы с массивами и другими типами коллекций:
Теперь рассмотрим на аналогичный пример с
Окончание следует…
Источник: https://code-maze.com/csharp-span-to-improve-application-performance/
Используем Span Для Производительности. Начало
Сегодня рассмотрим
Span
в C#, как он реализован и как мы можем использовать его для повышения производительности.Span<T>
— это типобезопасное и безопасное по памяти представление непрерывной области памяти. Span<T>
реализован как ref-структурa (подробнее о ref-структурах), которая содержит ссылку на объект T
и длину для чтения. Т.е. Span в C# всегда будет размещаться на стеке, а не в куче. Рассмотрим упрощённую реализацию Span<T>
:public readonly ref struct Span<T>Использование
{
private readonly ref T _pointer;
private readonly int _length;
}
Span<T>
повышает производительность за счёт размещения на стеке, т.к. сборка мусора не тормозит выполнение приложения. Операции со Span<T>
аналогичны операциям с массивами: индексация в Span
не требует вычислений для определения адреса памяти.Другой реализацией
Span
является ReadOnlySpan<T>
. Его отличие от Span
в том, что индексатор возвращает ссылку на T
только для чтения. Это позволяет использовать ReadOnlySpan<T>
для представления неизменяемых типов данных, таких как string
.Span
может использовать типы значений, такие как int
, byte
, ref struct
, bool
и enum
. Span
не может использовать такие типы, как object
, dynamic
или интерфейсы.Ограничения
Реализация
Span
ограничивает его использование в коде. Объекты ссылочного типа размещаются в куче, поэтому мы не можем использовать Span
в качестве полей в ссылочных типах. Также ref-структуры не могут быть упакованы, и Span
нельзя использовать в лямбда-выражениях и асинхронном коде с await
, а также с yield
. Кроме того, т.к. мы выделяем память в стеке, мы должны помнить, что памяти в стеке меньше, чем в куче.Span-подобный класс можно использовать в асинхронном коде. Это классы
Memory<T>
и ReadOnlyMemory<T>
.Примеры
Мы можем использовать Span для работы с массивами и другими типами коллекций:
int[] arr = new[] { 0, 1, 2, 3 };C# предлагает неявное приведение от
Span<int> intSpan = arr;
var otherSpan = arr.AsSpan();
T[]
к Span<T>
, но мы также можем вызвать AsSpan()
для массивов. Как ReadOnlySpan<T>
, так и Span<T>
предлагают знакомые по работе с массивами функции, не выделяющие дополнительную память.Теперь рассмотрим на аналогичный пример с
List<T>
:List<int> intList = new() { 0, 1, 2, 3 };Использовать
var listSpan = CollectionsMarshal.AsSpan(intList);
Span
с коллекцией не так просто, как с массивами. В этом случае мы должны использовать метод CollectionMarshal.AsSpan()
, чтобы получить коллекцию в виде Span
. Для этого нужно импортировать пространство имён System.Runtime.InteropServices
.Окончание следует…
Источник: https://code-maze.com/csharp-span-to-improve-application-performance/
👍2
День 1265. #ЗаметкиНаПолях
Используем Span Для Производительности. Окончание
Начало
Используем ReadOnlySpan вместо строки
Рассмотрим пример, где нам нужно разобрать строку построчно:
Теперь тот же процесс с использованием Span:
Вспомним, что сборка мусора напрямую влияет на производительность приложения. Используя
Тестирование
Оценим результаты теста производительности двух примеров выше:
ParseWithSpan - 23.55 us, без аллокаций.
ParseWithString - 36.12 us, аллоцировано 70,192 B
Результаты ожидаемы.
Итого
Использование Span повышает производительность. Важно отметить, что команда разработчиков .NET активно использует
Источник: https://code-maze.com/csharp-span-to-improve-application-performance/
Используем Span Для Производительности. Окончание
Начало
Используем ReadOnlySpan вместо строки
Рассмотрим пример, где нам нужно разобрать строку построчно:
public int ParseWithString()В первом примере мы используем строки. Мы пытаемся определить, сколько пустых строк в нашем файле. Текст хранится в строковой переменной
{
var prev = 0;
var curr = 0;
var rows = 0;
foreach (char c in _text)
{
if (c == '\n')
{
curr += 1;
var line = _text[prev..curr];
if (line.Equals(Environment.NewLine))
rows++;
prev = curr;
continue;
}
curr++;
}
return rows;
}
_text
. Мы перебираем каждый символ строке, если находим символ новой строки, с помощью Substring()
проверяем предыдущую строку. Если эта строка пустая, увеличиваем счётчик. Ключевым моментом здесь является то, что Substring()
создаёт строку в куче. Сборщику мусора потребуется время, чтобы уничтожить эти строки.Теперь тот же процесс с использованием Span:
public int ParseWithSpan()Здесь процесс такой же, за исключением того, что мы не создаем дополнительные строки. Мы преобразуем текстовую строку в
{
var textSpan = _text.AsSpan();
var prev = 0;
var curr = 0;
var rows = 0;
foreach (char c in textSpan)
{
if (c == '\n')
{
curr += 1;
var slice = textSpan[prev..curr];
if (slice.Equals(Environment.NewLine, StringComparison.OrdinalIgnoreCase))
rows++;
prev = curr;
continue;
}
curr++;
}
return rows;
}
ReadOnlySpan
, вызывая метод AsSpan()
. Кроме того, вместо Substring()
мы используем метод Slice
, который создаёт ReadOnlySpan
, представляющий подстроку. В этом случае в куче ничего не выделяется.Вспомним, что сборка мусора напрямую влияет на производительность приложения. Используя
ReadOnlySpan
вместо строк везде, где возможно, мы можем сильно повысить производительность приложения. ReadOnlySpan
поддерживает множество функций, знакомых по работе со строками: Contains()
, EndsWith()
, StartsWith()
, IndexOf()
, LastIndexOf()
, ToString()
, Trim()
и т.п. Тестирование
Оценим результаты теста производительности двух примеров выше:
ParseWithSpan - 23.55 us, без аллокаций.
ParseWithString - 36.12 us, аллоцировано 70,192 B
Результаты ожидаемы.
Span
работает быстрее и не выделяет дополнительной памяти (но см. ограничения в предыдущем посте).Итого
Использование Span повышает производительность. Важно отметить, что команда разработчиков .NET активно использует
Span
во внутренних библиотеках и максимально упрощает их использование для разработчиков. Команда .NET уже имеет поддержку Span<T>
для DateTime
, TimeSpan
, Int32
, GUID
, StringBuilder
, System.Random
и многих других типов. Важно понимать, как использовать Span
, потому что они будут больше и больше присутствовать в будущем коде .NET и в некоторых случаях могут стать стандартом.Источник: https://code-maze.com/csharp-span-to-improve-application-performance/
👍10
День 1266. #ЧтоНовенького
AWS Упростили Развёртывание Приложений .NET
Теперь развёртывание в AWS доступно в Visual Studio в виде нового мастера "Publish to AWS" (Опубликовать в AWS), либо через интерфейс командной строки .NET после установки AWS Deploy Tool для .NET.
Одной из основных новых функций являются проекты развёртывания. Эта новая концепция позволяет настраивать развёртывания внутри Visual Studio или CLI и делиться ими с остальными членами вашей команды. Проекты развёртывания позволяют командам разрабатывать собственные сценарии и по-прежнему использовать интерактивные развёртывания или развёртывания с использованием сценариев.
Новый интерфейс развёртывания поддерживает ASP.NET Core, Blazor WebAssembly, консольные приложения и задачи, которые необходимо выполнять по расписанию. В настоящее время функции .NET Lambda не поддерживаются. Существующий мастер развёртывания Lambda и .NET CLI Amazon.Lambda.Tools по-прежнему являются рекомендуемыми вариантами развёртывания для приложений .NET Lambda.
В Visual Studio установите последнюю версию AWS Toolkit для Visual Studio. После установки инструментария и настройки учетных данных AWS можно щелкнуть правой кнопкой мыши на проект в обозревателе решений и выбрать пункт "Publish to AWS…". Новый мастер предложит сервис AWS, который лучше всего подходит для вашего приложения.
В .NET CLI выполните следующую команду для установки инструмента из NuGet:
Подробности о работе инструмента есть в документации AWS.
Источник: https://aws.amazon.com/blogs/developer/aws-announces-a-streamlined-deployment-experience-for-net-applications/
AWS Упростили Развёртывание Приложений .NET
Теперь развёртывание в AWS доступно в Visual Studio в виде нового мастера "Publish to AWS" (Опубликовать в AWS), либо через интерфейс командной строки .NET после установки AWS Deploy Tool для .NET.
Одной из основных новых функций являются проекты развёртывания. Эта новая концепция позволяет настраивать развёртывания внутри Visual Studio или CLI и делиться ими с остальными членами вашей команды. Проекты развёртывания позволяют командам разрабатывать собственные сценарии и по-прежнему использовать интерактивные развёртывания или развёртывания с использованием сценариев.
Новый интерфейс развёртывания поддерживает ASP.NET Core, Blazor WebAssembly, консольные приложения и задачи, которые необходимо выполнять по расписанию. В настоящее время функции .NET Lambda не поддерживаются. Существующий мастер развёртывания Lambda и .NET CLI Amazon.Lambda.Tools по-прежнему являются рекомендуемыми вариантами развёртывания для приложений .NET Lambda.
В Visual Studio установите последнюю версию AWS Toolkit для Visual Studio. После установки инструментария и настройки учетных данных AWS можно щелкнуть правой кнопкой мыши на проект в обозревателе решений и выбрать пункт "Publish to AWS…". Новый мастер предложит сервис AWS, который лучше всего подходит для вашего приложения.
В .NET CLI выполните следующую команду для установки инструмента из NuGet:
dotnet tool install --global Aws.Deploy.ToolsПосле установки можно выполнить следующую команду для начала развёртывания:
dotnet aws deployКоманда
deploy
поможет вам выбрать правильный сервис AWS для развёртывания и настроить параметры. Развёртывание через CLI и через Visual Studio очень похоже, что позволяет развёртывать один и тот же проект из любой среды. Вы также можете составить список своих развёртываний с помощью команды dotnet aws list-deployments
или удалить развёртывание с помощью dotnet aws delete-deployment
. Используйте команду dotnet aws --help
, чтобы найти дополнительные сведения о других доступных командах.Подробности о работе инструмента есть в документации AWS.
Источник: https://aws.amazon.com/blogs/developer/aws-announces-a-streamlined-deployment-experience-for-net-applications/
👍9
День 1267. #ЗаметкиНаПолях #AsyncTips
Выборка в очередях
Задача
Есть очередь «производитель/потребитель», но производители могут работать быстрее потребителей, что может привести к неэффективному использованию памяти. Сохранять все элементы из очереди не обязательно; необходимо отфильтровать элементы очереди так, чтобы более медленные потребители могли ограничиться обработкой самых важных элементов.
Решение
Библиотека
Есть и другие режимы
Библиотека
Если выборка должна выполняться по времени (например, «только 10 элементов в секунду»), используйте
См. также
- Асинхронные очереди
- Блокирующие очереди
- Регулировка очередей
Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 9.
Выборка в очередях
Задача
Есть очередь «производитель/потребитель», но производители могут работать быстрее потребителей, что может привести к неэффективному использованию памяти. Сохранять все элементы из очереди не обязательно; необходимо отфильтровать элементы очереди так, чтобы более медленные потребители могли ограничиться обработкой самых важных элементов.
Решение
Библиотека
Channels
предоставляет самые простые средства применения выборки к элементам ввода. Типичный пример — всегда брать последние n элементов с потерей самых старых элементов при заполнении очереди:var queue = Channel.CreateBounded<int>(Это самый простой механизм контроля входных потоков и предотвращения «затопления» потребителей.
new BoundedChannelOptions(1)
{
FullMode = BoundedChannelFullMode.DropOldest,
});
var writer = queue.Writer;
// Операция записи завершается немедленно.
await writer.WriteAsync(7);
// Операция записи тоже завершается немедленно.
// Элемент 7 теряется, если только он не был
// немедленно извлечен потребителем.
await writer.WriteAsync(13);
Есть и другие режимы
BoundedChannelFullMode
. Например, если вы хотите, чтобы самые старые элементы сохранялись, можно при заполнении канала терять новые элементы:var queue = Channel.CreateBounded<int>(Пояснение
new BoundedChannelOptions(1)
{
FullMode = BoundedChannelFullMode.DropWrite,
});
var writer = queue.Writer;
// Операция записи завершается немедленно
await writer.WriteAsync(7);
// Операция записи тоже завершается немедленно
// Элемент 13 теряется, если только элемент 7 не был
// немедленно извлечен потребителем.
await writer.WriteAsync(13);
Библиотека
Channels
отлично подходит для простой выборки. Во многих ситуациях полезен режим BoundedChannelFullMode.DropOldest
. Более сложная выборка должна выполняться самими потребителями.Если выборка должна выполняться по времени (например, «только 10 элементов в секунду»), используйте
System.Reactive
. В System.Reactive
предусмотрены естественные операторы для работы со временем.См. также
- Асинхронные очереди
- Блокирующие очереди
- Регулировка очередей
Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 9.
👍5
День 1268. #Безопасность #СписокУязвимостей
Памятка по Уязвимостям в C# Приложениях. Продолжение
1-4
5-9
10-13
14-17
Инъекции. Начало
Проблемы с инъекциями возникают, когда приложение не может правильно отличить ненадёжные пользовательские данные от кода.
18. SQL-инъекции
При атаке с SQL-инъекцией злоумышленник вводит данные для управления командами SQL. Когда приложение не проверяет пользовательский ввод должным образом, злоумышленники могут вставлять спецсимволы языка SQL, чтобы нарушить логику запроса; тем самым выполняя произвольный код SQL.
Это позволит злоумышленнику изменять структуру SQL-запросов для кражи или изменения данных, или потенциального выполнения произвольных команд в операционной системе. Лучший способ предотвратить SQL-инъекции — использовать параметризованные запросы, что делает SQL-инъекции практически невозможными.
19. NoSQL-инъекции
Относятся к атакам, которые внедряют данные в логику языков NoSQL (Not Only SQL) баз данных. Современные базы данных NoSQL, такие как MongoDB, Couchbase, Cassandra и HBase, уязвимы для атак путем инъекций. Синтаксис запросов NoSQL зависит от базы данных, и запросы часто пишутся на языке приложения. По той же причине методы предотвращения NoSQL-инъекций в каждую базу данных также зависят от базы данных.
20. LDAP-инъекции
Облегчённый протокол доступа к каталогам (Lightweight Directory Access Protocol - LDAP) — это способ запроса к службе каталогов о пользователях и устройствах системы. Например, он используется для запросов к Microsoft Active Directory. Когда приложение использует ненадёжные входные данные в запросах LDAP, злоумышленники могут отправлять специально созданные данные и обходить аутентификацию или портить данные, хранящиеся в каталоге.
21. Инъекции в журналы
Вы задумывались когда-нибудь о том, что записи в файле журнала могут вам лгать? Файлы журнала, как и другие системные файлы, могут быть изменены злоумышленниками (например, чтобы замести следы во время атаки). Инъекции в журналы происходят, когда злоумышленник обманом заставляет приложение записывать поддельные записи в ваши файлы журналов.
Часто они происходят, когда приложение не экранирует символы новой строки «\n» во входных данных, записываемых в журналы. Злоумышленники могут использовать символ новой строки для вставки новых записей в журналы приложений. Другой способ заключается во внедрении вредоносного HTML в записи журнала, чтобы попытаться провести XSS-атаку на браузер администратора, который просматривает журналы.
Чтобы предотвратить атаки через инъекции в журналы, вам нужен способ отличить настоящие записи журнала от поддельных, введённых злоумышленником. Один из способов сделать это — добавить к каждой записи журнала дополнительные метаданные, такие как отметка времени, идентификатор процесса и имя хоста. Вы также должны относиться к содержимому файлов журналов как к ненадёжным входным данным и проверять их перед доступом к ним или операциями с ними.
22. Инъекции в почте
Многие веб-приложения отправляют электронные письма пользователям в зависимости от их действий. Например, если вы подписались на ленту новостей, веб-сайт может отправить вам письмо с подтверждением.
Инъекции в почте происходят, когда приложение использует пользовательский ввод, чтобы определить, на какие адреса отправлять электронные письма. Это может позволить спамерам использовать ваш сервер для массовых рассылок пользователям или позволить мошенникам проводить фишинговые кампании через ваш адрес электронной почты.
Окончание следует…
Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet
Памятка по Уязвимостям в C# Приложениях. Продолжение
1-4
5-9
10-13
14-17
Инъекции. Начало
Проблемы с инъекциями возникают, когда приложение не может правильно отличить ненадёжные пользовательские данные от кода.
18. SQL-инъекции
При атаке с SQL-инъекцией злоумышленник вводит данные для управления командами SQL. Когда приложение не проверяет пользовательский ввод должным образом, злоумышленники могут вставлять спецсимволы языка SQL, чтобы нарушить логику запроса; тем самым выполняя произвольный код SQL.
Это позволит злоумышленнику изменять структуру SQL-запросов для кражи или изменения данных, или потенциального выполнения произвольных команд в операционной системе. Лучший способ предотвратить SQL-инъекции — использовать параметризованные запросы, что делает SQL-инъекции практически невозможными.
19. NoSQL-инъекции
Относятся к атакам, которые внедряют данные в логику языков NoSQL (Not Only SQL) баз данных. Современные базы данных NoSQL, такие как MongoDB, Couchbase, Cassandra и HBase, уязвимы для атак путем инъекций. Синтаксис запросов NoSQL зависит от базы данных, и запросы часто пишутся на языке приложения. По той же причине методы предотвращения NoSQL-инъекций в каждую базу данных также зависят от базы данных.
20. LDAP-инъекции
Облегчённый протокол доступа к каталогам (Lightweight Directory Access Protocol - LDAP) — это способ запроса к службе каталогов о пользователях и устройствах системы. Например, он используется для запросов к Microsoft Active Directory. Когда приложение использует ненадёжные входные данные в запросах LDAP, злоумышленники могут отправлять специально созданные данные и обходить аутентификацию или портить данные, хранящиеся в каталоге.
21. Инъекции в журналы
Вы задумывались когда-нибудь о том, что записи в файле журнала могут вам лгать? Файлы журнала, как и другие системные файлы, могут быть изменены злоумышленниками (например, чтобы замести следы во время атаки). Инъекции в журналы происходят, когда злоумышленник обманом заставляет приложение записывать поддельные записи в ваши файлы журналов.
Часто они происходят, когда приложение не экранирует символы новой строки «\n» во входных данных, записываемых в журналы. Злоумышленники могут использовать символ новой строки для вставки новых записей в журналы приложений. Другой способ заключается во внедрении вредоносного HTML в записи журнала, чтобы попытаться провести XSS-атаку на браузер администратора, который просматривает журналы.
Чтобы предотвратить атаки через инъекции в журналы, вам нужен способ отличить настоящие записи журнала от поддельных, введённых злоумышленником. Один из способов сделать это — добавить к каждой записи журнала дополнительные метаданные, такие как отметка времени, идентификатор процесса и имя хоста. Вы также должны относиться к содержимому файлов журналов как к ненадёжным входным данным и проверять их перед доступом к ним или операциями с ними.
22. Инъекции в почте
Многие веб-приложения отправляют электронные письма пользователям в зависимости от их действий. Например, если вы подписались на ленту новостей, веб-сайт может отправить вам письмо с подтверждением.
Инъекции в почте происходят, когда приложение использует пользовательский ввод, чтобы определить, на какие адреса отправлять электронные письма. Это может позволить спамерам использовать ваш сервер для массовых рассылок пользователям или позволить мошенникам проводить фишинговые кампании через ваш адрес электронной почты.
Окончание следует…
Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet
👍6
День 1269. #Безопасность #СписокУязвимостей
Памятка по Уязвимостям в C# Приложениях. Окончание
1-4
5-9
10-13
14-17
18-22
Инъекции. Окончание
23. Инъекции в шаблоны
Шаблоны предоставляют разработчикам способ указать, как должна отображаться страница, комбинируя данные приложения с макетом страницы, тем самым отделяя бизнес-логику приложения от клиентского кода представления.
В зависимости от разрешений скомпрометированного приложения злоумышленники могут использовать уязвимость инъекции в шаблон для чтения конфиденциальных файлов, выполнения кода или повышения своих привилегий в системе.
24. Инъекции в регулярные выражения
Иногда приложения позволяют пользователям предоставлять серверу собственные шаблоны регулярных выражений. Атака с инъекцией в регулярное выражение – вид атаки на «отказ в обслуживании» (ReDoS – подробнее об этой атаке в будущих постах) - происходит, когда злоумышленник предоставляет механизму регулярных выражений шаблон, для оценки которого требуется много времени.
25. XPath-инъекции
XPath — это язык запросов, используемый в XML-документах для запроса и выполнения операций с данными, хранящимися в XML-документах. XPath-инъекция — это инъекция в выражения XPath, чтобы изменить результат запроса. Подобно SQL-инъекции, её можно использовать для обхода бизнес-логики, повышения привилегий пользователя и утечки конфиденциальных данных. Поскольку приложения всё ещё часто используют XML для передачи конфиденциальных данных между системами и веб-сервисами, именно эти места наиболее уязвимы для XPath-инъекций.
26. Инъекции в заголовки
Происходят, когда заголовки ответов HTTP динамически создаются из ненадёжных входных данных. В зависимости от того, на какой заголовок ответа влияет уязвимость, инъекция в заголовок может привести к межсайтовому скриптингу, открытому перенаправлению или краже сессии.
Например, если заголовком Location можно управлять с помощью параметра URL, злоумышленники могут вызвать открытое перенаправление, указав свой вредоносный сайт. Злоумышленники могут даже выполнять вредоносные сценарии в браузере жертвы или заставлять жертв загружать вредоносное ПО, отправляя жертве полностью контролируемые HTTP-ответы посредством инъекции в заголовок.
Вы можете предотвратить эту атаку, избегая записи пользовательского ввода в заголовки ответов, удаляя символы новой строки из пользовательского ввода (символы новой строки используются для создания новых заголовков ответов HTTP) или используя белый список для проверки значений заголовков.
27. Инъекции в сессии и небезопасные cookie
Если злоумышленник может манипулировать содержимым cookie-файла сессии или украсть чужие cookie, он может обмануть приложение, заставив его думать, что он является кем-то другим. Существует три основных способа, с помощью которых злоумышленник может получить доступ к чужой сессии:
1) Перехват сессии, когда злоумышленник крадёт чужой cookie-файл сессии и использует его как свой. Злоумышленники часто крадут cookie-файлы сессии с помощью атак XSS или MITM (man-in-the-middle).
2) Фальсификация сессии, когда злоумышленники могут изменить свой cookie-файл сессии, чтобы изменить то, как сервер интерпретирует их личность. Это происходит, когда состояние сессии передаётся в файле cookie, а он неправильно подписан или не зашифрован.
3) Спуфинг сессии – это «подделка» сессии, когда её идентификатор предсказуем. В этом случае злоумышленники могут подделывать настоящие cookie-файлы сессии и входить в систему как кто-то другой.
Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet
Памятка по Уязвимостям в C# Приложениях. Окончание
1-4
5-9
10-13
14-17
18-22
Инъекции. Окончание
23. Инъекции в шаблоны
Шаблоны предоставляют разработчикам способ указать, как должна отображаться страница, комбинируя данные приложения с макетом страницы, тем самым отделяя бизнес-логику приложения от клиентского кода представления.
В зависимости от разрешений скомпрометированного приложения злоумышленники могут использовать уязвимость инъекции в шаблон для чтения конфиденциальных файлов, выполнения кода или повышения своих привилегий в системе.
24. Инъекции в регулярные выражения
Иногда приложения позволяют пользователям предоставлять серверу собственные шаблоны регулярных выражений. Атака с инъекцией в регулярное выражение – вид атаки на «отказ в обслуживании» (ReDoS – подробнее об этой атаке в будущих постах) - происходит, когда злоумышленник предоставляет механизму регулярных выражений шаблон, для оценки которого требуется много времени.
25. XPath-инъекции
XPath — это язык запросов, используемый в XML-документах для запроса и выполнения операций с данными, хранящимися в XML-документах. XPath-инъекция — это инъекция в выражения XPath, чтобы изменить результат запроса. Подобно SQL-инъекции, её можно использовать для обхода бизнес-логики, повышения привилегий пользователя и утечки конфиденциальных данных. Поскольку приложения всё ещё часто используют XML для передачи конфиденциальных данных между системами и веб-сервисами, именно эти места наиболее уязвимы для XPath-инъекций.
26. Инъекции в заголовки
Происходят, когда заголовки ответов HTTP динамически создаются из ненадёжных входных данных. В зависимости от того, на какой заголовок ответа влияет уязвимость, инъекция в заголовок может привести к межсайтовому скриптингу, открытому перенаправлению или краже сессии.
Например, если заголовком Location можно управлять с помощью параметра URL, злоумышленники могут вызвать открытое перенаправление, указав свой вредоносный сайт. Злоумышленники могут даже выполнять вредоносные сценарии в браузере жертвы или заставлять жертв загружать вредоносное ПО, отправляя жертве полностью контролируемые HTTP-ответы посредством инъекции в заголовок.
Вы можете предотвратить эту атаку, избегая записи пользовательского ввода в заголовки ответов, удаляя символы новой строки из пользовательского ввода (символы новой строки используются для создания новых заголовков ответов HTTP) или используя белый список для проверки значений заголовков.
27. Инъекции в сессии и небезопасные cookie
Если злоумышленник может манипулировать содержимым cookie-файла сессии или украсть чужие cookie, он может обмануть приложение, заставив его думать, что он является кем-то другим. Существует три основных способа, с помощью которых злоумышленник может получить доступ к чужой сессии:
1) Перехват сессии, когда злоумышленник крадёт чужой cookie-файл сессии и использует его как свой. Злоумышленники часто крадут cookie-файлы сессии с помощью атак XSS или MITM (man-in-the-middle).
2) Фальсификация сессии, когда злоумышленники могут изменить свой cookie-файл сессии, чтобы изменить то, как сервер интерпретирует их личность. Это происходит, когда состояние сессии передаётся в файле cookie, а он неправильно подписан или не зашифрован.
3) Спуфинг сессии – это «подделка» сессии, когда её идентификатор предсказуем. В этом случае злоумышленники могут подделывать настоящие cookie-файлы сессии и входить в систему как кто-то другой.
Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet
👍8
День 1270. #Оффтоп
А вы знали, что C# допускает out-параметры в конструкторе? То есть вы можете написать что-то вроде:
На Stackoverflow есть даже попытка объяснения:
«В некоторых случаях может быть необходимо при неудаче в конструкторе передать информацию о том, какие части операции были успешными, а какие нет. Рассмотрим, например, объект, конструктор которого принимает дескриптор неуправляемого объекта и должен его инкапсулировать. Если конструктор выдаёт исключение, может быть обязательно, чтобы вызывающий объект освобождал неуправляемый объект, если этого не сделал конструктор, и в равной степени обязательно, чтобы вызывающий объект не освобождал объект, если это сделал конструктор. Наличие в конструкторе параметра out или ref может быть наименее опасным способом для класса сообщить вызывающему объекту, что нужно будет очистить, если конструктор завершится ошибкой.
Хотя передавать конструктору параметры ref или out некрасиво, существуют некоторые типы, в которых попытки создать пригодный для использования экземпляр будут иметь побочные эффекты и могут завершиться неудачей после того, как некоторые из этих побочных эффектов уже произошли. Если невозможно создать допустимый объект, вот способы передать информацию вызывающей стороне:
- сохранение в поле ThreadStatic,
- инкапсуляция в выброшенном исключении,
- сохранение или передача в параметр в виде объекта или делегата,
- запись в параметр ref/out.
Из них только параметр ref/out делает очевидным наличие информации, с которой клиентский код должен что-то делать.
Существование параметров ref или out часто является признаком того, что конструктор должен быть помечен как protected, и что внешний код должен проходить через фабричные методы, которые гарантируют, что в случае возникновения исключения переданный объект будет использоваться соответствующим образом. Однако, чтобы класс мог разумно поддерживать наследование, он должен предлагать по крайней мере один конструктор, видимый вне его.»
Источник: https://stackoverflow.com/questions/19633251/constructor-with-output-parameter
А вы знали, что C# допускает out-параметры в конструкторе? То есть вы можете написать что-то вроде:
class MyClassЖивите теперь с этим…
{
public MyClass(out bool succeeded)
{
// что-то делаем
succeeded = true;
}
}
На Stackoverflow есть даже попытка объяснения:
«В некоторых случаях может быть необходимо при неудаче в конструкторе передать информацию о том, какие части операции были успешными, а какие нет. Рассмотрим, например, объект, конструктор которого принимает дескриптор неуправляемого объекта и должен его инкапсулировать. Если конструктор выдаёт исключение, может быть обязательно, чтобы вызывающий объект освобождал неуправляемый объект, если этого не сделал конструктор, и в равной степени обязательно, чтобы вызывающий объект не освобождал объект, если это сделал конструктор. Наличие в конструкторе параметра out или ref может быть наименее опасным способом для класса сообщить вызывающему объекту, что нужно будет очистить, если конструктор завершится ошибкой.
Хотя передавать конструктору параметры ref или out некрасиво, существуют некоторые типы, в которых попытки создать пригодный для использования экземпляр будут иметь побочные эффекты и могут завершиться неудачей после того, как некоторые из этих побочных эффектов уже произошли. Если невозможно создать допустимый объект, вот способы передать информацию вызывающей стороне:
- сохранение в поле ThreadStatic,
- инкапсуляция в выброшенном исключении,
- сохранение или передача в параметр в виде объекта или делегата,
- запись в параметр ref/out.
Из них только параметр ref/out делает очевидным наличие информации, с которой клиентский код должен что-то делать.
Существование параметров ref или out часто является признаком того, что конструктор должен быть помечен как protected, и что внешний код должен проходить через фабричные методы, которые гарантируют, что в случае возникновения исключения переданный объект будет использоваться соответствующим образом. Однако, чтобы класс мог разумно поддерживать наследование, он должен предлагать по крайней мере один конструктор, видимый вне его.»
Источник: https://stackoverflow.com/questions/19633251/constructor-with-output-parameter
👍12
День 1272. #Оффтоп
Github и Лицензирование
Вопрос
Код моего проекта на Github скопировали вместе с комментариями и выдали за свой. Я не указывал никакой лицензии в своём проекте. В будущем, если кто-то попытается скопировать мой проект, как быть? Означает ли наличие кода на Github, что любой может скопировать код, не указывая автора? Не хотелось бы просто закрывать свои репозитории.
Ответ на зависит от лицензии, которую вы применили к проекту.
1. Лицензия не указана
Технически, если вы не указали лицензию, а также явно не поместили работу в публичный домен, то никто, кроме вас, не может легально делать копии. Независимо от того, заявили ли вы это где-либо явно или нет, этот случай, по сути, является авторским правом, и все права защищены. Если в этом ваше намерение, то такой репозиторий лучше закрыть. Люди все время форкают и клонируют общедоступные репозитории, в том числе без заявленных лицензий. Многие ошибочно думают, что отсутствие лицензии означает разрешение на свободное использование, но на самом деле нет.
2. Лицензия MIT
Эта лицензия разрешает всё. Позволяет другим делать практически всё что угодно с вашим кодом: копировать, как есть, изменять, использовать в коммерческом программном обеспечении с закрытым исходным кодом, продавать с изменениями или без них и так далее. Единственное требование заключается в том, чтобы они сохраняли уведомление об авторских правах и уведомление о лицензии в неизменном виде во всех копиях, которые они распространяют, в том числе в «значительных частях». Однако они могут распространять код с изменениями или без под любой лицензией, под которой пожелают. Основная цель требования сохранения уведомления состоит в том, чтобы другие знали, как эта часть была первоначально лицензирована. Можно копировать несущественные части без включения вашего уведомления об авторских правах и лицензии.
С лицензией MIT вы должны помещать уведомления об авторских правах и лицензии в комментариях вверху каждого исходного файла в дополнение к файлу лицензии в репозитории. Таким образом, если кто-то использует один или несколько файлов, но не весь репозиторий, ваше уведомление об авторских правах и заявление о лицензии останутся с вашим кодом, если только его не удалят преднамеренно. Имея только файл лицензии, вы рискуете, что любой из ваших исходных файлов может быть использован отдельно от остального кода без указания лицензии.
3. Лицензия Apache
Как и с MIT, здесь разрешено всё. Есть несколько отличий, но в основном она позволяет другим использовать ваш код так, как они считают нужным. Одно из отличий заключается в том, что Apache требует, чтобы любые изменения в вашем коде были идентифицированы, чтобы другие знали, что он был изменён и как. MIT не требует этого, хотя многие всё равно это делают.
Как и в случае с MIT, лучше помещать уведомление об авторских правах вверху каждого исходного файла, но не полную лицензию (слишком длинную для этого). В нижней части лицензии Apache есть сокращённое уведомление, которое следует включать в комментарий вверху каждого исходного файла. Причина та же, что и в случае с MIT.
Всеразрешающие лицензии, как MIT или Apache, близки к тому, чтобы сделать что-то общественным достоянием, не делая этого на самом деле. В некоторых странах это самое близкое к тому, чтобы сделать что-то общественным достоянием.
4. Лицензия «копилефт»
Если вы хотите сохранить больше прав на свою работу, можно использовать лицензию «копилефт». Если коротко, применение лицензии «копилефт» к коду, требует от любого, кто создаёт производную работу на основе вашего кода, применения той же лицензии. По сути, это сохраняет ваш код и всё, что из него происходит, открытым кодом. Лицензии MIT и Apache не накладывают таких обязательств. GPL 3.0 является наиболее распространённой лицензией «копилефт».
Источник: https://dev.to/sadeedpv/someone-copied-my-code-on-github-and-claimed-to-be-his-own-project-4dho
Github и Лицензирование
Вопрос
Код моего проекта на Github скопировали вместе с комментариями и выдали за свой. Я не указывал никакой лицензии в своём проекте. В будущем, если кто-то попытается скопировать мой проект, как быть? Означает ли наличие кода на Github, что любой может скопировать код, не указывая автора? Не хотелось бы просто закрывать свои репозитории.
Ответ на зависит от лицензии, которую вы применили к проекту.
1. Лицензия не указана
Технически, если вы не указали лицензию, а также явно не поместили работу в публичный домен, то никто, кроме вас, не может легально делать копии. Независимо от того, заявили ли вы это где-либо явно или нет, этот случай, по сути, является авторским правом, и все права защищены. Если в этом ваше намерение, то такой репозиторий лучше закрыть. Люди все время форкают и клонируют общедоступные репозитории, в том числе без заявленных лицензий. Многие ошибочно думают, что отсутствие лицензии означает разрешение на свободное использование, но на самом деле нет.
2. Лицензия MIT
Эта лицензия разрешает всё. Позволяет другим делать практически всё что угодно с вашим кодом: копировать, как есть, изменять, использовать в коммерческом программном обеспечении с закрытым исходным кодом, продавать с изменениями или без них и так далее. Единственное требование заключается в том, чтобы они сохраняли уведомление об авторских правах и уведомление о лицензии в неизменном виде во всех копиях, которые они распространяют, в том числе в «значительных частях». Однако они могут распространять код с изменениями или без под любой лицензией, под которой пожелают. Основная цель требования сохранения уведомления состоит в том, чтобы другие знали, как эта часть была первоначально лицензирована. Можно копировать несущественные части без включения вашего уведомления об авторских правах и лицензии.
С лицензией MIT вы должны помещать уведомления об авторских правах и лицензии в комментариях вверху каждого исходного файла в дополнение к файлу лицензии в репозитории. Таким образом, если кто-то использует один или несколько файлов, но не весь репозиторий, ваше уведомление об авторских правах и заявление о лицензии останутся с вашим кодом, если только его не удалят преднамеренно. Имея только файл лицензии, вы рискуете, что любой из ваших исходных файлов может быть использован отдельно от остального кода без указания лицензии.
3. Лицензия Apache
Как и с MIT, здесь разрешено всё. Есть несколько отличий, но в основном она позволяет другим использовать ваш код так, как они считают нужным. Одно из отличий заключается в том, что Apache требует, чтобы любые изменения в вашем коде были идентифицированы, чтобы другие знали, что он был изменён и как. MIT не требует этого, хотя многие всё равно это делают.
Как и в случае с MIT, лучше помещать уведомление об авторских правах вверху каждого исходного файла, но не полную лицензию (слишком длинную для этого). В нижней части лицензии Apache есть сокращённое уведомление, которое следует включать в комментарий вверху каждого исходного файла. Причина та же, что и в случае с MIT.
Всеразрешающие лицензии, как MIT или Apache, близки к тому, чтобы сделать что-то общественным достоянием, не делая этого на самом деле. В некоторых странах это самое близкое к тому, чтобы сделать что-то общественным достоянием.
4. Лицензия «копилефт»
Если вы хотите сохранить больше прав на свою работу, можно использовать лицензию «копилефт». Если коротко, применение лицензии «копилефт» к коду, требует от любого, кто создаёт производную работу на основе вашего кода, применения той же лицензии. По сути, это сохраняет ваш код и всё, что из него происходит, открытым кодом. Лицензии MIT и Apache не накладывают таких обязательств. GPL 3.0 является наиболее распространённой лицензией «копилефт».
Источник: https://dev.to/sadeedpv/someone-copied-my-code-on-github-and-claimed-to-be-his-own-project-4dho
👍18
День 1273. #ЧтоНовенького
Обновления ASP.NET Core в .NET 7 Превью 6. Начало
Некоторые интересные новинки, которые выпустили для ASP.NET Core в очередном превью .NET 7.
1. Промежуточное ПО для распаковки запросов
Используется HTTP-заголовок
Это промежуточное ПО добавляется с помощью метода расширения
Поддерживаются Brotli (br), Deflate (deflate) и GZip (gzip). Другие кодировки можно добавить, зарегистрировав собственный класс поставщика распаковки, который реализует интерфейс
2. Промежуточное ПО для кэширования вывода
Помогает вам сохранять результаты вашего веб-приложения и обслуживать их из кэша, а не вычислять их каждый раз, что повышает производительность и высвобождает ресурсы для других действий.
Используйте метод расширения
Существует множество более продвинутых способов:
- по параметру строки запроса
- по произвольному значению (
Промежуточное ПО кэширования имеет встроенную защиту от некоторых распространённых ошибок. Например, при инвалидации значения кэша только первый запрос будет вызывать серверный код получения значения. Остальные запросы в это время будут ждать появления значения в кэше, чтобы не перегружать сервер избыточной работой. Вот здесь есть пример использования кэширования.
3. Обновления промежуточного ПО ограничений
Промежуточное ПО ограничений (rate limiting) теперь поддерживает ограничения на определённых конечных точках, которое можно комбинировать с глобальным ограничителем, работающим для всех запросов. Также теперь поддерживается добавление пользовательских политик ограничений с помощью новых методов
Подробнее об ограничениях в этом посте (см. пункт 4).
4. Поддержка WebSockets через HTTP/2 в Kestrel
Использование WebSockets через HTTP/2 позволяет использовать преимущества новых функций, таких как сжатие заголовков и мультиплексирование, которые сокращают время и ресурсы, необходимые при выполнении нескольких запросов к серверу. Эта поддержка теперь доступна в Kestrel на всех платформах с поддержкой HTTP/2.
Согласование версии HTTP выполняется автоматически в браузерах и Kestrel. Вы можете использовать существующие примеры для ASP.NET Core.
Примечание: WebSockets в HTTP/2 использует запросы
5. Улучшения производительности Kestrel на многоядерных компьютерах
Разделение
Источник: https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-7-preview-6/
Обновления ASP.NET Core в .NET 7 Превью 6. Начало
Некоторые интересные новинки, которые выпустили для ASP.NET Core в очередном превью .NET 7.
1. Промежуточное ПО для распаковки запросов
Используется HTTP-заголовок
Content-Encoding
для автоматической идентификации и распаковки запросов со сжатым содержимым, чтобы разработчику серверной части не приходилось заниматься этим самостоятельно.Это промежуточное ПО добавляется с помощью метода расширения
UseRequestDecompression
в IApplicationBuilder
и метода расширения AddRequestDecompression
в IServiceCollection
.Поддерживаются Brotli (br), Deflate (deflate) и GZip (gzip). Другие кодировки можно добавить, зарегистрировав собственный класс поставщика распаковки, который реализует интерфейс
IDecompressionProvider
вместе со значением заголовка Content-Encoding
в RequestDecompressionOptions
.2. Промежуточное ПО для кэширования вывода
Помогает вам сохранять результаты вашего веб-приложения и обслуживать их из кэша, а не вычислять их каждый раз, что повышает производительность и высвобождает ресурсы для других действий.
Используйте метод расширения
AddOutputCache
в IServiceCollection
и метод расширения UseOutputCache
в IApplicationBuilder
. После можно настроить кэширование на конечных точках:app.MapGet("/notcached",Запросы к
() => DateTime.Now.ToString());
app.MapGet("/cached",
() => DateTime.Now.ToString()).CacheOutput();
/notcached
вернут текущее время. А каждый запрос к /cached
после первого будет возвращать кешированный ответ.Существует множество более продвинутых способов:
- по параметру строки запроса
….CacheOutput(p => p.VaryByQuery("culture"));- по заголовкам (
VaryByHeader
)- по произвольному значению (
VaryByValue
).Промежуточное ПО кэширования имеет встроенную защиту от некоторых распространённых ошибок. Например, при инвалидации значения кэша только первый запрос будет вызывать серверный код получения значения. Остальные запросы в это время будут ждать появления значения в кэше, чтобы не перегружать сервер избыточной работой. Вот здесь есть пример использования кэширования.
3. Обновления промежуточного ПО ограничений
Промежуточное ПО ограничений (rate limiting) теперь поддерживает ограничения на определённых конечных точках, которое можно комбинировать с глобальным ограничителем, работающим для всех запросов. Также теперь поддерживается добавление пользовательских политик ограничений с помощью новых методов
AddPolicy
в RateLimiterOptions
.Подробнее об ограничениях в этом посте (см. пункт 4).
4. Поддержка WebSockets через HTTP/2 в Kestrel
Использование WebSockets через HTTP/2 позволяет использовать преимущества новых функций, таких как сжатие заголовков и мультиплексирование, которые сокращают время и ресурсы, необходимые при выполнении нескольких запросов к серверу. Эта поддержка теперь доступна в Kestrel на всех платформах с поддержкой HTTP/2.
Согласование версии HTTP выполняется автоматически в браузерах и Kestrel. Вы можете использовать существующие примеры для ASP.NET Core.
Примечание: WebSockets в HTTP/2 использует запросы
CONNECT
, а не GET
, поэтому ваши маршруты и контроллеры возможно придётся обновить.5. Улучшения производительности Kestrel на многоядерных компьютерах
Разделение
ConcurrentQueue
, используемой в Kestrel, по связанному с ней сокету уменьшает конкуренцию и увеличивает пропускную способность на машинах с большим количеством ядер. В превью 6 пул памяти Kestrel теперь разделён так же, как и очередь ввода-вывода. Наблюдалось более чем 500% улучшение RPS в тестах TechEmpower на 80-ядерных виртуальных машинах ARM64 (доступных теперь в Azure) и почти 100-процентное улучшение на 48-ядерных виртуальных машинах AMD в тесте HTTPS JSON.Источник: https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-7-preview-6/
👍15
День 1274. #ЧтоНовенького
Обновления ASP.NET Core в .NET 7 Превью 6. Окончание
Начало
6. Поддержка регистрации дополнительных заголовков запросов в W3CLogger
W3Clogger – логгер, который пишет лог-файлы в формате стандарта W3C.
Теперь вы можете указать дополнительные заголовки запросов
В Blazor появились два новых шаблона проектов для старта «с чистого листа». Новые шаблоны такие же, как их непустые аналоги, но без дополнительного демонстрационного кода, только с очень простой домашней страницей. Также удалён Bootstrap, чтобы можно было использовать любой CSS-фреймворк.
Новые шаблоны доступны в Visual Studio после установки пакета SDK для .NET 7, а также из командной строки:
.NET 6 поддерживал семейство алгоритмов хеширования SHA при работе на WebAssembly. .NET 7 позволяет использовать больше криптографических алгоритмов, используя преимущества SubtleCrypto, когда это возможно, и возвращаясь к реализации .NET, когда SubtleCrypto использовать нельзя. Теперь поддерживаются следующие алгоритмы:
- SHA1
- SHA256
- SHA384
- SHA512
- HMACSHA1
- HMACSHA256
- HMACSHA384
- HMACSHA512
Поддержка AES-CBC, PBKDF2 и HKDF запланирована в будущих обновлениях .NET 7.
9. Поддержка пользовательских элементов Blazor больше не является экспериментальной
Ранее экспериментальный пакет Microsoft.AspNetCore.Components.CustomElements для создания пользовательских элементов Blazor на основе стандартных больше не является экспериментальным и теперь является частью выпуска .NET 7. Подробности см. в документации о создании пользовательских элементов Blazor.
10. Экспериментальный компонент QuickGrid для Blazor
QuickGrid — это новый экспериментальный компонент Blazor для быстрого и эффективного отображения данных в табличной форме. QuickGrid предоставляет простой и удобный компонент сетки данных для наиболее распространённых случаев. Чтобы использовать компонент, добавьте пакет
Microsoft.AspNetCore.Components.QuickGrid. Примеры использования можно посмотреть здесь.
Источник: https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-7-preview-6/
Обновления ASP.NET Core в .NET 7 Превью 6. Окончание
Начало
6. Поддержка регистрации дополнительных заголовков запросов в W3CLogger
W3Clogger – логгер, который пишет лог-файлы в формате стандарта W3C.
Теперь вы можете указать дополнительные заголовки запросов
AdditionalRequestHeaders()
в W3CLoggerOptions
:services.AddW3CLogging(l =>7. Пустые шаблоны проектов Blazor
{
l.AdditionalRequestHeaders.Add("x-forwarded-for");
l.AdditionalRequestHeaders.Add("x-client-ssl-protocol");
});
В Blazor появились два новых шаблона проектов для старта «с чистого листа». Новые шаблоны такие же, как их непустые аналоги, но без дополнительного демонстрационного кода, только с очень простой домашней страницей. Также удалён Bootstrap, чтобы можно было использовать любой CSS-фреймворк.
Новые шаблоны доступны в Visual Studio после установки пакета SDK для .NET 7, а также из командной строки:
dotnet new blazorserver-empty8. Поддержка System.Security.Cryptography в WebAssembly
dotnet new blazorwasm-empty
.NET 6 поддерживал семейство алгоритмов хеширования SHA при работе на WebAssembly. .NET 7 позволяет использовать больше криптографических алгоритмов, используя преимущества SubtleCrypto, когда это возможно, и возвращаясь к реализации .NET, когда SubtleCrypto использовать нельзя. Теперь поддерживаются следующие алгоритмы:
- SHA1
- SHA256
- SHA384
- SHA512
- HMACSHA1
- HMACSHA256
- HMACSHA384
- HMACSHA512
Поддержка AES-CBC, PBKDF2 и HKDF запланирована в будущих обновлениях .NET 7.
9. Поддержка пользовательских элементов Blazor больше не является экспериментальной
Ранее экспериментальный пакет Microsoft.AspNetCore.Components.CustomElements для создания пользовательских элементов Blazor на основе стандартных больше не является экспериментальным и теперь является частью выпуска .NET 7. Подробности см. в документации о создании пользовательских элементов Blazor.
10. Экспериментальный компонент QuickGrid для Blazor
QuickGrid — это новый экспериментальный компонент Blazor для быстрого и эффективного отображения данных в табличной форме. QuickGrid предоставляет простой и удобный компонент сетки данных для наиболее распространённых случаев. Чтобы использовать компонент, добавьте пакет
Microsoft.AspNetCore.Components.QuickGrid. Примеры использования можно посмотреть здесь.
Источник: https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-7-preview-6/
👍10
День 1275. #ЗаметкиНаПолях
Настройка Через Параметры Командной Строки в Консольных Приложениях
Внедрение зависимостей значительно упрощает управление ресурсами в приложениях .NET, по крайней мере, если вы разберётесь с настройкой хоста.
Для приложений .NET мы обычно используем файл JSON с настройками, но можно сделать приложение более гибким, с помощью параметров командной строки. Вариантом использования может быть временное решение, которое требуется запускать как запланированное задание.
В примере ниже консольное приложение .NET вызывается в терминале, а параметры являются позиционными и все обязательные. Приложение вызывается так:
Важно отметить, что в нашей конфигурации хоста мы сопоставляем параметры с элементами словаря, а в классе извлекаем настроенные значения, как и в любом другом случае использования интерфейса
Полный код примера здесь
Источник: https://dev.to/alfetta159/configuration-using-command-line-parameters-in-net-console-applications-21e4
Настройка Через Параметры Командной Строки в Консольных Приложениях
Внедрение зависимостей значительно упрощает управление ресурсами в приложениях .NET, по крайней мере, если вы разберётесь с настройкой хоста.
Для приложений .NET мы обычно используем файл JSON с настройками, но можно сделать приложение более гибким, с помощью параметров командной строки. Вариантом использования может быть временное решение, которое требуется запускать как запланированное задание.
В примере ниже консольное приложение .NET вызывается в терминале, а параметры являются позиционными и все обязательные. Приложение вызывается так:
dotnet MyApp.dll first second third fourth fifthТеперь проведём настройку хоста в файле program.cs, сначала создавая построитель по умолчанию с аргументами командной строки, а затем настраиваем конфигурацию приложения как коллекцию в памяти, основанную на парах ключ-значение из словаря:
using IHost host = HostТеперь мы можем передать эту конфигурацию как параметр в любой конструктор:
.CreateDefaultBuilder(args)
.ConfigureAppConfiguration((_, conf) =>
conf.AddInMemoryCollection(
new Dictionary<string, string> {
["First"] = args[0],
["Second"] = args[1],
["Third"] = args[2],
["Fourth"] = args[3],
["Fifth"] = args[4]
}))
.ConfigureServices((_, srvc) =>
srvc.AddScoped<TestClass>())
.Build();
using System.Text;И далее вызвать класс как сервис:
using Microsoft.Extensions.Configuration;
namespace MyApp;
public class TestClass
{
private readonly string First;
private readonly string Second;
private readonly string Third;
private readonly string Fourth;
private readonly string Fifth;
public TestClass(IConfiguration conf)
{
First = conf["First"];
Second = conf["Second"];
Third = conf["Third"];
Fourth = conf["Fourth"];
Fifth = conf["Fifth"];
}
public void Run()
{
//…
}
}
var test = host.Services.GetService<TestClass>();Этот пример не проверяет список параметров и не предлагает какой-либо гибкости. Здесь мы просто превращаем параметры командной строки в удобную конфигурацию, передаваемую через внедрение зависимостей.
test.Run();
Важно отметить, что в нашей конфигурации хоста мы сопоставляем параметры с элементами словаря, а в классе извлекаем настроенные значения, как и в любом другом случае использования интерфейса
IConfiguration
.Полный код примера здесь
Источник: https://dev.to/alfetta159/configuration-using-command-line-parameters-in-net-console-applications-21e4
👍1
День 1276. #Карьера
Что Можно Делать Перед Работой, Чтобы Улучшить Ментальное Состояние и Повысить Продуктивность
По возможности не стоит вставать с кровати и сразу же отправляться на работу. Эксперты говорят, что стоит добавить в ежедневный распорядок занятия собой перед работой.
«Осознаёте вы это или нет, старт рабочего дня в плохом настроении может сильно испортить весь день», - говорит Джоэл Двоскин, психолог из Медицинского колледжа Университета Аризоны. Хорошо, что обратное также справедливо. «Просто размышление о том, что вы сегодня можете сделать для себя, перед началом рабочего дня может повлиять на ваше удовлетворение от работы, продуктивность и на то, как вы работаете с коллегами».
Перед работой вы можете заняться множеством дел, чтобы проверить свой ментальный статус, улучшить настроение и повысить эффективность работы. Вот три пути, по мнению экспертов:
1. Проведите время в тихой обстановке
Практика «настройки сознания» может быть очень полезной для вашей продуктивности. Смысл в том, чтобы выделить первые 20–30 минут утра для уединения. В это время обратите внимание на ваши желания и стремления,
подумайте о том, чего вы хотели бы достичь в течение дня. Вот некоторые из вопросов, которые стоит задать себе:
- Что меня волнует сегодня?
- Что действительно важно для меня в перспективе?
- Чего стоит сегодня добиться?
- Что будет успехом?
2. Займитесь физической активностью
Найдите свой любимый способ подвигаться и стремитесь делать это всякий раз, прежде чем браться за работу. Простая прогулка по пять минут в день рядом с вашим домом может стать отличным началом.
«Есть исследования, которые показывают, что движение может помочь людям сосредоточиться и успокоиться», — говорит Двоскин. Согласно сводному обзору более 1000 исследований, проведённых с 1990 по 2020 год, движение в любой форме положительно влияет на самочувствие и уменьшает симптомы депрессии по сравнению с полным отсутствием физических упражнений. Если найти свободное время каждый день сложно, есть альтернативы. Даже просто выйти на балкон или во двор и потянуться пару минут будет полезно.
3. Побалуйте себя
Это сугубо индивидуальное занятие, но заняться тем, что вы любите, или побаловать себя чем-то, что вам нравится, может стать зарядом позитивной энергии для отличного рабочего дня.
Мы чувствуем, что наша жизнь не принадлежит нам по утрам, поэтому переключаем будильник и остаёмся в кровати подольше, пытаясь удержать каждую минуту, которую мы можем сохранить для себя. Нужно найти какое-нибудь утреннее занятие, которое вам действительно интересно и которого вы с нетерпением ждёте:
- Приготовьте свой любимый завтрак,
- Включите любимый плейлист, пока собираетесь,
- Возьмите побольше стакан вашего любимого напитка в кофейне,
- Посмотрите эпизод сериала, который вам нравится.
Независимо от того, как вы это сделаете, важно выделить время для себя утром. Личное развитие и внимание к своему ментальному здоровью являются частью профессионального развития. Если вы заботитесь о себе в личное время, это сделает вас более эффективным в профессиональное время.
Источник: https://www.cnbc.com/2022/07/26/3-activities-before-work-that-improve-mental-health-and-productivity.html
Что Можно Делать Перед Работой, Чтобы Улучшить Ментальное Состояние и Повысить Продуктивность
По возможности не стоит вставать с кровати и сразу же отправляться на работу. Эксперты говорят, что стоит добавить в ежедневный распорядок занятия собой перед работой.
«Осознаёте вы это или нет, старт рабочего дня в плохом настроении может сильно испортить весь день», - говорит Джоэл Двоскин, психолог из Медицинского колледжа Университета Аризоны. Хорошо, что обратное также справедливо. «Просто размышление о том, что вы сегодня можете сделать для себя, перед началом рабочего дня может повлиять на ваше удовлетворение от работы, продуктивность и на то, как вы работаете с коллегами».
Перед работой вы можете заняться множеством дел, чтобы проверить свой ментальный статус, улучшить настроение и повысить эффективность работы. Вот три пути, по мнению экспертов:
1. Проведите время в тихой обстановке
Практика «настройки сознания» может быть очень полезной для вашей продуктивности. Смысл в том, чтобы выделить первые 20–30 минут утра для уединения. В это время обратите внимание на ваши желания и стремления,
подумайте о том, чего вы хотели бы достичь в течение дня. Вот некоторые из вопросов, которые стоит задать себе:
- Что меня волнует сегодня?
- Что действительно важно для меня в перспективе?
- Чего стоит сегодня добиться?
- Что будет успехом?
2. Займитесь физической активностью
Найдите свой любимый способ подвигаться и стремитесь делать это всякий раз, прежде чем браться за работу. Простая прогулка по пять минут в день рядом с вашим домом может стать отличным началом.
«Есть исследования, которые показывают, что движение может помочь людям сосредоточиться и успокоиться», — говорит Двоскин. Согласно сводному обзору более 1000 исследований, проведённых с 1990 по 2020 год, движение в любой форме положительно влияет на самочувствие и уменьшает симптомы депрессии по сравнению с полным отсутствием физических упражнений. Если найти свободное время каждый день сложно, есть альтернативы. Даже просто выйти на балкон или во двор и потянуться пару минут будет полезно.
3. Побалуйте себя
Это сугубо индивидуальное занятие, но заняться тем, что вы любите, или побаловать себя чем-то, что вам нравится, может стать зарядом позитивной энергии для отличного рабочего дня.
Мы чувствуем, что наша жизнь не принадлежит нам по утрам, поэтому переключаем будильник и остаёмся в кровати подольше, пытаясь удержать каждую минуту, которую мы можем сохранить для себя. Нужно найти какое-нибудь утреннее занятие, которое вам действительно интересно и которого вы с нетерпением ждёте:
- Приготовьте свой любимый завтрак,
- Включите любимый плейлист, пока собираетесь,
- Возьмите побольше стакан вашего любимого напитка в кофейне,
- Посмотрите эпизод сериала, который вам нравится.
Независимо от того, как вы это сделаете, важно выделить время для себя утром. Личное развитие и внимание к своему ментальному здоровью являются частью профессионального развития. Если вы заботитесь о себе в личное время, это сделает вас более эффективным в профессиональное время.
Источник: https://www.cnbc.com/2022/07/26/3-activities-before-work-that-improve-mental-health-and-productivity.html
👍11
День 1278. #Безопасность
Атаки на Отказ в Обслуживании с помощью Регулярных Выражений (ReDoS)
Регулярные выражения сложно оценивать. Неправильный шаблон может привести к низкой производительности, ошибочным результатам и даже к уязвимости.
Плохо спроектированные шаблоны регулярных выражений могут привести к неудачной проверке входных данных, негерметичным брандмауэрам и даже атакам на отказ в обслуживании (DoS). При DoS-атаке злоумышленник замедляет работу онлайн-сервиса или делает его недоступным для пользователей. Существует множество различных типов DoS, одним из которых является ReDoS, когда злоумышленник предоставляет механизму регулярных выражений строку, для оценки которой требуется много времени с помощью так называемых «злых шаблонов» (evil regex).
Большинство оценщиков регулярных выражений имеют экспоненциальную сложность в худшем случае, т.е. время оценки растёт экспоненциально по отношению к размеру входной строки. Шаблоны, которые могут привести к зависанию приложения при оценке, имеют две характеристики:
1) часто включают повторение сложных подвыражений (
2) внутри этих повторяющихся подвыражений есть дополнительные повторяющиеся символы и выражения, которые соответствуют суффиксу другого совпадения.
Например:
Иногда приложения позволяют пользователям вводить собственные шаблоны регулярных выражений для выполнения сервером. В этом случае злоумышленник может внедрить вредоносное регулярное выражение по своему выбору, а затем отправить строку ввода, которая заставит злонамеренное регулярное выражение выполняться в течение длительного времени.
Другой пример - при регистрации проверка, содержит ли пароль пользователя его имя. Если приложение вслепую использует имя пользователя как шаблон без очистки спецсимволов, например:
1. Многопоточность и упреждающее уничтожение процессов. Многопоточное приложение может одновременно обрабатывать другие запросы, даже если вычисление регулярного выражения занимает слишком много времени. Также нужно останавливать выполнение любой оценки регулярного выражения, если она занимает больше времени, чем ожидалось.
2. Не стоит раскрывать ваши шаблоны регулярных выражений. Иногда они публикуются, потому что проект имеет открытый исходный код, или случайно, т.к. используются одни и те же шаблоны как в серверном, так и в клиентском коде. Это облегчает злоумышленникам поиск вредоносных регулярных выражений и создание соответствующих строк для атаки.
3. Избегайте использования опасных регулярных выражений для оценки пользовательского ввода (см. критерии выше) и вместо этого используйте более простые. Поищите проверенные и защищённые шаблоны вместо того, чтобы писать свои собственные.
4. Исключите возможность для пользователей предоставлять свои шаблоны регулярных выражений оценщику. Если вам нужна такая функциональность, используйте предварительно отформатированные регулярные выражения, которые допускают минимальную настройку.
Источник: https://sec.okta.com/articles/2020/04/attacking-evil-regex-understanding-regular-expression-denial-service
Атаки на Отказ в Обслуживании с помощью Регулярных Выражений (ReDoS)
Регулярные выражения сложно оценивать. Неправильный шаблон может привести к низкой производительности, ошибочным результатам и даже к уязвимости.
Плохо спроектированные шаблоны регулярных выражений могут привести к неудачной проверке входных данных, негерметичным брандмауэрам и даже атакам на отказ в обслуживании (DoS). При DoS-атаке злоумышленник замедляет работу онлайн-сервиса или делает его недоступным для пользователей. Существует множество различных типов DoS, одним из которых является ReDoS, когда злоумышленник предоставляет механизму регулярных выражений строку, для оценки которой требуется много времени с помощью так называемых «злых шаблонов» (evil regex).
Большинство оценщиков регулярных выражений имеют экспоненциальную сложность в худшем случае, т.е. время оценки растёт экспоненциально по отношению к размеру входной строки. Шаблоны, которые могут привести к зависанию приложения при оценке, имеют две характеристики:
1) часто включают повторение сложных подвыражений (
+
и *
в сложных подвыражениях),2) внутри этих повторяющихся подвыражений есть дополнительные повторяющиеся символы и выражения, которые соответствуют суффиксу другого совпадения.
Например:
^(a+)+$Подвыражение в скобках ищет повторяющийся символ «a». Оно также проверяет, является ли всё выражение повторением какого-либо из подвыражений! Допустим, злоумышленник вводит такие данные:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaЗдесь каждая дополнительная буква "a" заставит оценщик проверять наличие повторений дополнительного подвыражения, таким образом удваивая количество времени обработки.
Иногда приложения позволяют пользователям вводить собственные шаблоны регулярных выражений для выполнения сервером. В этом случае злоумышленник может внедрить вредоносное регулярное выражение по своему выбору, а затем отправить строку ввода, которая заставит злонамеренное регулярное выражение выполняться в течение длительного времени.
Другой пример - при регистрации проверка, содержит ли пароль пользователя его имя. Если приложение вслепую использует имя пользователя как шаблон без очистки спецсимволов, например:
var r = new Regex(username, RegexOptions.IgnoreCase);Тогда злоумышленник может внедрить вредоносное регулярное выражение через поле имени пользователя:
var result = r.Match(password);
username: ^(a+)+$Способы борьбы с ReDoS:
password: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
1. Многопоточность и упреждающее уничтожение процессов. Многопоточное приложение может одновременно обрабатывать другие запросы, даже если вычисление регулярного выражения занимает слишком много времени. Также нужно останавливать выполнение любой оценки регулярного выражения, если она занимает больше времени, чем ожидалось.
2. Не стоит раскрывать ваши шаблоны регулярных выражений. Иногда они публикуются, потому что проект имеет открытый исходный код, или случайно, т.к. используются одни и те же шаблоны как в серверном, так и в клиентском коде. Это облегчает злоумышленникам поиск вредоносных регулярных выражений и создание соответствующих строк для атаки.
3. Избегайте использования опасных регулярных выражений для оценки пользовательского ввода (см. критерии выше) и вместо этого используйте более простые. Поищите проверенные и защищённые шаблоны вместо того, чтобы писать свои собственные.
4. Исключите возможность для пользователей предоставлять свои шаблоны регулярных выражений оценщику. Если вам нужна такая функциональность, используйте предварительно отформатированные регулярные выражения, которые допускают минимальную настройку.
Источник: https://sec.okta.com/articles/2020/04/attacking-evil-regex-understanding-regular-expression-denial-service
👍16
День 1279. #ЗаметкиНаПолях #AsyncTips
Связанные Запросы на Отмену
Подробнее про токены отмены см. «Скоординированная отмена».
Задача: в коде присутствует промежуточный уровень, который должен реагировать на запросы на отмену «сверху», а также выдавать собственные запросы на отмену на следующий уровень.
Решение
В .NET предусмотрена встроенная поддержка этого сценария в виде связанных токенов отмены. Источник токена отмены может быть создан связанным с одним (или несколькими) существующими токенами. Когда вы создаёте источник связанного токена отмены, полученный токен будет отменяться как при непосредственной отмене его, так и при отмене любого из связанных токенов.
Следующий пример выполняет асинхронный запрос HTTP. Токен
Хотя в примере выше используется только один токен
Например, ASP.NET предоставляет токен отмены, представляющий отключение пользователя. Код обработчика может создать связанный токен, который реагирует либо на отключение пользователя, либо на свои причины отмены (например, тайм-аут).
Помните о сроке существования источника связанного токена отмены. Предыдущий пример является наиболее типичным: один или несколько токенов отмены передаются методу, который связывает их и передаёт как комбинированный токен. Обратите внимание на то, что в примере используется команда using, которая гарантирует, что источник связанного токена отмены будет освобожден, когда операция будет завершена (а комбинированный токен перестанет использоваться). Подумайте, что произойдёт, если код не освободит источник связанного токена отмены: может оказаться, что метод
Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 10.
Связанные Запросы на Отмену
Подробнее про токены отмены см. «Скоординированная отмена».
Задача: в коде присутствует промежуточный уровень, который должен реагировать на запросы на отмену «сверху», а также выдавать собственные запросы на отмену на следующий уровень.
Решение
В .NET предусмотрена встроенная поддержка этого сценария в виде связанных токенов отмены. Источник токена отмены может быть создан связанным с одним (или несколькими) существующими токенами. Когда вы создаёте источник связанного токена отмены, полученный токен будет отменяться как при непосредственной отмене его, так и при отмене любого из связанных токенов.
Следующий пример выполняет асинхронный запрос HTTP. Токен
ct
, переданный методу GetWithTimeoutAsync
, представляет отмену, запрошенную конечным пользователем, а сам метод также применяет тайм-аут к запросу:async Task<HttpResponseMessage>Полученный токен
GetWithTimeoutAsync(
HttpClient client,
string url,
CancellationToken ct)
{
using var cts =
CancellationTokenSource
.CreateLinkedTokenSource(ct);
cts.CancelAfter(TimeSpan.FromSeconds(2));
var combinedToken = cts.Token;
return await client.GetAsync(url, combinedToken);
}
combinedToken
отменяется либо когда пользователь отменяет существующий токен ct
, либо при отмене связанного источника вызовом CancelAfter
.Хотя в примере выше используется только один токен
ct
, метод CreateLinkedTokenSource
может получать любое количество токенов отмены в своих параметрах. Это позволяет вам создать один объединённый токен, на базе которого можно реализовать собственную логику отмены. Например, ASP.NET предоставляет токен отмены, представляющий отключение пользователя. Код обработчика может создать связанный токен, который реагирует либо на отключение пользователя, либо на свои причины отмены (например, тайм-аут).
Помните о сроке существования источника связанного токена отмены. Предыдущий пример является наиболее типичным: один или несколько токенов отмены передаются методу, который связывает их и передаёт как комбинированный токен. Обратите внимание на то, что в примере используется команда using, которая гарантирует, что источник связанного токена отмены будет освобожден, когда операция будет завершена (а комбинированный токен перестанет использоваться). Подумайте, что произойдёт, если код не освободит источник связанного токена отмены: может оказаться, что метод
GetWithTimeoutAsync
будет вызван несколько раз с одним (долгосрочным) существующим токеном; в этом случае код будет создавать новый источник связанного токена при каждом вызове. Даже после того, как запросы HTTP завершатся (и ничто не будет использовать комбинированный токен), эти связанные источники будут оставаться присоединенными к существующему токену. Чтобы предотвратить подобные утечки памяти, освобождайте источник связанного токена отмены, когда комбинированный токен перестаёт быть нужным.Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 10.
👍4
Архитектура Rider и не только
DotNet & More
День 1280. #Подкаст
Сегодня предложу вам посмотреть/послушать эпизод подкаста DotNet&More #70: Архитектура Rider и не только. На чём написан Rider и другие продукты JetBrains? Кто работает над продуктом? Как команды справляются с объёмом кода? Чем разработка IDE отличается от обычной Enterprise разработки? В продолжение обсуждения вчерашнего квиза про то, зачем знать какие классы реализуют какие интерфейсы, ребята обсуждают, что нужно знать кандидату при устройстве в JetBrains, и чем требования отличаются от требований в обычных компаниях.
Честно признаюсь, я процентов 20 из того, что авторы обсуждали, не понял совсем. Это для меня какие-то высшие материи. Но всё равно интересно.
Можете посмотреть эпизод на ютуб, либо (надеюсь, ребята не обидятся на меня) послушать его прямо здесь.
Источник: https://t.iss.one/dotnetmore
Сегодня предложу вам посмотреть/послушать эпизод подкаста DotNet&More #70: Архитектура Rider и не только. На чём написан Rider и другие продукты JetBrains? Кто работает над продуктом? Как команды справляются с объёмом кода? Чем разработка IDE отличается от обычной Enterprise разработки? В продолжение обсуждения вчерашнего квиза про то, зачем знать какие классы реализуют какие интерфейсы, ребята обсуждают, что нужно знать кандидату при устройстве в JetBrains, и чем требования отличаются от требований в обычных компаниях.
Честно признаюсь, я процентов 20 из того, что авторы обсуждали, не понял совсем. Это для меня какие-то высшие материи. Но всё равно интересно.
Можете посмотреть эпизод на ютуб, либо (надеюсь, ребята не обидятся на меня) послушать его прямо здесь.
Источник: https://t.iss.one/dotnetmore
👍9👎2
День 1281. #ЧтоНовенького
Microsoft Прекратит Поддержку .NET Core 3.1
Долгосрочная поддержка (LTS) версии 3.1 Microsoft .NET Core Framework должна прекратиться 13 декабря 2022г. Microsoft рекомендует обновить приложения .NET Core 3.1 до .NET 6.0, чтобы поддерживать их в будущем. Однако у разработчиков неоднозначное отношение к политике поддержки .NET.
По словам Доминика Уиттакера, старшего менеджера программ в Microsoft, клиентам, использующим версию 3.1, следует перейти на .NET 6 или 7, чтобы по-прежнему получать официальную поддержку и исправления безопасности. Уиттакер объясняет, что приложения .NET Core 3.1 по-прежнему будут работать после окончания поддержки, но клиенты могут столкнуться с потенциальными недостатками безопасности, которые будут исправляться только для поддерживаемых версий.
Версия 3.1 — это то, что Microsoft называет выпуском с долгосрочной поддержкой (LTS), жизненный цикл поддержки которого составляет три года с даты выпуска. Текущие (не LTS) выпуски, такие как .NET 7.0, имеют более короткий жизненный цикл поддержки 18 месяцев, т.е. Microsoft будет поддерживать их в течение шести месяцев после выпуска следующей LTS версии.
Последней LTS-версией .NET является 6.0, которую Microsoft планирует поддерживать до 12 ноября 2024 года. В ноябре 2022 года планируется выпуск .NET 7.0 (не LTS версии), т.е. текущие клиенты .NET Core 3.1 могут выбрать между обновлением до .NET 6 или 7.
Обновление до .NET 6.0 включает изменение одной строки в файле проекта для изменения версии целевой платформы. Однако между .NET Core 3.1 и .NET 6.0 могут быть несовместимости среды выполнения или исходного кода.
Microsoft рекомендует разработчикам просмотреть официальное руководство по совместимости на наличие проблем при обновлении своих приложений и предоставляет инструмент обновления с открытым исходным кодом под названием upgrade-assistant. Инструмент анализирует код приложения, обновляет файлы проекта, проверяет наличие критических изменений и выполняет некоторые автоматические исправления кода, но разработчикам всё равно придётся делать некоторые исправления вручную.
Реакция сообщества разработчиков в социальных сетях была неоднозначной. Некоторые утверждают, что трёхлетний цикл поддержки слишком короток для корпоративных проектов, в то время как другие признают, что растущая сложность зависимостей кода делает частые обновления версий необходимостью и новым способом работы. Рокфорд Лхотка, создатель широко используемой среды приложений CSLA .NET, объясняет, что большая часть проблем при обновлении кода .NET связана с переходом от старой .NET Framework на современную инфраструктуру .NET, в то время как обновления между версиями .NET Core существенно менее трудоёмки.
Майкрософт регулярно публикует сводные данные об использовании .NET SDK. По данным на июнь 2022 года, наиболее используемой версией является именно .NET Core 3.1, на которую приходится 31%.
Источник: https://www.infoq.com/news/2022/07/microsoft-dotnet/
Microsoft Прекратит Поддержку .NET Core 3.1
Долгосрочная поддержка (LTS) версии 3.1 Microsoft .NET Core Framework должна прекратиться 13 декабря 2022г. Microsoft рекомендует обновить приложения .NET Core 3.1 до .NET 6.0, чтобы поддерживать их в будущем. Однако у разработчиков неоднозначное отношение к политике поддержки .NET.
По словам Доминика Уиттакера, старшего менеджера программ в Microsoft, клиентам, использующим версию 3.1, следует перейти на .NET 6 или 7, чтобы по-прежнему получать официальную поддержку и исправления безопасности. Уиттакер объясняет, что приложения .NET Core 3.1 по-прежнему будут работать после окончания поддержки, но клиенты могут столкнуться с потенциальными недостатками безопасности, которые будут исправляться только для поддерживаемых версий.
Версия 3.1 — это то, что Microsoft называет выпуском с долгосрочной поддержкой (LTS), жизненный цикл поддержки которого составляет три года с даты выпуска. Текущие (не LTS) выпуски, такие как .NET 7.0, имеют более короткий жизненный цикл поддержки 18 месяцев, т.е. Microsoft будет поддерживать их в течение шести месяцев после выпуска следующей LTS версии.
Последней LTS-версией .NET является 6.0, которую Microsoft планирует поддерживать до 12 ноября 2024 года. В ноябре 2022 года планируется выпуск .NET 7.0 (не LTS версии), т.е. текущие клиенты .NET Core 3.1 могут выбрать между обновлением до .NET 6 или 7.
Обновление до .NET 6.0 включает изменение одной строки в файле проекта для изменения версии целевой платформы. Однако между .NET Core 3.1 и .NET 6.0 могут быть несовместимости среды выполнения или исходного кода.
Microsoft рекомендует разработчикам просмотреть официальное руководство по совместимости на наличие проблем при обновлении своих приложений и предоставляет инструмент обновления с открытым исходным кодом под названием upgrade-assistant. Инструмент анализирует код приложения, обновляет файлы проекта, проверяет наличие критических изменений и выполняет некоторые автоматические исправления кода, но разработчикам всё равно придётся делать некоторые исправления вручную.
Реакция сообщества разработчиков в социальных сетях была неоднозначной. Некоторые утверждают, что трёхлетний цикл поддержки слишком короток для корпоративных проектов, в то время как другие признают, что растущая сложность зависимостей кода делает частые обновления версий необходимостью и новым способом работы. Рокфорд Лхотка, создатель широко используемой среды приложений CSLA .NET, объясняет, что большая часть проблем при обновлении кода .NET связана с переходом от старой .NET Framework на современную инфраструктуру .NET, в то время как обновления между версиями .NET Core существенно менее трудоёмки.
Майкрософт регулярно публикует сводные данные об использовании .NET SDK. По данным на июнь 2022 года, наиболее используемой версией является именно .NET Core 3.1, на которую приходится 31%.
Источник: https://www.infoq.com/news/2022/07/microsoft-dotnet/
👍9
День 1282. #ЗаметкиНаПолях
Исправляем Отсутствующий Источник Пакетов NuGet
Иногда после настройки системы с нуля, установки Visual Studio и создания нового проекта при сборке проекта может возникать ошибка NU1101, говорящая о том, что восстановление пакета не удалось. Например:
NU1101 Unable to find package Swashbuckle.AspNetCore. No packages exist with this id in source(s): Microsoft Visual Studio Offline Packages
В настройках менеджера пакетов NuGet во вкладке Package Sources (Источники Пакетов) при этом будет отсутствовать источник по умолчанию Nuget.org.
Как это исправить?
Существует три файла конфигурации NuGet.Config доступные для Visual Studio, которые можно использовать для управления источниками NuGet:
1. Файл конфигурации, локальный для проекта или решения. Размещается соответственно в папке проекта или решения.
2. Файл конфигурации для конкретного пользователя для всех проектов пользователя. Размещение:
- в Windows:
- в Mac/Linux:
3. Общесистемная конфигурация, влияющая на всех пользователей на компьютере. Размещение:
- в Windows:
- в Mac/Linux:
Эти файлы конфигурации применяются иерархически. Источники, специфичные для проекта, переопределяют конфигурацию пользователя, а настройки пользователя, переопределяют общесистемные.
Собственно, в файл в раздел
Источник: https://blog.nimblepros.com/blogs/fix-missing-default-nuget-feed/
Исправляем Отсутствующий Источник Пакетов NuGet
Иногда после настройки системы с нуля, установки Visual Studio и создания нового проекта при сборке проекта может возникать ошибка NU1101, говорящая о том, что восстановление пакета не удалось. Например:
NU1101 Unable to find package Swashbuckle.AspNetCore. No packages exist with this id in source(s): Microsoft Visual Studio Offline Packages
В настройках менеджера пакетов NuGet во вкладке Package Sources (Источники Пакетов) при этом будет отсутствовать источник по умолчанию Nuget.org.
Как это исправить?
Существует три файла конфигурации NuGet.Config доступные для Visual Studio, которые можно использовать для управления источниками NuGet:
1. Файл конфигурации, локальный для проекта или решения. Размещается соответственно в папке проекта или решения.
2. Файл конфигурации для конкретного пользователя для всех проектов пользователя. Размещение:
- в Windows:
%appdata%\NuGet\NuGet.Config
,- в Mac/Linux:
~/.config/NuGet/NuGet.Config
либо ~/.nuget/NuGet/NuGet.Config
(по-разному в разных дистрибутивах).3. Общесистемная конфигурация, влияющая на всех пользователей на компьютере. Размещение:
- в Windows:
%ProgramFiles(x86)%\NuGet\Config
,- в Mac/Linux:
$XDG_DATA_HOME
. Если $XDG_DATA_HOME
пустой, ~/.local/share
либо /usr/local/share
(по-разному в разных дистрибутивах).Эти файлы конфигурации применяются иерархически. Источники, специфичные для проекта, переопределяют конфигурацию пользователя, а настройки пользователя, переопределяют общесистемные.
Собственно, в файл в раздел
packageSources
нужно добавить строку со ссылкой на api.nuget.org
, как показано ниже:<?xml version="1.0" encoding="utf-8"?>После изменения файла перезапустите Visual Studio и пересоберите решение. Нужные пакеты NuGet теперь должны восстановиться из указанного источника.
<configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
</packageSources>
</configuration>
Источник: https://blog.nimblepros.com/blogs/fix-missing-default-nuget-feed/
👍9