Могу ли я создавать приложения .NET Core на сервере Windows без установленной Visual Studio?

Я пытаюсь настроить сервер непрерывной интеграции в Windows, который создает основные приложения .net, после установки только SDK ядра .net с сайта загрузки ядра .net без установки Visual Studio.

Ошибка, которую я получаю, когда пытаюсь построить:

C:\dev\aaa.xproj(7,3): error MSB4019: The imported project 
 "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0
 \DNX\Microsoft.DNX.Props" was not found

Я искал в Google и нашел жалобы на такого рода ошибки в более ранних бета-версиях, но я подумал, что автономные основные инструменты .net должны были работать только с кодом Visual Studio (или даже с любым редактором) и с не установленной Visual Studio, просто . net core standalone sdk.

Есть ли какой-нибудь способ заставить это работать? Интересно, что указанная выше ошибка возникла, когда я запустил сборку dotnet из корневого каталога решения, например:

msbuild /v:q  /t:Build /nologo /P:Configuration=Release MySolutionWithSevenProjectsInIt.sln

Вышеупомянутое, похоже, требует установки Visual Studio для создания всего решения, поэтому я предполагаю, что если мне нужен этап «сборки решения» вместо этапа сборки отдельного проекта, мне нужна Visual Studio?

Мне странно, что в этой системе вообще установлен msbuild, все, что есть на этом компьютере, - это основной sdk .net и "нерабочий" (как указано выше) msbuild.


person Warren P    schedule 04.08.2016    source источник
comment
Я думаю, что если вы хотите построить без установленной Visual Studio, вы должны использовать dotnet и его команды docs.microsoft.com/en-us/dotnet/articles/core/tools/, потому что инструменты dotnet cli должны работать без *.sln/*.csproj/*.xproj файлов, просто на основе project.json   -  person Tseng    schedule 04.08.2016
comment
Интересный. Есть также некоторые сумасшедшие предупреждения даже при сборке с использованием dotnet на машине без установленной VS. Ожидается, что будет существовать полный набор библиотек C / C ++, таких как MFC и т. Д.   -  person Warren P    schedule 04.08.2016
comment
проверьте это - stackoverflow.com/questions/34580599/   -  person Sanket    schedule 04.08.2016


Ответы (1)


Да, вы можете создавать приложения .NET Core без установленной Visual Studio. (Я делал это на своем Mac!)

Для вашей платформы необходимо установить .NET Core SDK. Дважды проверьте, что у вас последняя версия:

dotnet --version
2.0.2

Затем вы можете перейти в каталог своего проекта (папку, содержащую ваш .csproj файл) и запустить:

dotnet build

или, чтобы построить в режиме выпуска:

dotnet build -c Release
person Nate Barbettini    schedule 04.08.2016
comment
И не пытайтесь использовать MSBUILD, который они установили для вас. :-) - person Warren P; 04.08.2016
comment
Ага. Я думаю, это потребует обновления, когда они вернутся к msbuild с ядром .net. Не уверен, как это будет работать. Думаю, сборка dotnet вызовет msbuild. - person Warren P; 04.08.2016
comment
Я также использую систему Mac, и когда я запустил сборку dotnet, я получил следующую ошибку: ........ visual studio / v15.0 / Webapplications / microsoft.webaapplication.traget не выполнялся. убедитесь, что путь в объявлении ‹import› правильный и что файл существует на диске ... - person Pravee; 15.01.2018
comment
@Pravee Вы можете создавать кроссплатформенные (.NET Core) проекты только на Mac. Похоже, этот проект может быть более старым (.NET Framework) проектом, который будет построен только на Windows. См .: stackoverflow.com/a/38064762/3191599 - person Nate Barbettini; 15.01.2018
comment
А как насчет используемых пакетов NuGet? The type or namespace name 'log4net' could not be found (are you missing a using directive or an assembly reference?) - person SerjG; 16.05.2019
comment
@Sergey Эти пакеты NuGet перечислены в файле .csproj? Если нет, вам нужно их добавить. См. docs.microsoft.com/en-us/dotnet / core / tools / dotnet-add-package - person Nate Barbettini; 17.05.2019
comment
@NateBarbettini Ага. Это была проблема с упомянутым проектом 4.6.1, который ссылался на log4net. Переход на .NET Standard решил проблему. Прости - person SerjG; 18.05.2019