-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Description
The reason for enabling this setting is to include code from a source generator (BoilerPlateZero), but that wasn't needed to cause the build to break.
Version Used:
.NET 5.0-windows with C#9 with VS2019 16.11.0 Enterprise
Steps to Reproduce:
- Take a relatively complex solution using WPF which builds with no errors
- Add in
Directory.Build.props
or*.csproj
a.<AssemblyName>MyProductName.$(MSBuildProjectName)</AssemblyName>
b.<IncludePackageReferencesDuringMarkupCompilation>true</IncludePackageReferencesDuringMarkupCompilation>
- Build project
Expected Behavior:
Should build with no errors.
Actual Behavior:
Fails to builds with errors such as:
Severity | Code | Description |
---|---|---|
Error | CS0006 | Metadata file '[ProjectDir] \bin\Debug\ref\[AssemblyName] .dll' could not be found. |
Error | CS0006 | Metadata file '[ProjectDir] \bin\Debug\[AssemblyName] .dll' could not be found. |
Error | MC2000 | Unknown build error, 'Could not find file '[ProjectDir] \obj\Debug\[AssemblyName] .dll'. |
Error | MC3050 | Cannot find the type '[CustomClass] '. Note that type names are case sensitive. |
Error | MC3074 | The tag '[CustomClass] ' does not exist in XML namespace 'clr-namespace:[Namespace] '. |
NOTE: In all cases, the [ProjectDir]
/[AssemblyName]
is the same as the source of the error (I assume due to the iterative way WPF is built) and the [CustomClass]
es which aren't found in the [Namespace]
s are also within the same project.
This occurs in two separate solutions using $(MSBuildProjectName)
in AssemblyName
, and the only way I could get it to build was to override Directory.Build.props
with an explicit AssemblyName
tag in the *.csproj
(not using $(MSBuildProjectName)
).
I tried to make a sample solution without any private code, but for some reason it was lacking the complexity which causes it to fail, sorry.