wpf
wpf copied to clipboard
dotnet
MSBuildProjectExtensionsPath not handled correctly in GenerateTemporaryTargetAssembly
Description
This is a duplicate/regression of #5679, which I cannot reopen.
Using MSBuildProjectExtensionsPath in a dotnet-wpf application results in an error, because the build process tries to access a directory that does not exist and is not the one given in MSBuildProjectExtensionsPath.
Reproduction Steps
Create Directory.Build.props.
<Project>
<PropertyGroup>
<BaseOutputPath>$(MSBuildThisFileDirectory)bin\$(MSBuildProjectName)\</BaseOutputPath>
<MSBuildProjectExtensionsPath>$(MSBuildThisFileDirectory)obj\$(MSBuildProjectName)\</MSBuildProjectExtensionsPath>
<IntermediateOutputPath>$(MSBuildThisFileDirectory)obj\$(MSBuildProjectName)\$(Configuration)\</IntermediateOutputPath>
</PropertyGroup>
</Project>
then execute dotnet new wpf -n MyApp ; dotnet new sln ; dotnet sln add MyApp ; dotnet build
Expected behavior
Successful build.
Actual behavior
C:\Program Files\dotnet\sdk\8.0.303\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(266,5): error NETSDK1004: Assets file 'D:\dev\sdktest\obj\MyApp_32u0chsa_wpftmp\project.assets.json' not found. Run a NuGet package restore to generate this file. [D:\dev\sdktest\MyApp\MyApp_32u0chsa_wpftmp.csproj]
Regression?
This seems to be a regression. The original issue #5679 was reported for .NET Core Version: 6.0.100, and was reported as fixed in 7.0.100-preview.4.22252.9. However, I am experiencing this issue with 8.0.303.
Known Workarounds
Everything works as long as MSBuildProjectExtensionsPath is not set. This issue only appears if MSBuildProjectExtensionPath is set.
Impact
The bug impacts any project that uses wpf and sets MSBuildProjectExtensionsPath on .net8.0-windows
Configuration
dotnet --info
.NET SDK:
Version: 8.0.303
Commit: 29ab8e3268
Workload version: 8.0.300-manifests.34944930
MSBuild version: 17.10.4+10fbfbf2e
Runtime Environment:
OS Name: Windows
OS Version: 10.0.19045
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\8.0.303\
Other information
No response
@BFS-blickshift - I've examined the issue, and it appears that the issue is actually by design. During the WPF build process, a temporary project is generated as part of the markup compilation. During this time, the $(MSBuildProjectName) variable correctly points to the *_wpftmp project name. I attempted to use the $(AssemblyName) variable instead, but it seems that $(AssemblyName) is resolved at a later stage in the build process, which prevents it from being used effectively in this context.
Could you please let me know if the workaround that was shared by the community - here is not working for you?
If this is "by design" then the design is flawed. The documentation for $(MSBuildProjectName) does not mention anywhere that it can be an arbitrary name. Before I filed this issue I spent many hours trying to resolve the build problems I have in my real solution. I read through issues such as this because it is not possible to set MSBuildProjectExtensionsPath in the project file itself. Using the Directory.build.props seemed to be the recommended workaround for this issue, and now I'm supposed to use a workaround for a workaround that involves using regular expressions and hardcoded project names? This workaround may well work in the case of the minimum reproducible project for this bug report, but the fact that the project name is hardcoded into it makes it unviable for a real solution with dozens of projects - and even if it was, it would still be an unacceptable way of dealing with such a simple task as not polluting your source directory with intermediate and binary files.
This problem still exists in both the latest .NET SDKs 8.0.404 and 9.0.100.
