Use Microsoft.NET.Sdk.WindowsDesktop for XAML projects

[tmat]

Switches projects that depend on WPF to Microsoft.NET.Sdk.WindowsDesktop SDK.

Enables building Roslyn.sln x-plat via dotnet build.

Note: dotnet pack will also work but not produce any VSIXes, as VSIXes can only be built using desktop msbuild/VS.

[tmat]

@nguerrera Seems to work fine :)

[nguerrera]

Nice. @vatsan-madhavan fyi

[tmat]

@vatsan-madhavan What is GeneratedInternalTypeHelper? Seems to be sometimes generated sometimes not.

[vatsan-madhavan]

What is GeneratedInternalTypeHelper? Seems to be sometimes generated sometimes not.

GeneratedInternalTypeHelper.g.cs is generated by MarkupCompilePass1, and derives from InternalTypeHelper.

When compiling a XAML file, you can use public types, but you can also use internal types subject to the same limitations that exist on code access to internal types. InternalTypeHelper enables support of internal access level types for markup. This involves the compiler creating a generated class that derives from InternalTypeHelper and implements its members. The generated class exists in a security and access context such that only the same assembly or other assemblies specifically attributed for shared internal access can reference the generated class and thus the internal types.

/cc @rladuca, @ryalanms

[tmat]

@vatsan-madhavan It seems that this file is not always generated, which is a problem. We need the class to be either always generated or never. The reason is that the class is public and thus becomes part of public surface of the assembly. We have an analyzer that validates that public surface has not changed accidentally and it does so by checking against a baseline. If we include the type in public API baseline but the file is not always generated then we get build errors and vice versa.

[vatsan-madhavan]

It seems that this file is not always generated

Depends on what one means by that.

(a) If a project generates GeneratedInternalTypeHelper.g.cs only sporadically without any corresponding changes in its sources, then that represents a likely bug in WPF's markup compiler.

(b) If GeneratedInternalTypeHelper.g.cs comes and goes as the project itself changes, that may very well be by design. XamlGeneratedNamespace.GeneratedInternalTypeHelper is generated only when WPF needs it. Typically, this happens when an internal type is referenced in the XAML, but the precise logic is a bit more involved and I can't give a full recounting of it ad lib.

(c) If GeneratedInternalTypeHelper.g.cs is present for some projects but absent for others, that's understandable, and also by design. This is similar to (b).

In general, I believe that it would be safe for public-API baseline analyzers to ignore XamlGeneratedNamespace namespace. This is because (b) and (c) are by-design and represent correct behavior; (a) represents a build-breaking bug - the build wouldn't normally reach the analyzer stage if GeneratedInterTypeHelper.g.cs were truly required but nevertheless absent due to a bug.

[tmat]

@vatsan-madhavan I think this is case (a). When I build the project locally and watch the obj directory this is what happens.
At some point GeneratedInternalTypeHelper.g.cs is created with a declaration of class GeneratedInternalTypeHelper and a few moments later it is replaced with an empty file. Seems like a bug. On CI the content of the file is not erased for some reason.

[tmat]

I can see .NET Framework targets imported:

Should they be? I thought by switching to WindowsDesktop SDK we remove the dependency on .NET Framework build targets.

[vatsan-madhavan]

You might be seeing dotnet/msbuild#4948. Are you seeing this under any under conditions besides (a) build engine is msbuild/VS and (b) TFM is netfx?

[vatsan-madhavan]

I thought by switching to WindowsDesktop SDK we remove the dependency on .NET Framework build targets.

That is indeed correct. Even when those get imported, WindowsDesktop SDK's targets will supersede _as long as the project is a Microsoft.NET.Sdk.WindowsDesktop project - but you'll need to be on 3.1.100+ SDK.

[tmat]

Are you seeing this under any under conditions besides (a) build engine is msbuild/VS and (b) TFM is netfx?

Yes, the same behavior (the file being generated and then its content erased) when building using msbuild and dotnet build (3.1.100 SDK).

The .NET Framework targets are only imported when using msbuild.

[vatsan-madhavan]

Yes, the same behavior when building using msbuild and dotnet build (3.1.100 SDK).

We'd be interested in seeing the logs for the dotnet build case in the dotnet/msbuild#4948 discussion. I don't think I've seen it under dotnet build.

[tmat]

@vatsan-madhavan Sent the log via email.

[vatsan-madhavan]

Yes, the same behavior (the file being generated and then its content erased) when building using msbuild and dotnet build (3.1.100 SDK).

Depending on the code/xaml being compiled, GeneratedInternalTypeHelper could be generated in MarkupCompilePass1 and subsequently removed in MarkupCompilePass2.

That doesn’t tell us why you might be seeing inconsistency across builds. For now my advice is to ignore XamlGeneratedNamespace from api-compat checks.

I’ll look into your binlog again in Jan when I’m back from vacation to see if it has any clues. If you have a small-ish project that can reproduce the problem consistently it would be helpful in debugging.

[tmat]

GeneratedInternalTypeHelper could be generated in MarkupCompilePass1 and subsequently removed in MarkupCompilePass2.

This is definitely not something I'd expect a build task to do - to update content of a file generated by other task.

If you have a small-ish project that can reproduce the problem consistently

I don't have a small project, but you can sync this PR branch and run

>C:\Roslyn\src\VisualStudio\Core\Def>dotnet build /bl:log.binlog /p:MSBuildTargetsVerbose=true

[tmat]

@vatsan-madhavan Ping.

[vatsan-madhavan]

@tmat Would you mind opening an issue for this on https://github.com/dotnet/wpf so that we could look into this ? Unfortunately I haven't had the time to dig into this further since I was out sick for a few days I'm now trying to catch up on a bunch of work...

[tmat]

Actually, there is a difference in behavior between 3.0.100 and 3.1.100. Seems like if we update to 3.1.100 it works.

[vatsan-madhavan]

Actually, there is a difference in behavior between 3.0.100 and 3.1.100. Seems like if we update to 3.1.100 it works.

Only thing I can think of that explains it is a combination of dotnet/wpf#2004 and dotnet/wpf#2075.

Glad to hear that this got better! 👍 😃 👍

[tmat]

@jaredpar PTAL

[tmat]

@jasonmalinowski @JoeRobich @sharwell

[jasonmalinowski]

Looks good, let's merge this after our 16.5 snap to avoid any surprises there unless we need it first.