• .NET 5.0 Preview 3 и Runtime
• Образы Docker
• Snap-установщик

• Установщики Windows и macOS
• Полный список
• Образы Docker
• Snap-установщик

• .NET 5.0 — заметки о версии
• .NET 5.0 — известные проблемы
• Выпуск на GitHub
• Трекер проблем на GitHub

• Установщики
• Образы
• Snap-установщик
• Заметки о выпуске
• Известные проблемы
• Трекер проблем на GitHub

17 ноября Apple официально представила устройства на базе своего нового ARM-процессора Apple M1. Естественно, это событие не могло быть не замечено со стороны компании Microsoft, которая с 2014 года начала активную экспансию .NET на новые платформы. Давайте посмотрим, что нас ждет в связи с этим в ближайшее время!

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

Не секрет, что Telegram является на данный момент одним из самых популярных мессенджеров. Особенно в среде ИТ-специалистов. Он удобен, в нем нет встроенной рекламы и работает весьма стабильно. Довольно большую часть времени я общаюсь как по работе, так и по личным вопросам именно в этом мессенджере. Поэтому в один прекрасный день я подумал о том, что было бы удобно, чтобы в этом же мессенджере я мог получать уведомления о работе некоторых своих сервисов. На тот момент я как раз активно работал над интеграцией проекта //devdigest и Telegram, поэтому используя тот же родной Telegram Bot SDK довольно быстро реализовал логгер.

Несколько дней назад я решил вернуться к этому проекту, слегка почистить и отрефакторить код, а затем выложить его в открытый доступ – быть может возможность получения логов в Телеграм будет полезна кому-то еще. Если этот кто-то – вы, то

С выпуском .NET 5 миграция решений из .NET Framework увеличилась. В частности, мы начали наблюдать перемещение очень крупных решений. Чтобы обеспечить максимальное удобство, мы работали над оптимизацией Visual Studio для обработки решений, содержащих большое количество проектов .NET 5 и .NET Core. Многие из этих оптимизаций были включены в версию 16.8, и в этом посте рассматриваются внесенные нами улучшения.

Сегодня мы собираемся показать вам, как начать парсинг аргументов командной строки. Кстати, это один пост из серии статей о .NET 5. У нас есть еще много интересного.

Приложения командной строки, также известные как консольные приложения, - это программы, созданные для использования из оболочки, например cmd или bash. Они существуют с 1960-х годов, задолго до появления Windows, MacOS или любого другого графического пользовательского интерфейса (GUI).

Обычно, когда вы начинаете изучать язык программирования, самый простой и распространенный стартовый пример -- это приложение Hello world. Подобные примеры в основном выводят на консоль только текст «Hello world», используя свои встроенные API. Компьютерное ПО может делать много разных вещей. Иногда у вас будет ввод, который каким-то образом преобразуется в вывод. В нашем примере «Hello world» нет никакого ввода.

Недавно, когда я просматривал новые возможности, которые будут включены в .Net 5, я натолкнулся на одну весьма интересную — генераторы исходного кода. Этот функционал меня особенно заинтересовал, так как я использую аналогичный подход в течение последних… 5 лет, и то, что предлагает Microsoft — это просто более глубокая интеграция этого подхода в процесс сборки проектов.

Примечание: Оригинал был написан в момент, когда релиз .Net 5 только-только собирался выйти, но актуальности этот текст, на мой взгляд, не потерял, поскольку переход на новую версию платформы занимает какое-то время, да и принципы работы с Roslyn никак не поменялись.

Далее я поделюсь своим опытом использования Roslyn при генерации кода, и надеюсь, что это поможет вам лучше понять, что именно предлагает Microsoft в .Net 5 и в каких случаях это можно использовать.

Some of the features of your website require message queue integration. It is not a complex task for most developers. If you work with Azure infrastructure, you are able to choose Azure Service Bus as a queue engine. It sounds quite simple: just create Azure Resource, write some code and then be happy! But what would you say if the resources are limited? What will you do if there are several teammates in your team, and all of you have to debug queues at the same time? I try to give you a simple solution.

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

В чём проблема и как решить?

Building console application can produce an unexpectedly much larger file than you would think due to implicit references.

What is the problem and how it can be solved?

Одной из первых задач для большинства бизнес-приложений на ASP.NET Core является реализация операций CRUD (Create, Read, Update, Delete) для основных объектов, с которыми работает ваше решение.

Каждый разработчик, которому нужно решить эту задачу, знает, что создание CRUD-страниц и форм — очень скучный и трудоемкий процесс.

Если делать это вручную, то получится очень медленно и наверняка с кучей недоработок (пропущенные поля, забытые валидаторы и т.д.).

Можно воспользоваться инструментом scaffolding'а, доступным в Visual Studio. Но даже в этом случае это будет совсем не быстрый процесс, поскольку его нужно запускать для каждого класса модели. В итоге вы получаете множество .cs/.cshtml файлов, которые нужно поддерживать и атуализировать по мере изменений в классах модели или просто когда нужно что-то исправить в поведении или внешнем виде CRUD страниц. Если количество сущностей в вашей БД превышает десяток, то весьма велики шансы того, что файлы для реализации CRUD операций занимают больше 50% всей кодовой базы вашего проекта. Более того это решение все равно не обеспечивает некоторых важных, а порой и необходимых функций, таких как разбитие на страницы в режиме просмотра (pagination) или банальные поиск/фильтрация.

Решение: использовать библиотеку с открытым кодом EasyData, о которой и пойдет речь в данной статье.

Наша команда занимается развитием корпоративной системы электронного документооборота. В команде часть приложений разрабатывается на текущей LTS версии .NET Core 3.1, в частности, бэкэнд для SPA, а также ряд Worker Service’ов, которые с определенным интервалом взаимодействуют с СЭД.

Со временем, возникла необходимость использования этими приложениями общих мастер-данных. Для их хранения решили использовать БД PostgreSQL, так как имели свежий опыт и почти готовое окружение для его развертывания. Непосредственно для получения (а в будущем – и для записи) данных приложениями, решили реализовать Web API на .NET Core 3.1, чтобы инкапсулировать взаимодействие с БД в одном приложении и заложить возможность взаимодействия с любой системой. В качестве ORM, исходя из сложившихся практик и опыта, использовали EF Core. При этом, нужна была возможность фильтрации и получения связанных данных. Чтобы не придумывать велосипед в этой части, пришли к необходимости реализации API на основе стандартов OData.

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

В предыдущей статье было описано создание Web API OData на .NET Core с акцентом на особенности реализации связи "многие-ко-многим".

В данной статье хотели бы коснуться реализации методов контроллера для одной из моделей, описанных в предыдущей статье. Как правило, статьи по реализации API OData на .NET Core содержат всего пару примеров – получение всех сущностей и получение одной сущности по ее ID.

Мы постараемся дать больше образцов кода для написания методов, которые позволяют осуществлять основные манипуляции с данными в рамках требований OData.

Спустя некоторое время я увидел интересный метод "12 проектов за 12 месяцев". Суть метода состоит в том, что ты каждый месяц делаешь 1 продукт и показываешь его людям. Неважно насколько он готов.

Regexoop - переосмысление подхода написания regex. 30 сентября я подумал - "Хм, regex такой сложный. НУ ПОЧЕМУ? Может его можно сделать как-то проще?".