Failure publishing WPF app with RID can fail if intermediate path is overridden

[dsplaisted]

Repro steps

• dotnet new wpf
• Put the following in Directory.Build.props in project directory:

<Project>
    <PropertyGroup>
        <BaseOutputPath>$(MSBuildProjectDirectory)/out/$(MSBuildProjectName)/bin</BaseOutputPath>
        <BaseIntermediateOutputPath>$(MSBuildProjectDirectory)/out/$(MSBuildProjectName)/obj</BaseIntermediateOutputPath>
    </PropertyGroup>
</Project>

• dotnet build
• dotnet publish -r win10-x64 --self-contained

Expected result

Publish succeeds

Actual result

Errors such as:

out\wpf\obj\Debug\netcoreapp3.0\wpf_oqgucux2_wpftmp.AssemblyInfo.cs(10,12): error CS0579: Duplicate 'System.Reflection.AssemblyCompanyAttribute' attribute [C:\git\repro\wpf\wpf_xfkwhwdg_wpftmp.csproj]
out\wpf\obj\Debug\netcoreapp3.0\wpf_oqgucux2_wpftmp.AssemblyInfo.cs(11,12): error CS0579: Duplicate 'System.Reflection.AssemblyConfigurationAttribute' attribute [C:\git\repro\wpf\wpf_xfkwhwdg_wpftmp.csproj]

It looks like these errors are due to the generated files being generated in two separate paths (one from the RID-less dotnet build, and the other from the dotnet publish with the RID specified), but both are being included in the WPF temporary generated project (likely because the Directory.Build.props intermediate path depends on the project name, which changes for the temporary project).

The best fix is probably to stop generating a temporary project, and instead call a target in the main project, if that's possible.

FYI @nguerrera

Thanks to @mjrousos for reporting this

[nguerrera]

@ryalanms

[nguerrera]

We have had to do various workarounds for the wpf temp project. I agree it would be good to eliminate it.

See https://github.com/dotnet/arcade/search?q=IsWpfTempPRoject&unscoped_q=IsWpfTempProject

The idea I've had to do that would be to do something like multi-targeting where we build the same csproj, but change some global properties. I don't think this can just be a target in the same project evaluation as some of the targets need to run twice IIRC.

[nguerrera]

Looking at it a little closer, I'm not sure it's right to pin this on the temp project entirely.

I assume the goal of those statements in D.B. props is to account for projects in the same directory and make sure they each get thier own output and intermediate directories?

However, outting these underneath $(MSBuildProjectDirectory) doesn't work well with globs.

Here's a different case that will hit the same error.

• mkdir repro && cd repro
• dotnet new classlib
• copy repro.csproj repro2.csproj
• Create Directory.Build.props as defined in the issue description
• dotnet build repro.csproj
• dotnet build repro2.csproj

Same errors:

out\repro2\obj\Debug\netstandard2.0\repro2.AssemblyInfo.cs(10,12): error CS0579: Duplicate 'System.Reflection.AssemblyCompanyAttribute' attribute [C:\Users\nicholg\repro\repro2.csproj]
out\repro2\obj\Debug\netstandard2.0\repro2.AssemblyInfo.cs(11,12): error CS0579: Duplicate 'System.Reflection.AssemblyConfigurationAttribute' attribute [C:\Users\nicholg\repro\repro2.csproj]
out\repro2\obj\Debug\netstandard2.0\repro2.AssemblyInfo.cs(12,12): error CS0579: Duplicate 'System.Reflection.AssemblyFileVersionAttribute' attribute [C:\Users\nicholg\repro\repro2.csproj]
out\repro2\obj\Debug\netstandard2.0\repro2.AssemblyInfo.cs(13,12): error CS0579: Duplicate 'System.Reflection.AssemblyInformationalVersionAttribute' attribute [C:\Users\nicholg\repro\repro2.csproj]
out\repro2\obj\Debug\netstandard2.0\repro2.AssemblyInfo.cs(14,12): error CS0579: Duplicate 'System.Reflection.AssemblyProductAttribute' attribute [C:\Users\nicholg\repro\repro2.csproj]
out\repro2\obj\Debug\netstandard2.0\repro2.AssemblyInfo.cs(15,12): error CS0579: Duplicate 'System.Reflection.AssemblyTitleAttribute' attribute [C:\Users\nicholg\repro\repro2.csproj]
out\repro2\obj\Debug\netstandard2.0\repro2.AssemblyInfo.cs(16,12): error CS0579: Duplicate 'System.Reflection.AssemblyVersionAttribute' attribute **[C:\Users\nicholg\repro\repro2.csproj]

[mjrousos]

I assume the goal of those statements in D.B. props is to account for projects in the same directory and make sure they each get thier own output and intermediate directories?

Correct. In the real scenario I took this from, there are two projects in the directory (one old-style csproj targeting NetFX and one new one targeting NetCore). It's an interim solution to allow using VS designers (via the old project) while porting to Core (via the new project). To avoid the globbing problem, the new csproj includes an explicit remove for anything under out\oldProject (<Compile Remove="out\OriginalProj\**\*.cs />).

Thinking about the temporary csproj, I can see how this could be an issue since the original project is removed but the temp project isn't. From the developer's point of view, though, they've excluded the only other csproj that should be using the \out\ directory, so it's a confusing problem. I think it's ok to expect developers to know that shared output folders can mess up globbing includes, but it's not a good experience to drop unexpected projects in that exacerbate the problem by also writing to those output locations.

A couple other items that seem odd about this:

1. Why is this only an issue when the intermediate output path is overridden?
2. Even when this issue repros, dotnet build seems to be ok. Why is it only publishing that runs into this?

[nguerrera]

1. Because BaseIntermediateOutputPath is excluded from globs and without customization all projects in the directory + temp project have a shared BaseIntermediateOutputPath
2. I'm not sure. Investigating.

[stevenbrix]

@nguerrera are you taking this bug?

[vatsan-madhavan]

@ryalanms & I have been talking about ways to eliminate the temp project being created on the disk. It’s something he’d need to prototype to be sure that our intended approach would actually work...