У меня есть проект OSS на GitHub, построенный против .NET 4.5 на AppVeyor CI с Visual Studio 2017 (не предварительный просмотр, только 2017).
Решение создает надстройку COM, которая расширяет классически устаревшую Win32 IDE, и мы установили, что самой ранней версией Windows, на которой нам нужно работать, является Vista (так что .net 4.5 и async/await awesomeness ).
Пока все хорошо. Теперь создание COM-видимой библиотеки .net DLL - это одно, а создание надстройки COM, которая выполняется в процессе и размещается в суетливом приложении, которое последний раз обновлялось 20 лет назад, - это другое: мы не можем полагаться на .net сборка мусора очищает RCW недетерминированным образом, поэтому довольно легко случайно утечь COM-объект и создать серьезные проблемы во время выполнения (на самом деле, разрыв), поэтому один из основных участников добавляет проект анализатора Roslyn в решение , что происходит чтобы помочь разработчикам, старым и новым в этом, путем предотвращения сборки, которая привела бы к такой утечке.
Таким образом, все файлы .csproj в решении получают эту разницу:
+ <ItemGroup>
+ <Analyzer Include="..\RubberduckCodeAnalysis\RubberduckCodeAnalysis\bin\Release\netstandard1.3\RubberduckCodeAnalysis.dll" />
+ </ItemGroup>
Таким образом, сначала необходимо построить проект анализатора.
Там есть .sln diff, показывающий GUID для нового проекта анализатора:
+Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "RubberduckCodeAnalysis", "RubberduckCodeAnalysis\RubberduckCodeAnalysis\RubberduckCodeAnalysis.csproj", "{A2B4E037-A446-41B9-A304-F91C7C7A6972}"
+EndProject
А затем .sln diff, показывающий один из проектов решения и то, как анализатор был добавлен в качестве зависимости для управления порядком сборки :
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Rubberduck.Parsing", "Rubberduck.Parsing\Rubberduck.Parsing.csproj", "{A4A618E1-CBCA-435F-9C6C-5181E030ADFC}"
ProjectSection(ProjectDependencies) = postProject
+ {A2B4E037-A446-41B9-A304-F91C7C7A6972} = {A2B4E037-A446-41B9-A304-F91C7C7A6972}
{8CE35EB3-8852-4BA1-84DD-DF3F5D2967B0} = {8CE35EB3-8852-4BA1-84DD-DF3F5D2967B0}
EndProjectSection
EndProject
Что приводит меня к ошибке сборки AppVeyor, в которой я застрял:
C: \ Program Files (x86) \ Microsoft Visual
Studio \ 2017 \ Пользователи \ MSBuild \ 15.0 \ Bin \ Microsoft.Common.CurrentVersion.targets (1603,5):
ошибка: проект
'C: \ Проекты \ Rubberduck \ RubberduckCodeAnalysis \ RubberduckCodeAnalysis \ RubberduckCodeAnalysis.csproj'
цели 'netstandard1.3'. На него не может ссылаться проект,
цели '.NETFramework, версия = v4.5' .
[C: \ Проекты \ Rubberduck \ Rubberduck.Parsing \ Rubberduck.Parsing.csproj]
В локальной отладочной сборке проект анализатора может быть собран вручную, а затем остальная часть решения может быть построена и проанализирована просто без необходимости взламывать зависимости проекта.
На сервере сборки AppVeyor CI проект анализатора - это просто библиотека DLL, являющаяся частью решения, и если мы не скажем, что он будет собран первым, библиотека DLL анализатора не будет найдена, и решение выиграно. не строить.
Похоже, я застрял, с какой стороны я смотрю на проблему. Все мои пользователи - пользователи Win32, меня не волнует переносимость; Я все равно хочу работать в Windows Vista, поэтому есть ли способ заставить это работать на CI, не перенаправляя проекты на .NET Standard 1.3?