System.Xaml platform independence

[MarkPflug]

I was looking at using System.Xaml to serialize some state in an application. My usage is completely unrelated to windows and UI components. System.Xaml appears to be almost entirely platform agnostic, except for one reference to System.Windows.Extensions. As far as I can tell, the only type consumed in that library is System.Xaml.Permissions.XamlAccessLevel, which itself doesn't have any platform specific dependencies. If it was possible to move that XamlAccessLevel type into System.Xaml, and "forward" it from System.Windows.Extensions, that could make System.Xaml completely platform agnostic (as far as I can tell).

Would platform independence be a desirable property for System.Xaml to have?

[vatsan-madhavan]

Please take a look at #46, which I believe tracks the main discussion. Just realized that I did some research/thinking about this a while back but haven't jotted down my notes anywhere.

One key problem that has to be solved at a design level is whether to keep calling the hypothetical new assembly System.Xaml if it were made platform independent.

Imagine that a .NET 4.6 WPF application were to PackageReference a hypothetical plat-independent System.Xaml, Version>5.0 Would the markup-compiler and other XAML parsing in that older .NET 4.6 application's build-process and runtime environment continue to use the .NET Framework copy of System.Xaml, Version=4.0 (i.e, an older lower versioned System.Xaml), or would it use the newer System.Xaml assembly? Normally, our reference resolution rules would switch it over to the newer version, but that would create more problems for us (the new .NET Standard fork would be forever bound to be backwards compatible with .NET Framework 4.5 WPF's needs, the test matrix for the new fork would grow greatly on day-0 and so on).

On the other hand, if we were to rename System.Xaml to something else (for e.g., Microsoft.Xaml.dll) before forking it, it would force toolchains, tools, utilities etc. out there relying on System.xaml today (and the vendors who produce them) to create and maintain two versions (one for System.Xaml, and another for Microsoft.Xaml) - or choose one (and ignore the other).

This is not impossible to solve, but there isn't a simple approach either that can be put into effect easily. Whatever is chosen should be done with care and with a mind to minimize potential problems of these kinds.

[MarkPflug]

Thanks for pointing me to that other issue. I actually looked before I opened this, but didn't find that one. I'll close this issue then.