Как подключить net framework к visual studio

Обновлено: 04.07.2024

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

Как только кто-либо из нашей команды вносит изменения в код (читай «мерджит feature-ветку в develop»), наш билд-сервер:

Собирает исходный код и установщик приложения
- проставляет номер сборки, каждый раз увеличивая последнюю цифру. Например, текущая версия нашего ПО 3.3.0.202 – часть 3.3.0 когда-то ввёл разработчик (привет, SemVer), а «202» проставляется в процессе сборки.
- В процессе анализирует качество кода (с использованием SonarQube) – и отправляет отчёт во внутренний SonarQube,
Также, в зависимости от ветки, в которую были внесены изменения, могут быть выполнены:
- отправка сборки (вместе с changelog-ом) в один или несколько телеграм-каналов (иногда удобнее брать сборки оттуда).
- публикация файлов в систему автообновления ПО.
Под катом о том, как мы научили Gitlab CI делать за нас бОльшую часть этой муторной работы.

Чтобы настроить Gitlab Runner, выполните следующие шаги:

Далее надо ввести ответы на вопросы мастера регистрации Runner-а:

В процессе своей работы Gitlab CI берёт инструкции о том, что делать в процессе сборки того или иного репозитория из файла .gitlab-ci.yml , который следует создать в корне репозитория.

И последнее: если нам требуется передавать в скрипт значение параметра, который мы не хотим хранить в самом скрипте (например, пароль для подключения куда-либо), мы можем использовать для этого объявление параметров в gitlab. Для этого зайдите в проекте (или в группе проекта) в Settings > CI/CD и найдите раздел Variables. Прописав в нём параметр с именем (key) SAMPLE_PARAMETER, вы сможете получить его значение в в скрипте .gitlab-ci.yml через обращение $env:SAMPLE_PARAMETER.

Также в этом разделе можно настроить передачу введенных параметров только при сборке защищённых веток (галочка Protected) и/или скрытие значения параметра из логов (галочка Masked).

Подробнее о параметрах окружения сборки смотрите в документации к Gitlab CI.

Скрипт, приведённый выше, уже можно использовать для сборки и вызова тестов. Правда, присутствует НО: крайне неудобно прописывать абсолютные пути к разным установкам Visual Studio. К примеру, если на одной билд-машине стоит Visual Studio 2017 BuildTools, а на другой Visual Studio Professional 2019, то такой скрипт будет работать только для одной из двух машин.

К счастью, с версии Visual Studio 2017 появился способ поиска всех инсталляций Visual Studio на компьютере. Для этого существует утилита vswhere, путь к которой не привязан ни к версии Visual Studio, ни к её редакции. А в Visual Studio 2019 (в версии 16.1 или более новой) есть библиотека, которая умеет «трансформировать» консоль Powershell в режим Developer Powershell, в котором уже прописаны пути к утилитам из поставки VS.

Дописываем переменную к секции Variables:

Затем создаём новую секцию before_msbuild якорем enter_vsdevshell и следующим текстом:

И всюду, где нам надо использовать утилиты Visual Studio, добавляем этот якорь. После этого задача сборки начинает выглядеть намного более опрятно:

Результат: мы имеем путь к vswhere.

Результат: в переменную $visualStudioPath записан путь к Visual Studio или пустая строка, если инсталляций Visual Studio не найдено (обработку этой ситуации мы ещё не добавили).
1. Команда Import-Module загружает библиотеку Microsoft.VisualStudio.DevShell.dll, в которой прописаны командлеты трансформации консоли Powershell в Developer-консоль. А командлет Join-Path формирует путь к этой библиотеке относительно пути установки Visual Studio.
  На этом шаге нам прилетит ошибка, если библиотека Microsoft.VisualStudio.DevShell.dll отсутствует или путь к установке Visual Studio нужной редакции не был найден — Import-Module сообщит, что не может загрузить библиотеку.
Результат: загружен модуль Powershell с командлетом трансформации.
1. Запускаем «переделку» консоли в Developer Powershell. Чтобы корректно прописать пути к утилитам, командлету требуется путь к установленной Visual Studio (параметр -VsInstallPath ). А указание SkipAutomaticLocation требует от командлета не менять текущее расположение (без этого параметра путь меняется на <домашнаяя папка пользователя>\source\repos ).
Результат: мы получили полноценную консоль Developer Powershell с прописанными путями к msbuild и многим другим утилитам, которые можно использовать при сборке.

Раньше мы использовали t4 шаблоны для проставления версий: номер версии собиралась из содержимого файла в формате <major>.<minor>.<revision> , далее к ней добавлялся номер сборки из Gitlab CI и он передавался в tt-шаблон, добавляющий в решение везде, где требуется, номер версии. Однако некоторое время назад был найден более оптимальный способ — использование команд git tag и git describe .

Команда git tag устанавливает коммиту метку (тэг). Отметить таким образом можно любой коммит в любой момент времени. В отличие от веток, метка не меняется. То есть если после помеченного коммита вы добавите ещё один, метка останется на помеченном коммите. Если попробуете переписать отмеченный коммит командами git rebase или git commit --amend, метка также продолжит указывать на исходный коммит, а не на изменённый. Подробнее о метках смотрите в git book.

Команда git describe , к сожалению, в русскоязычном gitbook не описана. Но работает она примерно так: ищет ближайшего помеченного родителя текущего коммита. Если такого коммита нет — команда возвращает ошибку fatal: No tags can describe '<тут хэш коммита>' . А вот если помеченный коммит нашёлся — тогда команда возвращает строку, в которой участвует найденная метка, а также количество коммитов между помеченным и текущим.

Кстати, по этой же причине если вы используете gitflow, после вливания feature-ветки в develop требуется удалить влитую локальную ветку, после чего пересоздать её от свежего develop:

(обратите внимание на историю git в левой части картинки: из-за отсутствия пути из текущего коммита до коммита с меткой 1.0.5, команда git describe выдаст неверный ответ)

Но вернёмся к автопроставлению версии. В нашем репозитории царит gitflow (точнее его rebase-версия), метки расставляются в ветке master и мы не забываем пересоздавать feature-ветки от develop, а также merge-ить master в develop после каждого релиза или хотфикса.

Тогда получить версию для любого коммита и сразу передать её в msbuild можно добавив всего пару строк к задаче сборки:

Как это работает:
1. Мы проставляем метки в формате <major>.<minor>.<revision> .
2. Тогда git describe --long возвращает нам строку, описывающую версию в формате <major>.<minor>.<revision>-<количество новых коммитов>-g<хэш текущего коммита> .
3. Парсим полученную строку через регулярные выражения, выделяя нужные нам части — и записывем части в $versionGroup .
4. Преобразовываем четыре найденные подстроки в 4 числа и пишем их в переменные $major , $minor , $patch , $commit , после чего собираем из них строку уже в нужном нам формате.
5. Передаём указанную строку в msbuild чтобы он сам проставил версию файлов при сборке.
Обратите внимание: если вы, согласно gitflow, будете отмечать (тэгировать) ветку master после вливания в неё release или hofix, будьте внимательны: до простановки метки автосборка будет вестись относительно последней существующей ветки. Например, сейчас опубликована версия 3.4, а вы создаёте release-ветку для выпуска версии 3.5. Так вот: всё время существования этой ветки, а также после её вливания в master, но до простановки тэга, автосборка будет проставлять версию 3.4.

SonarQube — это мощный инструмент контроля качества кода.

SonarQube имеет бесплатную Community-версию, которая способна проводить полный анализ. Правда, только одной ветки. Чтобы настроить её на контроль качества ветки разработки (develop), требуется выполнить следующие шаги (разумеется, помимо установки и развёртывания сервера SonarQube):

Теперь при каждой сборке ветки develop в SonarQube будет отправляться подробный анализ нашего кода.

На заметку: вообще команда msbuild /t:rebuild полностью пересобирает решение. Вероятно, в большинстве проектов анализ можно было бы встроить прямо в стадию сборки. Но сейчас у нас анализ в отдельной задаче.

Пара слов об использованных параметрах:

Со сборкой более-менее разобрались — теперь приступаем к тестам. Доработаем код прогона тестов, чтобы он:
- сам находил библиотеки с тестами,
- прогонял их пачкой через xUnit,
- вычислял тестовое покрытие через OpenConver,
- отправлял результаты покрытия тестами в SonarQube.
На заметку: обычно в паре с OpenCover используют ReportGenerator, но при наличии SonarQube мы с тем же успехом можем смотреть результаты через его интерфейс.

Для настройки выполним следующие шаги:
1. Скачайте OpenCover в виде zip-файла с сайта github.
2. Распакуйте содержимое архива в папку. Например, в C:\Tools\OpenCover .
  На заметку: эту утилиту также можно скачать на сборочную машину через NuGet, но тогда надо будет чуть по-иному указывать её путь.
3. Допишите переменные к секции Variables:
4. Модифицируйте задачу тестирования ветки разработки (test_job), чтобы она включала и команды вызова OpenCover:
.NET является программной платформой, разработанной компанией Microsoft. Выделим некоторые из ее особенностей:

(Изображение взято с блога Microsoft)

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

Установка для Windows

Выберете дистрибутив под Windows и дождидесь его скачивания. После запуска файла установки, на первом экране вы увидите краткую информацию о продукте. Нажмите на кнопку “Установить”.

На этом процесс установки для Windows можно считать завершенным.

Перейдите на страницу официальной документации Microsoft по установке .NET Core и убедитесь, что ваша операционная система (тип и версия) поддерживает возможность установки .NET Core.

Согласно приведенной инструкции нужно выполнить несколько шагов. Добавьте ключ подписывания пакета Microsoft в список доверенных ключей и добавьте репозиторий пакетов:

После этого запустите установку SDK:

И проверить версии среды выполнения:

Среда разработки (IDE)

Microsoft Visual Studio

Сохраните файл установки на компьютере. Это веб-установщик, поэтому он имеет небольшой размер. Запустите его, в результате вам будет представлено окно приветствия.

Нажмите на кнопку “Продолжить” дождитесь окончания подготовительного этапа. После этого откроется окно с настройкой компонентов, для выполнения всех работ по курсу достаточно выбрать “Разработка классических приложений .NET”, “ASP.NET и Разработка веб-приложений”.

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

Microsoft VS Code

Еще один продукт от Microsoft , он позиционируется как легковесный редактор кода, включает в себя отладчик, инструменты для работы с Git , подсветку синтаксиса, IntelliSense, средства для рефакторинга и многое другое. VS Code предоставляет большое количество настроек визуального оформления редактора.

Нажмите на кнопку “Download for Windows” и сохраните дистрибутив на свой компьютер.

В следующем окне оставьте все галочки без изменений и нажмите “Далее”.

В последнем окне нажмите кнопку “Установить” и дождитесь окончания установки.

JetBrains Rider

Нажмите “ Next ” и выберите место установки. На следующем экране можно произвести дополнительные настройки ассоциации файлов или оставить все как есть, после этого нажмите кнопку “ Next ”, а затем “ Install ”.

Дождитесь окончания установки.

Онлайн интерпретаторы

Создание проекта в Microsoft Visual Studio (Windows)

Далее выберите тему по вкусу и нажмите “Запуск Visual Studio ”.

Все подготовительные шаги пройдены, нажмите на кнопку “Создание проекта”.

Выберете шаблон “Консольное приложение” и нажмите “Далее”.

Укажите имя проекта, например “ MyFirstProject ” и место где он будет сохранен.

В результате будет открыто окно Visual Studio с созданным проектом.

Проект в Visual Studio представляет собой набор файлов, их структура представлена в окне “Обозреватель решения”. Основной файл, который нас сейчас интересует это Program.cs . Откройте его, мы добавили поясняющие комментарии в код модуля:

Запустим наше приложение и посмотрим, что произойдет.

Для этого можно использовать несколько способов:

После выполнения команды в папке с проектом будет размещен необходимый набор файлов. Для запуска проекта воспользуйтесь командой:

Как и в случае с проектом в Visual Studio , в консоли будет выведен текст “Hello World!”.

Поработаем над кодом программы: вместо текста выведем текущую дату. Для этого в файле Program.cs замените строку

Сохраните файл и выполните команду:

Вместо текста в консоли должна появиться текущая дата.

Компиляция файла с исходным кодом вручную (Windows)

В меню “Пуск” найдите и откройте “ Developer Command Prompt for VS 2019 ”, перейдите в каталог с файлом и выполните в нем команду:

Шаг 1. Запуск Portability Analyzer

Запускаем Portability Analyzer и указываем расположение исходного кода проекта:

Portability Analyzer

После этого откроется файл Excel с отчётом по проверке. У меня этот файл выглядел следующим образом:

Лист Portability Summary

Шаг 2. Миграция .csproj в SDK-стиле

А вот так будет выглядеть контекстное меню проекта без пункта:

Откроется XML-файл примерно такого содержания:

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

У меня такой блок оказался всего один, поэтом итоговый файл *.cproj стал выглядеть вот так:

Помогло удаление файла AssemblyInfo.cs

После этого проект запустился, работоспособность не нарушилась. Однако встретилась другая проблема.

Теперь необходимо добавить в проект пространство имен:

И можно пользоваться классами Point и Rect :

Приложения (программы) можно разрабатывать на разных языках программирования, которые поддерживают эту технологию.
- совместное использование разных языков программирования;
- безопасность и переносимость программ;
- общую модель программирования на базе платформы Windows.
- общеязыковая исполнительная среда CLR ( Common Language Runtime );
- библиотека базовых классов.
Библиотека базовых классов включает в себя определение разнообразных примитивов, которыми могут быть: потоки, графические API-интерфейсы, реализация баз данных, файловый ввод-вывод и прочее.

3. Какой принцип действия общеязыковой среды выполнения CLR ( Common Language Runtime )?

Основное назначение CLR – превратить промежуточный код MSIL в исполнительный код в процессе выполнения программы.

Рис. 1. Процесс преобразования исходного кода в код на языке MSIL ( CIL или IL ) и создание файла сборки ( *.dll или *.exe )

Исполнительная среда CLR отвечает за определение места размещения сборки (assembly).

Запрашиваемый тип, который размещается в сборке (например, класс ArrayList или другой тип), определяется в двоичном файле ( *.dll или *.exe ) с помощью считывания метаданных этого файла.

После этого CLR размещает в памяти считанный из сборки тип.

Затем CLR превращает CIL-код в соответствующие инструкции, которые подстраиваются под конкретную платформу (в зависимости от ПК, операционной системы и т.п.). Кроме того, на этом этапе происходят необходимые проверки на предмет безопасности.

Последним происходит выполнение запрашиваемого программного кода.

4. Что такое промежуточный язык MSIL ( Microsoft Intermediate Language ) или CIL ( Common Intermediate Language )?

MSIL есть псевдокодом. MSIL определяет набор инструкций, которые:
- могут переноситься на разные платформы;
- не зависят от конкретного процессора.
Фактически, MSIL – это язык переносного ассемблера

Сборка предназначена для сохранения пространств имен ( namespaces ). Пространства имен содержат типы. Типами могут быть классы, делегаты, интерфейсы, перечисления, структуры.

Сборка может содержать любое количество пространств имен. Любое пространство имен может содержать любое количество типов (классов, интерфейсов, структур, перечислений, делегатов).

6. Что размещается в сборках?

В сборках размещается CIL -код ( MSIL -код или IL -код) и метаданные.

7. Что такое манифест ( manifest )?

Манифест – это описание самой сборки с помощью метаданных.

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

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

После этого приложение выполняется.

9. Какие существуют виды сборок?

Существует два вида сборок:
- однофайловые сборки;
- многофайловые сборки.
Сборка, которая состоит из одного единого модуля ( *.dll или *.exe ) называется однофайловой. В однофайловых сборках все необходимые CIL -инструкции, метаданные и манифесты размещаются в одном, четко определенном пакете.

В многофайловой сборке один из модулей есть главным ( primary ).

10. В каком файле размещается главная сборка библиотеки MS Visual Studio?

Главная сборка размещается в файле “ mscorlib.dll ”.

11. Что такое общая система типов CTS ?

CTS ( Common Type System ) – система типов, которая содержит полное описание всех возможных типов данных и программных конструкций, которые поддерживаются общеязыковой исполнительной средой CLR . Также здесь описывается то, как эти сущности могут взаимодействовать между собою.

Типами могут быть классы, интерфейсы, структуры, перечисления, делегаты.

12. Какое назначение общеязыковой спецификации CLS?

14. Что такое пространство имен ( namespace )?

Пространство имен предназначено для объединения группы типов, которые связаны между собою с семантической точки зрения. Типы размещаются в сборках ( assembly ). Под типами понимаются классы, делегаты, интерфейсы, структуры, перечисления.

Примеры названий пространств имен:

Например, в пространстве имен System.Data размещаются основные типы для работы с базами данных, в пространстве имен System.Collections размещаются основные типы для работы с коллекциями.

15. Как вывести содержимое сборок, пространств имен и типов в MS Visual Studio ?

В системе Microsoft Visual Studio есть утилита Object Browser , которая вызывается с меню View (рисунок 3).

Рис. 3. Вызов утилиты Object Browser

В результате откроется окно Object Browser , в котором будут отображаться сборки, которые используются в определенной технологии.

Рис. 4. Окно Object Browser с выделенной сборкой mscorlib.dll

Если раскрыть содержимое сборки mscorlib (знак “ + ”), то будет отображен список всех пространств имен данной сборки (рисунок 5). Как видно из рисунка, сборка включает пространства имен Microsoft.Win32 , System , System.Collections , System.Collections.Concurrent и много других.

Рис. 5. Сборка mscorlib и список пространств имен, которые входят в нее

Аналогично раскрывается любое из пространств имен. В пространствах имен описываются типы. В типах описываются методы, свойства, константы и т.п.

На рисунке 6 изображен класс BinaryReader из пространства имен System.IO . По всей видимости, в классе реализованы методы с именами BinaryReader() , Close() , Dispose() , FillBuffer() и прочие.

Рис. 6. Содержимое класса BinaryReader

Для подключения пространства имен используется ключевое слово using .

Примеры подключения пространств имен:

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

Читайте также: