Open cremor opened 4 years ago
It seems like a partial workaround is to add this to the project file:
<PropertyGroup>
<Configurations>Debug;Release</Configurations>
<Platforms>AnyCPU</Platforms>
</PropertyGroup>
(I got the idea for that from here.)
But this only helps as long as the project doesn't reference any NuGet packages via a <PackageReference>
tag in the project file. As soon as it does, the build is broken again because the NuGet package restore doesn't work any more.
Note: I've now also reported this as a bug for Visual Studio at dotnet/project-system#6247. Since your SDK worked fine in older Visual Studio versions, it shouldn't break with a minor update in my opinion.
But if you can fix it, please do so. Even if Microsoft fixes the regression it will most likely take some time until the update is available.
So the current easiest workaround would be to split the import and create two files next to the csproj:
Directory.Build.props
:
<Project>
<Import Project="Sdk.props" Sdk="DasMulli.AssemblyInfoGeneration.Sdk/1.0.0" />
</Project>
Directory.Build.targets
:
<Project>
<Import Project="Sdk.targets" Sdk="DasMulli.AssemblyInfoGeneration.Sdk/1.0.0" />
</Project>
If you also have solution-/repo-wide Diretory.build/props files, you can add another import to these files (respectively changing props
/targets
):
<Import Project="$([MSBuild]::GetPathOfFileAbove('Directory.Build.props', '$(MSBuildThisFileDirectory)../'))" />
Thanks!
You don't even have to split it. You can simply put the whole <Sdk>
line in the Directory.Build.props
.
If your project contains customizations then no, you can't. Or shouldn't. The targets will normalize a bit so if you e.g. define <VersionPrefix>
in the main body of your project, the targets file will - because it is implicitly imported at the end - use it to construct Version
. that's the same for all properties that are defaulted in targets and one of the reasons the props/targets split exists...
I don't understand. According to the documentation importing an SDK with the <Sdk>
tag implicitly imports the props/targets file at the top/bottom of the project file. Isn't this the same as importing the props/targets file in Directory.Build.props/Directory.Build.targets?
It will only expand relative to the project file so it like importing the Sdk.props AND Sdk.targets file both from Directory.Build.props. "Project file" in this case would be the Directory.Build.props file...
Oh, I see. Overwriting properties in the project file does indeed not work this way. Thanks for the heads up.
But two further notes:
Splitting the import exactly like you suggested didn't work. The project didn't load because it didn't find the SDK. I had to specify the version as an attribute like
<Import Project="Sdk.props" Sdk="DasMulli.AssemblyInfoGeneration.Sdk" Version="1.0.0" />
as documented here.
After splitting the import (with the version in a tag) the result is worse. With the <Sdk>
tag in Directory.Build.props the version was correctly set (even if it couldn't be overwritten in the project file). But after the split the assembly version is always the default version (1.0.0). But the SDK still partly works, since e.g. the company is correctly set in the assembly (which comes from a tag in my root Directory.Build.props file).
For reference, here are the files that I used to test: Directory.Build.props:
<Project>
<Import Project="$([MSBuild]::GetPathOfFileAbove('Directory.Build.props', '$(MSBuildThisFileDirectory)../'))" />
<Import Project="Sdk.props" Sdk="DasMulli.AssemblyInfoGeneration.Sdk" Version="1.0.0" />
</Project>
Directory.Build.targets:
<Project>
<Import Project="$([MSBuild]::GetPathOfFileAbove('Directory.Build.targets', '$(MSBuildThisFileDirectory)../'))" />
<Import Project="Sdk.targets" Sdk="DasMulli.AssemblyInfoGeneration.Sdk" Version="1.0.0" />
</Project>
For my tests, I set both <VersionPrefix>
and <VersionSuffix>
. Both were set in my root Directory.Build.props file and overwritten in the project file.
After the recent update of Visual Studio 2019 to version 16.6.0 this SDK breaks project loading and building in Visual Studio.
Steps to reproduce:
Here is the error that is shown if you click on "Open log file" in the yellow error bar:
Log
``` 25.05.2020 09:32:34 Recoverable System.AggregateException: Project system data flow 'DataflowBlockSlim (ActionBlockSlimAsync`1 : 24683675)' closed because of an exception: System.AggregateException: One or more errors occurred. ---> System.ArgumentException: The project configuration "Debug|AnyCPU" was not found in the project manifest. at Microsoft.Requires.Fail(String message) at Microsoft.Requires.Fail(String unformattedMessage, Object[] args) at Microsoft.VisualStudio.ProjectSystem.DefaultingProjectConfigurationsServiceBase.