Папка dotnet что это

Папка dotnet что это

February 22, 2018 | 17 Minute Read

В последнее время в компании Microsoft произошло много изменений. Поддержка Docker контейнеров в Windows Server 2016, нативное подключение через SSH в CMD (ура! можно забыть о PuTTY!), изменения в рендоре консоли в Windows, Unix решения для Azure, поддержка Pyton в Visual Studio, мощьный открытый редактор Visual Studio Code и Visual Studio для Mac OS . Microsoft действительно стала "ближе" к Unix , ближе к Open Source. Конечно не осталась в стороне и платформа .NET. Тут тоже произошло много приятных подвижек и нововведений. Если раньше C# + Linux был уделом энтузиастов, то теперь — это прекрасная альтернатива Java. Именно об этих технологиях и будут написано несколько моих следующих статей. Но сначала давайте разберемся с точками в .NET.

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

Среда .NET.

Перед тем как углубляться в детали, обсудим среду .NET в целом и место, которое в ней занимают .NET Core и .NET Standard.

Рис 1. (Структура .NET. Отличия.)

Платформа .NET Framework появилась 15 лет назад(!). Тогда в её состав входил только один стек технологий .NET, с помощью которого можно было разрабатывать приложения для ПК под управлением Windows и веб-приложения. Но шло время и с тех пор появились и другие реализации .NET, например, Xamarin для разработки мобильных приложений для iOS и Android и классических приложений для macOS. Потом пришел mono фреймворк, появилась идея о .NET vNext в 2014г. Стало понятно, что классический .NET Freamwork не обладает должной гибкостью. Так возникла идея о стандартизации базовых API.

Какое же место здесь занимают .NET Core и .NET Standard?

  • .NET Core — это самая новая реализация .NET. Это проект Open Source с версиями для нескольких ОС. .NET Core позволяет создавать кроссплатформенные консольные приложения, а также приложения и облачные службы ASP.NET Core.
  • .NET Standard — это набор базовых API (другое их название — BCL, библиотека базовых классов), которые должны поддерживаться во всех реализациях .NET. .NET Standard позволяет создавать библиотеки, подходящие для любых приложений .NET, вне зависимости от реализации .NET или операционной системы, в которой они выполняются.

Рис 2. (Среда .NET.)

.NET Core

.NET Core — это открытая универсальная платформа разработки, которая поддерживается корпорацией Майкрософт и сообществом .NET на сайте GitHub. Она является кроссплатформенной, поддерживает Windows, Mac OS и Linux и может использоваться на устройствах, в облаке, во внедренных системах и в сценариях IoT (Интернета вещей). В её основе лежат технологии .NET Framework и Silverlight. Она оптимизирована для мобильных и серверных рабочих нагрузок, поскольку обеспечивает поддержку самодостаточных развёртываний XCOPY.

Чтобы лучше понять, что такое .NET Core, давайте попробуем разработать небольшое приложение для .NET Core. При этом мы познакомимся с новыми программами командной строки. Разрабатывать решения .NET Core можно в Visual Studio 2017, но раз уж вы читаете эту статью, я предположу, что с Visual Studio вы знакомы неплохо, и буду рассказывать в первую очередь о новых возможностях.

При создании .NET одним из главных приоритетов была высокая скорость разработки приложений для Windows. На практике это означает, что разработка .NET была неразрывно связана с Visual Studio. Безусловно, Visual Studio — замечательный инструмент. Он позволяет работать эффективно, а его отладчик — однозначно лучший из тех, которые мне доводилось использовать.

Но в некоторых случаях Visual Studio — не самый удобный вариант. Допустим, вы хотите поэкспериментировать с .NET, чтобы изучить C#. Для этого не хотелось бы скачивать и устанавливать IDE объемом в несколько гигабайт… Ладно, существует Sharp Develop , скажите вы. Но, допустим, вы подключаетесь к компьютеру с Linux через SSH? Тогда работать через IDE вообще не получится. А может быть, вам просто нравится командная строка?

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

Пример 1

Для начала создадим и запустим консольное приложение Hello World (я буду использовать PowerShell для Windows, но в Bash для macOS или Linux все делается аналогично).

Команда dotnet new делает то же самое, что элемент меню File – New Project в Visual Studio. С её помощью можно создавать проекты различных типов. Используйте команду dotnet new , чтобы вывести список предустановленных шаблонов.

Давайте переместим часть логики в библиотеку классов. Для этого в дополнение к проекту hello создадим проект библиотеки классов.

Здесь мы хотим описать логику, которая будет формировать сообщение Hello World. Поэтому изменим содержимое файла Class1.cs на следующее:

Переименуем файл Class1.cs в HelloWorld.cs .

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

Чтобы использовать класс HelloWorld , нужно добавить в приложение hello ссылку на библиотеку, в которой содержится логика. Для этого можно изменить файл проекта или воспользоваться командой dotnet add reference .

Теперь изменим файл Program.cs так, чтобы в нем использовался класс HelloWorld .

Обновление файла Program.cs для дальнейшего использования класса HelloWorld:

Чтобы собрать и запустить приложение, введите команду dotnet run .

В командной строке также можно создавать тесты. Этот CLI поддерживает MSTest , а также популярную платформу xUnit . Давайте для примера воспользуемся xUnit.

Чтобы добавить тест, измените содержимое файла UnitTest1.cs , как показано ниже.

Добавление теста в файл UnitTest1.cs:

Теперь можно запустить тесты с помощью команды dotnet test .

Пример 2

Рассмотрим более интересный пример: создадим простой веб-сайт ASP.NET Core.

Измените вызов app.Run в файле Startup.cs так, чтобы в нём использовался класс HelloWorld .

Чтобы запустить тестовый веб-сервер, вновь введите команду dotnet run .

Откройте в браузере URL-адрес, который был выведен в консоли (это должен быть адрес localhost:5000).

Сейчас структура вашего проекта должна соответствовать вот такой структуре.

Структура созданного проекта:

Чтобы упростить редактирование файлов в Visual Studio, создадим файл решения *.SIN и добавим в него все проекты.

Как видите, .NET Core CLI — мощный и удобный инструмент, который покажется привычным даже тем разработчикам, которые никогда раньше не работали с .NET.

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

.NET Standard

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

Платформа ОС Open Source Назначение
.NET Framework Windows Нет Создание классических Windows-приложений и веб-приложений ASP.NET для IIS.
.NET Core Windows, Linux, macOS Да Создание кроссплатформенных консольных приложений, а также веб-приложений и облачных служб ASP.NET Core.
Xamarin iOS, Android, macOS Да Создание мобильных приложений для iOS и Android, классических приложений для macOS.
.NET Standard любая Да Создание библиотек, которые можно использовать в любых реализациях .NET, в том числе .NET Framework, .NET Core и Xamarin.

Создание библиотек, которые можно использовать в любых реализациях .NET, в том числе .NET Framework, .NET Core и Xamarin.

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

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

Возможно, вы задаетесь вопросом, какие именно API входят в .NET Standard. Если вы знакомы с платформой .NET Framework, то¬, наверное, знаете про библиотеку BCL — мы ее уже упоминали.

BCL — это набор базовых API, не зависящих от инфраструктур пользовательского интерфейса и моделей приложений. В него входят простые типы, файловый ввод-вывод, сетевые API, API сериализации, XML и другое.

Читайте также:  Замена цепи грм опель мерива 1 4

Каждый стек .NET реализует определенную версию .NET Standard. Обычно каждая новая версия реализации .NET реализует самую последнюю (на этот момент) версию .NET Standard.

Хорошая аналогия — язык HTML и браузеры. Представьте, что спецификация HTML — это .NET Standard, а различные браузеры — это реализации .NET (например, .NET Framework, .NET Core и Xamarin).

Пример 3

Вероятно, вы уже задаетесь вопросом, как можно пользоваться .NET Standard . На самом деле мы им уже воспользовались, когда создавали библиотеку с классом логики. Давайте взглянем на файл проекта внимательнее.

Сравним его с файлом проекта консольного приложения hello.

Как видите, для параметра TargetFramework библиотеки логики задано значение netstandard2.0 , а для соответствующего параметра консольного приложения — значение netcoreapp2.0 . Параметр TargetFramework соответствует целевой версии реализации .NET. Таким образом, целевая реализация для консольного приложения — .NET Core 2.0, а для библиотеки — .NET Standard 2.0. Это значит, что к библиотеке логики можно обращаться не только из приложения .NET Core, но и из приложения для .NET Framework или Xamarin.

.NET Framework и .NET Standard. Совместимость.

К сожалению, для большей части современных библиотек целевой реализацией является не .NET Standard, а .NET Framework. Конечно, .NET Standard в качестве целевой версии подходит не для всех библиотек, и это совершенно нормально. Например, целевой реализацией для библиотеки, в которой содержатся элементы управления Windows Presentation Foundation (WPF), должна быть .NET Framework, потому что компоненты пользовательского интерфейса не являются частью стандарта. Однако с большей частью библиотек общего назначения ситуация другая: для них целевой реализацией является .NET Framework просто потому, что на момент их создания .NET Standard еще не существовало. И тут мы сталкиваемся с проблемой нехватки компонентов. Но Microsoft элегантно решила данную проблему.

В .NET Standard 2.0 уже содержится достаточно большой набор API для того, чтобы в подавляющей части библиотек общего назначения в качестве целевой реализации можно было использовать .NET Standard. В 70% библиотек, доступных сегодня в NuGet, используются только API, входящие в .NET Standard. Однако лишь немногие из них явным образом отмечены как совместимые с .NET Standard.

Чтобы разработчики могли использовать не только их, был добавлен режим совместимости. Если вы устанавливаете пакет NuGet, в котором нет библиотеки ни для вашей целевой платформы, ни для .NET Standard, то NuGet попробует использовать .NET Framework в качестве резервного варианта. Другими словами, вы можете обращаться к библиотекам .NET Framework так, как если бы для них в качестве целевой реализации был указан .NET Standard.

Так например, в процессе разработки проекта под Linux на C# мне пришлось общаться с базой данных MySQL. Для этого я использовал совместимую только с .NET Framework 4.6 библиотеку. Но проект успешно собрался под Linux и библиотека отработала на "ура".

Пример 4

Давайте посмотрим, как это работает. В моем примере мы использовали популярную библиотеку коллекций PowerCollections , которая была создана в 2007 году (верните мне мой 2007-ой). Она долго не обновлялась, и в качестве целевой платформы для нее по-прежнему указана .NET Framework 2.0(!). Добавим ее через NuGet в приложение hello .

Эта библиотека поддерживает дополнительные типы коллекций, которых нет в BCL. Один из них — тип Bag , не гарантирующий какого-либо порядка элементов. Изменим наше приложение hello так, чтобы в нем использовался этот тип.

Пример приложения с использованием PowerCollections:

Если вы запустите программу, то увидите следующее:

Компилятор выкинул warning но программа отработала!

Что же произошло? Целевой реализацией для приложения hello является платформа .NET Core 2.0. .NET Core 2.0 является одной из реализаций .NET Standard 2.0, поэтому она поддерживает режим совместимости для обращения к библиотекам .NET Framework. Однако некоторые библиотеки .NET Framework в определенных реализациях .NET работать не будут. Например, это библиотеки, в которых используются API Windows Forms или WPF . NuGet не может об этом знать, поэтому он выдает сообщение с предупреждением о возможных проблемах.

Конечно, неустранимые предупреждения, которые выводятся при каждой сборке, очень раздражают (а точнее БЕСЯТ!). Поэтому после проверки приложения вы можете отключить предупреждение, связанное с конкретным пакетом. Наше приложение работает правильно (корректно выводит содержимое созданной коллекции типа Bag ), поэтому сейчас мы отключим это сообщение. Для этого изменим файл hello.csproj и добавим атрибут NoWarn в ссылку на пакет.

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

В новых проектах поддерживается возможность задать несколько целевых платформ и выполнить сборку одного проекта для нескольких реализаций .NET. Это значит, что вы можете адаптировать библиотеку к конкретным реализациям .NET с помощью механизма условной компиляции ( #if ). Также вы можете создавать оболочки .NET Standard для API, относящихся к конкретным платформам. Но это уже совсем другая история.

Еще новый набор инструментов позволяет создавать пакеты NuGet в процессе сборки проектов — библиотек классов . Таким образом можно легко предоставить доступ к библиотекам неограниченному числу пользователей (достаточно просто выложить их на nuget.org) или только сотрудникам вашей организации (для этого добавьте их в вашу ленту пакетов в Visual Studio Team Services или в MyGet).

Заключение

.NET Standard представляет собой спецификацию API, которые должны содержаться во всех реализациях .NET. Он делает семейство технологий .NET более организованным и позволяет разработчикам создавать библиотеки, которые можно использовать в любой реализации .NET. Этот стандарт заменяет библиотеки PCL в роли механизма создания общих компонентов.

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

На сегодняшний день C# стал полностью кроссплатформенным языком, что конечно не может не радовать! Я лишь буду ждать и наедятся на то, что Java побыстрее умрет))) Смерть жабе!

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

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

DotNet — новая инициатива Microsoft, направленная на изменение компьютерного мира. Если говорить подробнее, то это набор нескольких технологий, программного обеспечения, стандартов и средств разработки. Основное преимущество dotNet для потребителя — реализация единого информационного пространства, соединяющего его с компьютерами и программами, а также ПО между собой. Разработчикам же она позволяет просто и быстро создавать нужные продукты.

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

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

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

Следующим шагом стала реализация средств для обеспечения совместной работы, например Lotus Notes и Exchange, которые одновременно служили и платформами для разработки.

Затем вошли в обиход продукты, обеспечивающие доставку сообщений (Message Oriented Middleware), такие как IBM MQSeries и MSMQ. Они позволили организовать обмен сообщениями в распределенной системе, имеющей разнородные (и подчас ненадежные) каналы связи. Их отличие от почтовых серверов заключается в том, что они ориентированы на обмен информацией не между людьми, а между различными частями программных систем.

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

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

Описанные выше продукты, хотя и содержат довольно много новшеств, все же являются развитием существующих технологий. Действительно новой технологией dotNet стали Web-сервисы, реализация которых создает в Сети среду автоматизированного ведения бизнеса.

Читайте также:  Opcache max accelerated files htaccess

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

Удобная и эффективная для пользователей, технология dotNet имееет неоспоримые преимущества и для разработчиков программных продуктов. Программистам dotNet позволяет создавать мощные информационные системы, использующие все возможности современных компьютеров и сетей без реализации вспомогательных функций (практически все эти функции берет на себя платформа). Она позволяет сосредоточится только на реализации бизнес-логики продукта. Следовательно, создатели программ будут способны быстро создавать качественные (и простые!) программы, имеющие множество возможностей, интегрированных c интернетом, столь необходимые пользователям. Это ведет к улучшению и удешевлению ПО, а также к уменьшению количества ошибок.

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

Microsoft .NET позволит создавать по-настоящему распределенные Web-службы, которые будут интегрироваться и совместно работать с целым набором дополнительных сервисов, чтобы обслуживать клиентов так, как сегодняшние компании могут только мечтать.

Microsoft .NET является одной из самых приоритетных технологий, используемых компанией Novosoft LLC. Microsoft .NET активно используется Новософтом для создания интегрированных информационных систем, Веб сайтов, новостных порталов и других софтверных решений для предприятий с различными направлениями деятельности.

В этой статье используются предварительные версии DotNet CLI и инструментария EF. Любая информация, изложенная в этой статье, может быть изменена.

Технология, ранее известная как Entity Framework 7 (EF7), в начале 2016 года была переименована в Entity Framework Core (EF Core). В EF Core 1.0.0 вводятся некоторые грандиозные новые возможности, хотя в целом она имеет меньший набор функциональности, чем EF6. Но это не означает, что EF работает только в .NET Core. Вы можете использовать EF Core в API и приложениях, требующих полной .NET Framework, а также в программном обеспечении, ориентированном только на кросс-платформенную .NET Core. В этой статье я проведу вас по двум проектам, в которых исследуются эти варианты. Моя цель — снять все озабоченности, ассоциируемые с приставкой «Core»: дескать, EF Core работает только в .NET Core. Попутно я объясню этапы создания каждого решения.

EF Core в проектах для полной .NET

Я начну с проекта, ориентированного на полную .NET Framework. Учтите, что в Visual Studio 2015 нужный инструментарий требует наличия Visual Studio 2015 Update 3, а также новейшей версии расширения Microsoft ASP.NET and Web Tools. На момент написания этой статьи (август 2016 года) лучшим руководством по их установке была документация (bit.ly/2bte6Gu).

Чтобы отделить доступ к данным от операций над ними, которые будет выполнять приложение, я создам свою библиотеку классов. На рис. 1 видно, что можно выбрать шаблон, специально ориентированный на библиотеку классов для .NET Core, но я выбираю Class Library — стандартный вариант, который всегда был доступен для .NET. Полученный проект (рис. 2) тоже является «обычным»: в нем нет никаких файлов project.json или любых ресурсов проекта для .NET Core. Все выглядит так же, как и всегда.


Рис. 1. Создание библиотеки классов для полной .NET


Рис. 2. Обычная (и привычная) библиотека классов для .NET

Пока ничто никак не связано с EF. Я могла бы выбрать EF6 в этот момент, но добавлю EF Core в проект. Как всегда, для поиска и выбора EF Core можно использовать либо NuGet Package Manager, либо окно Package Manager Console. Я буду использовать консоль. Помните, что пакет entityframework предназначен для EF6. Чтобы получить EF Core, вы должны установить один из пакетов Microsoft.EntityFrameworkCore. Я выберу пакет SqlServer, в котором есть все необходимое для взаимодействия EF с SqlServer:

Так как этот пакет зависит от основного пакета Microsoft.EntityFrameworkCore, а также от пакета Microsoft.EntityFrameworkCore.Relational, NuGet автоматически установит их за меня. А поскольку пакет EF Core зависит от других пакетов, они тоже будут установлены. Всего этот процесс добавляет три пакета EF Core и 23 других из более новой модульной .NET, на которую полагается EF Core. Вместо меньшего количества крупных пакетов я получаю больше малых пакетов, но только тех, которые реально нужны моему приложению. Все они нормально работают со стандартными .NET-библиотеками, уже находящимися в проекте.

Затем я добавлю простой класс предметной области (Samurai.cs) и DbContext (SamuraiContext.cs), чтобы EF Core могла сохранять мои данные в базе данных, как показано на рис. 3. В EF Core нет магической строки подключения, как в EF6, поэтому я должна дать знать, какой провайдер и какую строку подключения я использую. Для простоты я включу это прямо в новый виртуальный метод DbContext: OnConfiguring. Я также создала перегруженную версию конструктора, позволяющую передавать провайдер и другие необходимые детали. Вскоре я воспользуюсь этой версией.

Рис. 3. Класс Samurai и DbContext-класс SamuraiContext

Поскольку я использую полную .NET, а это также означает, что я ориентируюсь на полнофункциональную версию Windows, мне доступна Windows PowerShell. То есть в моем распоряжении есть те же команды миграции, которые я всегда использовала: add-migration, update-database и т. д. Также появились некоторые новые команды, и вы можете узнать о них в моей статье за январь 2016 года (msdn.com/magazine/mt614250). Кроме того, помните мое упоминание о том, что пакеты имеют меньший размер и их можно составлять как модули? Что ж, если я хочу использовать миграции, мне нужно добавить пакет, содержащий эти команды. На момент написания этой статьи весь инструментарий все еще находился на стадии предварительных версий, так что придется указать параметр –pre. Добавив этот пакет, я смогу добавить новую миграцию:

Это работает, как обычно: создаются новая папка Migrations и файл миграции (рис. 4). В EF Core изменен способ сохранения снимков модели (model snapshots), о чем можно прочитать в ранее упомянутой статье за январь 2016 года.


Рис. 4. Миграции EF Core в моей библиотеке классов для полной .NET

После подготовки миграций команда update-database успешно создает за меня новую базу данных EFCoreFullNet в SQL Server localdb.

Наконец, я добавлю в решение тестовый проект из того же шаблона проекта Unit Test, которым я всегда пользовалась в Visual Studio. Затем добавлю ссылку на свою библиотеку классов EFCoreFullNet. Мне не нужно, чтобы мой тестовый проект использовал базу данных для проверки работы EF Core, поэтому вместо установки пакета SqlServer я выполню следующую NuGet-команду применительно к новому тестовому проекту:

Провайдер InMemory — настоящая благодать для тестирования при применении EF Core. Он использует данные в памяти для представления базы данных и кеша EF, а EF Core будет взаимодействовать с этим кешем во многом так же, как с базой данных: добавлять, удалять и обновлять данные.

Помните тот дополнительный конструктор, созданный мной в SamuraiContext? Тесты TestEFCoreFullNet, приведенные на рис. 5, используют его преимущества. Заметьте, что в конструкторе класса теста я создала средство формирования (builder) DbContextOptions для SamuraiContext, а затем указала, что он должен использовать провайдер InMemory. Далее при создании экземпляра SamuraiContext я передаю в метод эти параметры (options). Метод OnConfiguring в SamuraiContext предназначен для проверки того, сконфигурированы ли уже параметры. Если да, он будет использовать их (в данном случае провайдер InMemory), нет — он перейдет к настройке на работу с SqlServer и строкой подключения, «зашитой» мной в код метода.

Рис. 5. Тестирование с помощью EFCore

Этот метод теста используется преимущества некоторых специфических средств EF Core, которых нет в EF6. Я писала об этих и других средствах отслеживания изменений в EF Core в своей статье за август 2016 года (msdn.com/magazine/mt767693). Например, после создания нового объекта самурая я добавляю его в контекст методом DbContext.Add, позволяя EF определить, с каким DbSet его нужно связать. Затем я сохраняю это в хранилище данных — в моем случае список какого-либо типа в памяти, управляемый провайдером InMemory. Далее я модифицирую объект самурая, создаю новый экземпляр DbContext и использую новую команду Update из EF Core, чтобы SaveChanges гарантированно обновил хранящийся объект самурая, а не создал новый такой объект. Наконец, я запрашиваю контекст для этого самурая и применяю Assert, чтобы убедиться, что контекст действительно возвращает обновленное имя.

Однако описание используемых мной конкретных средств было бы отклонением от темы статьи. Суть в том, что я проделываю всю эту работу с помощью EF Core в проекте для обычной старой .NET в Windows.

EF Core для CoreCLR: тот же код, разные зависимости

Я могла бы остаться в Windows и Visual Studio 2015 Update 3 для следующей демонстрации, где показала бы, как использовать те же EF Core API, тот же код и те же тесты с ориентацией на исполняющую среду CoreCLR, но это выглядело бы слишком похоже на первый вариант — для Windows. Поэтому я собираюсь впасть в другую крайность и создать CoreCLR-вариацию на своем MacBook, поясняя все этапы по мере их прохождения.

Читайте также:  Вега эп 110 стерео инструкция по эксплуатации

.NET Core не полагается на Windows или ее инструментарий. Помимо Visual Studio 2015, я могла бы использовать… ну, я полагаю, Emacs в прошлом был популярным редактором, отличным от Visual Studio. Однако существуют некоторые кросс-платформенные IDE, из которых есть, что выбрать, — не только для написания кода, но и для отладки и поддержки Git. Например, в номере «MSDN Magazine» за август 2016 года Алессандро Дель Соле (Alessandro Del Sole) продемонстрировал создание веб-сайта ASP.NET Core с использованием Visual Studio Code (msdn.com/magazine/mt767698). По его экранным снимкам я видела, что он работал в Windows, но в остальном среда для Mac в основном та же.

Другой кросс-платформенный вариант — Rider от JetBrains. Rider предназначен специально для C#, и лучший способ описать его: «ReSharper в собственной IDE».

Я уже использовала Visual Studio Code в Windows и OS X (не только для C#, но и для Node.js) и именно ее я задействую, чтобы показать вам EF Core в приложении, создаваемом под CoreCLR. По сути, поскольку я создаю решение в OS X, ориентация на CoreCLR — единственный мой вариант. Массив доступных для моей библиотеки API более ограничен. Однако EF Core — это тот же набор API, использовавшийся мной в библиотеке для полной .NET в первом проекте.

Как вы увидите, большая часть усилий будет связана с конфигурированием проектов и зависимостей, специфичных для CoreCLR. Но я могу использовать тот же класс SamuraiContext, чтобы определить свою модель данных EF Core, и тот же тестовый метод CanAddAndUpdateSomeData из предыдущего проекта для выполнения той же работы. Код идентичен, хотя я теперь ориентируюсь на более ограниченную исполняющую среду и работаю в среде, которая не способна использовать ничего, кроме .NET Core.

Создание библиотеки, похожей на .NET-библиотеку классов

Я создала папку для хранения проектов Library и Test с подпапками для каждого проекта. В подпапке Library я могу вызвать dotnet new для создания проекта Library. На рис. 6 показана эта команда наряду с подтверждением о создании проекта. Перечисление содержимого папки показывает, что создано только два файла, самый важный из которых — project.json — содержит список необходимых NuGet-пакетов и прочие детали проекта. Library.cs — это просто пустой файл класса, который я удалю.


Рис. 6. Создание новой CoreCLR Library командой dotnet

Затем я открою проект этой новой библиотеки в Visual Studio Code. Я могу просто ввести code в строке приглашения. Visual Studio Code открывает проект как целевую папку, автоматически распознает пакеты, перечисленные в json-файле и предлагает выполнить dotnet restore для исправления неразрешенных зависимостей. Я с радостью соглашаюсь на это предложение.

Файл project.json выглядит, как на рис. 7.

Рис. 7. Файл Project.json

Довольно просто. Библиотекам не нужна вся начинка ASP.NET Core, которой я привыкла пользоваться, — только .NET Standard Library. Она инкапсулирует общий функционал, который .NET может теперь выполнять на разных платформах. Цитата из документации на .NET Standard Library (bit.ly/2b1JoHJ): «.NET Standard Library является формальной спецификацией .NET API, которые должны быть доступны во всех исполняющих средах .NET». Так что создаваемую мной библиотеку можно использовать с .NET Core, ASP.NET Core и даже с .NET-приложениями, начиная с .NET 4.5. Таблицу совместимости см. на странице документации.

Мой следующий шаг — добавление EF Core в проект. Учтите: поскольку я работаю сейчас на Mac, SqlServer недоступен. Я задействую провайдер PostgreSQL для EF Core, который записывается в пустой на данный момент раздел project.json:

Как и раньше, я планирую выполнять миграции. В обычной ситуации я добавила бы и зависимость от пакета Microsoft.EntityFrameworkCore.Tools, где содержатся команды, — как делала это в версии библиотеки для полной .NET. Но из-за текущих ограничений инструментария версии Preview 2 я отложу это до более позднего этапа в процессе. Тем не менее, мне действительно нужен доступ к командам из этой папки библиотеки, поэтому я добавляю данный пакет в особый раздел tools файла project.json, как показано в предыдущем фрагменте кода.

Восстановление пакетов приводит не только к извлечению этих двух пакетов, но и их зависимостей. Если вы просмотрите создаваемый при этом файл project.lock.json, вы увидите все эти пакеты, включая Microsoft.EntityFrameworkCore и Microsoft.EntityFrameworkCore.Relational, — те же, что добавлялись в предыдущее .NET-решение.

Теперь я просто копирую свои файлы Samurai.cs и SamuraiContext.cs. Я должна изменить класс OnConfiguring, чтобы задействовать PostgreSQL и его строку подключения вместо SQL Server. Та часть кода теперь выглядит так:

Теперь следовало бы выполнить миграции, но здесь вы наталкиваетесь на известное ограничение текущей версии Preview2 инструментария EF Core вне Visual Studio, а именно: для нахождения критически важных ресурсов нужен исполняемый проект. Поэтому поначалу это добавляет головной боли, но особых дополнительных усилий не требуется. Подробнее см. по ссылке bit.ly/2btm4OW.

Создание проекта Test

Я продолжу и добавлю тестовый проект, который потом смогу задействовать как исполняемый проект для выполнения миграций. Возвращаясь в командную строку, я перехожу в подпапку Oct2016DataPointsMac/Test, созданную мной ранее, и выполняю команду:

В Visual Studio Code вы увидите новый project.json в папке Test. Поскольку этот проект будет отвечать за проверку возможности выполнения командных строк EF, вы должны добавить в зависимости ссылку на пакеты EF Core Tools. Кроме того, тестовому проекту нужна ссылка на Library, поэтому ее тоже следует добавить в зависимости в файле project.json. Вот раздел dependencies после этих добавлений:

Теперь я могу обращаться к командам EF Core из папки Library. Заметьте, что на рис. 8 команда указывает на проект в папке Test через параметр —startup-project. Я буду использовать его в каждой из команд миграций.


Рис. 8. Исполняемый проект позволяет библиотеке использовать EF-команды миграции

Выполнение миграций применительно к модели EF из .NET-библиотеки

Когда я перечисляла в своей рубрике миграции EF Core, команды миграций dotnet ef выглядели иначе, чем команды PowerShell, но они ведут к одинаковой логике в API миграций.

Сначала я создам миграцию с помощью:

Это дает тот же результат, что и в .NET-решении: добавляются новая папка Migrations с миграцией и снимок миграции.

Теперь можно создать базу данных командой:

Затем я проверила, что база данных PostgreSQL, таблицы и отношения действительно созданы. С этой целью в OS X можно использовать целый ряд утилит. На своем Mac я предпочла кросс-платформенный JetBrains DataGrip в качестве IDE базы данных.

Выполнение тестов в CoreCLR

Наконец, я копирую класс TestEFCoreFullNet из предыдущего решения в папку Test. И вновь мне придется внести инфраструктурные изменения для использования xUnit вместо MS Test: это потребует изменений нескольких пространств имен, удаления атрибута TestClass, замены атрибутов TestMethod на Fact и замены Assert.AreEqual на Assert.Equal. О, и конечно, я переименую класс в TestEFCoreCoreClr.

В project.json тоже должно быть известно о провайдере InMemory, поэтому я добавляю:

в раздел dependencies, а затем снова выполняю команду dotnet restore.

Мой тестовый проект под xUnit использует средство запуска тестов xUnit из командной строки. Поэтому я возвращаюсь к окну терминала для запуска тестов командой dotnet test. На рис. 9 показан вывод теста, прошедшего с большим успехом с тем исключением, что средство запуска тестов из командной строки не обеспечивает удовлетворительного вывода зеленым цветом для успешно прошедших тестов.


Рис. 9. Вывод успешно выполненного теста xUnit

.NET или CoreCLR: те же API, тот же код

Итак, теперь вы понимаете, что код и сборки, относящиеся к EF Core, одинаковы независимо от того, ориентировано ваше программное обеспечение исключительно на Windows с полнофункциональной .NET Framework или на CoreCLR в любой поддерживаемой среде (Linux, OS X, Windows). Обе демонстрации я могла бы реализовать в Visual Studio 2015 на компьютере с Windows. Но сочла, что работа с CoreCLR в среде, где полнофункциональная .NET Framework недоступна, гораздо нагляднее продемонстрирует, что EF API и мой код, относящийся к EF, совершенно одинаковы в обоих случаях. Крупные различия и вся дополнительная работа относятся только к целевым платформам (.NET в сравнении с CoreCLR). Вы можете посмотреть, как я создаю полнофункциональный ASP.NET Core Web API, используя EF Core 1.0.0 на своем MacBook в видеоролике «First Look at EF Core 1.0» (bit.ly/2cmblqE). Сокращенный и более интересный вариант этого видеоролика с моим выступлением на DotNetFringe см. по ссылке bit.ly/2ci7q0T.

Джули Лерман (Julie Lerman) — Microsoft MVP, преподаватель и консультант по .NET, живет в Вермонте. Часто выступает на конференциях по всему миру и в группах пользователей по тематике, связанной с доступом к данным и другими технологиями Microsoft .NET. Ведет блог thedatafarm.com/blog и является автором серии книг «Programming Entity Framework» (O’Reilly Media, 2010), в том числе «Code First Edition» (2011) и «DbContext Edition» (2012), также выпущенных издательством O’Reilly Media. Вы можете читать ее заметки в twitter.com/julielerman и смотреть ее видеокурсы для Pluralsight на juliel.me/PS-Videos.

Выражаю благодарность за рецензирование статьи эксперту Microsoft Джеффу Фрицу (Jeff Fritz).

Ссылка на основную публикацию
Охлаждение оперативной памяти своими руками
Не будем задаваться вопросом «зачем это?» - и так понятно. Многие производители, заложив в свою IT-продукцию широкие возможности, в том...
Они обычно ходят всюду вместе
A phrasal verbis usually a two-word verb: get on, go behind, fall off, turn up, run off. The most common...
Определение задачи использует нерекомендуемый компонент планировщик
Планировщик задач Windows позволяет пользователю выполнять продвинутую настройку ПК и совершать запуск нужных ему приложений и утилит в конкретное время...
Охлаждение для телефона своими руками
Одним из популярных технических решений в смартфонах 2018 года стало использование систем водяного охлаждения — например, трубки с жидкостью стоят...
Adblock detector