Workaround for WPF PackageReference and source generators bug about cswin32 HOT 19 CLOSED

@AArnott , figured out the issue. I needed to add <UseWPF>true</UseWPF> for the project to be formally recognized as a SDK-style WPF project. After that the new flag works

<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>        
    <TargetFrameworks>net45</TargetFrameworks>
    <IncludePackageReferencesDuringMarkupCompilation>true</IncludePackageReferencesDuringMarkupCompilation>
    <UseWPF>true</UseWPF>
....

from cswin32.

@nick-beer, your question sounds unrelated to this source generator and more appropriate for the WPF audience. Can you try posting your question over on the dotnet/wpf repo?

from cswin32.

@AArnott - Shoot, I'm sorry. I'm not sure what repo I thought I was in - I just followed google from a search for IncludePackageReferencesDuringMarkupCompilation - a property that looked suspicious when debugging a build issue. I'll post to another repo - thanks!

from cswin32.

Ok, thanks @AArnott, I think we figured it out.

In the sample, the using path is Microsoft.Windows.SDK, but for some reason, in our project, it must be Microsoft.Windows.Sdk. Using that camel case seems to have fixed our issue. Such a small thing. :)

from cswin32.

It seems to be fixed in dotnet 6.

from cswin32.

True. The .NET 6 SDK includes the new behavior as on by default whereas .NET 5 SDK had it off by default.

from cswin32.

@MddMBorg Check out #601, which sounds like what you're hitting.

from cswin32.

I believe I'm running into some form of this issue with a package that contains C# files in its contentFiles (with buildAction="Compile"). Setting IncludePackageReferencesDuringMarkupCompilation (when using 5.0.102, as described) does not seem to help. Are contentFiles still broken with this workaround?

from cswin32.

Hello, we're trying to use CsWin32 with our .NET 5.0 WPF app and the steps above DO NOT work (we followed them exactly). We still continue to get the following error. What are we missing?

error CS0234: The type or namespace name 'SDK' does not exist in the namespace 'Microsoft.Windows' (are you missing an assembly reference?) [C:\Users\micha\source\repos\teams-client\windows-gui\windows-ui\Windows-UI_gbumtqzv_wpftmp.csproj]

Thanks in advance!

from cswin32.

@anti-matter, I have attached a .zip to a sample that works in our testing to the issue description. Does that work on your machine with dotnet build?

from cswin32.

Thanks @AArnott for the zip. That simple project works fine for me, but I still cannot get it to work in my project. I tried to find a setting that our project has set that might be causing our build to fail, but no luck.

I did notice too that intellisense still claims there's an error with Microsoft.Windows.SDK in the sample project, but the compiler seems to ignore that it's missing. In my case, the compiler does not ignore it.

Is there a release where we expect this issue to be resolved in WPF so the work-around is not necessary?

thx.

from cswin32.

but the compiler seems to ignore that it's missing. In my case, the compiler does not ignore it.

The compiler can't and isn't ignoring it. The compiler sees it where the IDE language service does not. So given the sample project works for you at the command line but your project does not work at the command line tells us that there is something peculiar with your project that prevents the source generator from running. I suggest you compare the build logs between the sample and your project. Use the /bl switch and use the viewer at http://msbuildlog.com and focus on the Csc task invocation's Analyzers parameter to see if there are differences, to start with.

Once you get the command line build working on your project, we can focus on what remains in the IDE that could be broken, but you should probably start with trying out 16.9 Preview 3 to see if that works for you, as a lot of source generator bugs have been fixed in that release.

Is there a release where we expect this issue to be resolved in WPF so the work-around is not necessary?

The fix is already released, but it requires opt-in via the property documented above.
It may be the default behavior in the .NET 6 SDK, but I haven't heard that confirmed.

from cswin32.

@anti-matter What sample uses Microsoft.Windows.SDK with all-caps for SDK? That's a bug and wouldn't work anywhere. The sample .zip in the issue description doesn't have this issue -- I just checked.

from cswin32.

@AArnott does this fix apply to WPF non-core (WPF framework?)?

i.e.

<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>        
    <TargetFramework>net45</TargetFramework>
    <IncludePackageReferencesDuringMarkupCompilation>true</IncludePackageReferencesDuringMarkupCompilation>
   ...

I didn't see the property when searched the binlog, so I'm guessing no. Is there a place I can file a bug to get this fixed there too?

from cswin32.

@inthemedium, I'm told that it should work, provided you are building with the required SDK version.

I didn't see the property when searched the binlog

Then something else is wrong, since you are setting the property, it should be there.

from cswin32.

If anyone has this problem in .NET 6, try to install 0.1.422-beta version.

from cswin32.

@zhylmzr, that's quite an old version of CsWin32. Do you find it works better than the latest version?

from cswin32.

@AArnott The newst version doesn't work in my environment, same error message.

from cswin32.

Does anyone have a fix for this in .NET 6? I have a WPF project but receive the following when compiling:

error CS0101: The namespace 'NameSpace' already contains a definition for 'Type'

Where the namespace and type is defined in my Source generator. This had no issues in .net 472 with SDK style project, but have recently upgraded.

The project has the following tags:

	<PropertyGroup>
		<OutputType>WinExe</OutputType>
		<TargetFramework>net6.0-windows</TargetFramework>
		<UseWPF>true</UseWPF>
		<UseWindowsForms>true</UseWindowsForms>
		<deterministic>false</deterministic>
		<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
		<EnableNETAnalyzers>true</EnableNETAnalyzers>
		<AnalysisLevel>none</AnalysisLevel>
		<IncludePackageReferencesDuringMarkupCompilation>true</IncludePackageReferencesDuringMarkupCompilation>
	</PropertyGroup>

from cswin32.