Bug 44372 - Conflict with Microsoft's Win32 Registry Namespace: Xamarin version throws PlatformNotSupported
Summary: Conflict with Microsoft's Win32 Registry Namespace: Xamarin version throws Pl...
Status: RESOLVED ANSWERED
Alias: None
Product: Class Libraries
Classification: Mono
Component: mscorlib ()
Version: 4.8.0 (C9)
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Marek Safar
URL:
Depends on:
Blocks:
 
Reported: 2016-09-15 15:00 UTC by Stephen Rawlins
Modified: 2016-09-26 19:45 UTC (History)
6 users (show)

Tags: XATriaged
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED ANSWERED

Description Stephen Rawlins 2016-09-15 15:00:32 UTC
The current Xamarin.Android release includes the `Microsoft.Win32.Registry` object inside the `mscorlib` assembly. But most of the methods seem to throw a `PlatformNotSupported`.

In order to re-use a tried-and-true library, I implemented a compatible version within my Android compatible library. This creates a clashing namespace compiler exception when I build my app.

Is there a plan to implement the `Microsoft.Win32.Registry` functionality in Xamarin.Android in the future? Is there a reason the class exists but does not have much for an implementation?

The compile error we get with Xamarin.Android 6.1.x is:

The type ‘RegistryKey’ exists in both ‘[myLibrary]’, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null’, and ‘mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e’
Comment 1 Stephen Rawlins 2016-09-23 15:45:48 UTC
May we please have a status on this ticket?  It's been a week without any word from Xamarin.

Thank you,
Steve Rawlins
Zebra Technologies
Comment 2 Brendan Zagaeski (Xamarin Team, assistant) 2016-09-23 17:54:32 UTC
## Preliminary non-engineering-team bug review

Taking `RegistryKey` as an example for further study, that type has had 2 recent updates to match NETStandard 1.6 members:
https://github.com/mono/mono/commits/master/mcs/class/corlib/Microsoft.Win32/RegistryKey.cs

You can see in the "blame" view that those changes were mostly about adding "not supported" exceptions in empty method implementations:
https://github.com/mono/mono/blame/master/mcs/class/corlib/Microsoft.Win32/RegistryKey.cs

Providing empty implementations is a fairly common pattern in Mono for types that are in one of the cross-platform .NET profiles.  This allows Xamarin to target those profiles for the convenience of having portable assemblies that can be used across multiple platforms, but it does mean that attempting to _use_ methods that are not implemented in Mono will not work at run time.

In theory, I believe you could apply custom patches to `mscorlib.dll` to provide your own implementations.  The most direct way to get the expected build of `mscorlib.dll` could be to let the full Xamarin.Android build process create it [1].  It's probably also quite possible to compile just the Mono BCL assemblies, but figuring out the minimal steps needed could take some fiddling.  One you had the custom `mscorlib.dll`, you could then overwrite the default installed version of `mscorlib.dll` for Xamarin.Android with your custom version.  That will work for any deployment that doesn't use the Shared Runtime.  For the Shared Runtime, (unless you build your own custom Shared Runtime .apk) you can manually push the individual modified file to the .__override__ directory on the device.  More details on where to push that file can be provided if needed. (It might already be in the documentation, on Stack Overflow, or on another bug report. I'd have to look around a bit.)

The Xamarin.Android engineering team might also have some other ideas about this question.



Brendan
Xamarin Customer Support

[1] https://github.com/xamarin/xamarin-android/
Comment 3 Marek Habersack 2016-09-26 07:05:49 UTC
The Registry class itself doesn't throw any PlatformNotSupported exceptions, they are thrown from the RegistryKey class which is unavailable on any mobile Xamarin platform, not just Xamarin.Androiud. The reason for this was outlined in comment 2 by Brendan, but I'll reassign the bug to Marek Safar who made the changes and will probably be able to explain it in more detail.

As for the link error you experience, change your custom namespace and create an alias using clause which will let you use your class across platforms without problems:

namespace MyCustom.Win32
{
    class Registry { ... }
}

#if MOBILE
using Win32Reg = MyCustom.Win32;
#else
using Win32Reg = Microsoft.Win32;
#endif

class App
{
    static void Main ()
    {
          Win32Reg.RegistryKey rk = Win32Reg.Registry.LocalMachine;
    }
}
Comment 4 Marek Safar 2016-09-26 09:17:21 UTC
There are no plans to support Microsoft.Win32 on Android at the moment. The API was implemented to support netstandard.

You can easily use just your implementation in your code if you don't do using Microsoft.Win32 that way there should be no duplicate types in scope
Comment 5 Stephen Rawlins 2016-09-26 19:45:56 UTC
Thank you, everyone.  I also received, separately, a helpful response from David Hathaway by way of support@xamarin.com

We are reviewing our options.