#visual-studio #visual-studio-2019 #nuget-package #roslyn #.net-standard
#visual-studio #visual-studio-2019 #nuget-package #roslyn #.net-стандартный
Вопрос:
Когда я пытаюсь опубликовать свой пакет с помощью NuGet Package Explorer, я вижу следующее предупреждение:
Детерминированный (dll / exe): недетерминированный
Убедитесь, что для сборок CI включено следующее свойство
и вы используете по крайней мере пакет 2.1.300 SDK:<ContinuousIntegrationBuild>true</ContinuousIntegrationBuild>
Однако, когда я добавляю это свойство в PropertyGroup (как описано здесь), VS 2019 выходит из себя настолько сильно, что мне буквально нужно ctrl alt delete, чтобы закрыть его.
Согласно этой странице, имя свойства — <Deterministic> , но, похоже, это вообще ничего не делает.
Итак, как мне заставить детерминированные сборки работать?
Visual Studio 2019, версия 16.7.1
.Net SDK 3.1.401 (LTS)
Комментарии:
1. Можете ли вы опубликовать некоторые из ошибок, которые вы видите? В нынешнем виде на этот вопрос невозможно ответить. Детерминированный вариант, на который вы ссылаетесь, касается детерминированности компилятора (официальные документы здесь ). Этот флаг включен по умолчанию в любом проекте .NET Core, и поэтому указание его в вашем файле проекта ничего не даст.
2. @JonathonMarolf: Я уже опубликовал ошибки, которые я вижу. Когда вы включаете флаг в локальных сборках, Visual Studio зависает при сборке и ее необходимо принудительно закрыть.
3. @BlueRaja-DannyPflughoeft Файл default .csproj, созданный VS v16.7.1 для консольного приложения C #, находится
<Deterministic>true</Deterministic>вверху<PropertyGroup>, и он отлично создается локально. Итак, я предполагаю, что в файлах вашего проекта должно быть какое-то другое различие.4. что происходит при сборке из командной строки? Я полагаю, что свойства Clair будут работать только в проекте в стиле sdk (тип, созданный для проекта .NET Core).
5. что
ContinuousIntegrationBuildна самом деле делает, когда установлено?
Ответ №1:
Более простой ответ — не связываться с .csproj файлами (тьфу!) и сделать это через командную строку в вашем скрипте CI.
добавьте /p:ContinuousIntegrationBuild=true аргумент в dotnet pack команду.
dotnet pack
-c $env:CONFIGURATION
/p:ContinuousIntegrationBuild=true
-p:PackageVersion=$env:APPVEYOR_BUILD_VERSION
(сделайте все это одной строкой. Я разбил ее на несколько разделов для удобства чтения)
ПРИМЕЧАНИЕ: --no-build аргумента здесь НЕТ. Нам нужно собрать это снова. Или вы добавляете этот параметр на этапе сборки перед этим.
Это взято из примера файла CI, который я использую. Итак, когда я нахожусь в release режиме, я упаковываю библиотеку в nuget и публикую ее.
Сохраняет все в чистоте и из вашего .csproj файла (что очень сложно проверить и поддерживать).
Комментарии:
1. Это сделало это за меня. Спасибо @Pure.Krome
2. Как поднятая вами проблема влияет на этот ответ, он все еще действителен?: github.com/dotnet/sdk/issues/16325
Ответ №2:
Я в основном только что нашел ответ в этом сообщении в блоге:
Хотя детерминированные сборки включены по умолчанию в проектах .NET SDK, на сервере сборки можно установить дополнительное свойство ContinuousIntegrationBuild для нормализации путей к сохраненным файлам. Они не должны быть включены во время локальной разработки, иначе отладчик не сможет найти локальные исходные файлы.
<PropertyGroup Condition="'$(TF_BUILD)' == 'true'">
<ContinuousIntegrationBuild>true</ContinuousIntegrationBuild>
</PropertyGroup>
Комментарии:
1. Установка этой переменной не имела для меня никакого значения: я все еще получаю то же самое предупреждение при просмотре пакета с помощью NuGet Package Explorer. Пробовал как устанавливать для нее значение
trueвсегда (в качестве теста), так и компилировать из cmdline, используя пользовательскую переменную типаTF_BUILD.2. Для меня использование ContinuousIntegrationBuild также не работает
3. Мне пришлось включить sourcelink, включив соответствующий пакет для моего управления версиями, а затем я получил все зеленые галочки в nuget package explorer