C#/WinRT 1.4.1: Breaking change for projections

[angelazhangmsft]

C#/WinRT v1.4.1 includes AssemblyVersion changes in both the runtime and generated Windows SDK projection assemblies.

The AssemblyVersion changes are due to the fact that this version of C#/WinRT generates new helper methods for non-exclusive interfaces which are consumed by the generated code of a type implementing that interface. The impact of the AssemblyVersion changes is that components/C# projections built using this version of C#/WinRT and that implement interfaces from another C# projection (e.g., the Windows SDK or WinUI projection) will need an updated version of the dependent projection built using this version of C#/WinRT. Otherwise, you may see errors similar to the following:

Error CS0234: The type or namespace name 'IGraphicsEffectMethods' does not exist in the namespace 'ABI.Windows.Graphics.Effects' (are you missing an assembly reference?)

[Scottj1s]

For the Windows SDK projection, version 10.0.*.22 or later is required.

For Project Reunion, version 0.8.6 Preview1 or later is required.

The Windows App SDK has not yet been updated for this release.

[dotMorten]

@Scottj1s Is this why I'm seeing this?
I have an SDK build with .NET 6.0.201. used in an application built and run on a machine that only has 6.0.100

If I upgrade .NET SDK/Runtime problem goes away.

The callstack refers to a piece of code that hits the Windows.* APIs

[manodasanW]

@dotMorten it looks related, we had incremented the assembly version on the Windows SDK projection as part of the .NET SDK 6.0.201 update and your library when built with it has a dependency on it. But when it was consumed in an app using the .NET SDK 6.0.100 update, I would have expected a build time error when the references were resolved as we have a check for this in the .NET SDK that runs after ResolveAssemblyReferences. But that didn't seem to happen in this case and resulted in a runtime error. Is this binary dynamically loaded at runtime via some form of explicit call or is it a build time reference for the app?

[dotMorten]

@manodasanW No not dynamically loaded at runtime. I saw no compiler warning or anything. Just this sudden crash.
Regardless of whether a build error should happen or not, these dependency changes should not happen. We should be able to build an assembly with the latest 6.0 SDK, and still allow others to consume it with 6.0.100. Anything but that would be a breaking change (since there's no way in a nuget to define this minimum dependency of a runtime).

[dotMorten]

@manodasanW
I got a simple repro here you can just run from commandline:

curl https://dotnet.microsoft.com/download/dotnet/scripts/v1/dotnet-install.ps1 -o dotnet-install.ps1
powershell -ExecutionPolicy ByPass -command "./dotnet-install.ps1 -InstallDir .dotnet -Version 6.0.100"
md Sample
cd Sample
..\.dotnet\dotnet new wpf
powershell -Command "(gc Sample.csproj) -replace 'net6.0-windows', 'net6.0-windows10.0.18362.0' | Out-File -encoding ASCII Sample.csproj"
..\.dotnet\dotnet add package Esri.ArcGISRuntime.WPF --version 100.13.1
powershell -Command "(gc MainWindow.xaml) -replace '<Grid>', '<Grid><esri:MapView Map=\"https://www.arcgis.com/home/item.html?id=10df2279f9684e4a9f6a7f08febac2a9\" xmlns:esri=\"http://schemas.esri.com/arcgis/runtime/2013\" />' | Out-File -encoding ASCII MainWindow.xaml"
ECHO {"sdk":{"version": "6.0.100","rollForward": "disable"}} > global.json
..\.dotnet\dotnet run 

It looks like the app never launches, but in the event viewer you'll see:

Now run it again without the global.json file using latest .net sdk and it'll be fine. Or change the 100.13.1 version to 100.13.0 (which was built with an older .NET SDK) and it'll be fine.

The biggest problem here is there's just no way in my nuget package to specify this dependency.