Bug 43494 - Including System.Reactive nuget ends up with warning about System.Runtime.InteropServices.WindowsRuntime
Summary: Including System.Reactive nuget ends up with warning about System.Runtime.Int...
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild ()
Version: 7.0 (C8)
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Jonathan Pryor
: 44165 ()
Depends on:
Reported: 2016-08-17 21:52 UTC by James Moore
Modified: 2017-04-08 23:40 UTC (History)
7 users (show)

Is this bug a regression?: No
Last known good build:

project tarball (21.05 KB, application/gzip)
2016-08-17 21:52 UTC, James Moore

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 Developer Community or GitHub 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:

Description James Moore 2016-08-17 21:52:10 UTC
Created attachment 17092 [details]
project tarball

Add the System.Reactive nuget to an FSharp Android project (project tarball included).  Compile.  Get warnings about:

        FSC:  warning FS0217: The referenced or default base CLI library 'mscorlib' is binary-incompatible with the referenced library '/Users/james/Projects/Testing7/TestingFS/../packages/System.Runtime.InteropServices.WindowsRuntime.4.0.1/lib/netstandard1.3/System.Runtime.InteropServices.WindowsRuntime.dll'. Consider recompiling the library or making an explicit reference to a version of this library that matches the CLI version you are using.
Comment 1 James Moore 2016-08-17 21:52:26 UTC
=== Xamarin Studio Professional ===

Version 6.1 (build 5338)
Installation UUID: 6dc077b1-7f04-4c1c-b481-1dcbb9a8b0a1
	Mono 4.6.0 (mono-4.6.0-branch/e571108) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 406000138

=== NuGet ===


=== Xamarin.Profiler ===

Not Installed

=== Apple Developer Tools ===

Xcode 7.3.1 (10188.1)
Build 7D1014

=== Xamarin.iOS ===

Version: (Visual Studio Professional)
Hash: 40db5d1
Branch: cycle8
Build date: 2016-08-11 18:59:56-0400

=== Xamarin.Android ===

Version: (Visual Studio Professional)
Android SDK: /Users/james/Library/Developer/Xamarin/android-sdk-mac_x86
	Supported Android versions:
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.2    (API level 17)
		4.3    (API level 18)
		4.4    (API level 19)
		4.4.87 (API level 20)
		5.0    (API level 21)
		5.1    (API level 22)
		6.0    (API level 23)

SDK Tools Version: 25.2.2
SDK Platform Tools Version: 24.0.1
SDK Build Tools Version: 24

Java SDK: /Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home
java version "1.8.0_77"
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)

Android Designer EPL code available here:

=== Xamarin Android Player ===

Not Installed

=== Xamarin.Mac ===

Version: (Visual Studio Professional)

=== Build Information ===

Release ID: 601005338
Git revision: 860f5d2e358077f913badaf7b14c5532888bf12c
Build date: 2016-08-11 16:20:43-04
Xamarin addins: 8bea879bcb4de08213fff5812fd54323d79889d6
Build lane: monodevelop-lion-cycle8

=== Operating System ===

Mac OS X 10.11.6
Darwin retina.restphone.com 15.6.0 Darwin Kernel Version 15.6.0
    Thu Jun 23 18:25:34 PDT 2016
    root:xnu-3248.60.10~1/RELEASE_X86_64 x86_64
Comment 2 Brendan Zagaeski (Xamarin Team, assistant) 2016-08-20 19:05:27 UTC
## Confirmation status: confirmed

This appears to be an upstream bug in the System.Runtime.InteropServices.WindowsRuntime.4.0.1 NuGet package.

The NuGet package contains the following files that instruct Xamarin.iOS not to use the assembly:

But the NuGet package is missing the corresponding files for Xamarin.Android, so the NuGet package manager uses the next matching profile "netstandard1.3" instead.

I will hold off on marking the bug as UPSTREAM for the moment to get a double-check from the Xamarin engineering team on this evaluation.

### BAD Cycle 8 Beta 1 on Mac

Xamarin Studio 6.1 (build 5345)
Mono 4.6.0 (mono-4.6.0-branch/d0fc1a6)
Xamarin.Android (Cycle 8 Beta 1)

### BAD Cycle 7 – Service Release 1 on Windows

Visual Studio 2015 Update 3 Professional
XamarinVS (fcbe082)

## Steps followed to test

1. Create a new "Android > App > Android App > F#", or a new "Android > App > Blank Android App > C#" (I tested both).

2. Add the System.Reactive NuGet package (version 3.0.0) to the project.

## BAD Results

The NuGet package manager installs the "System.Runtime.InteropServices.WindowsRuntime.4.0.1" package and adds a reference to it in the project:


But Xamarin.Android already has its own version of that facade assembly:


### C# projects are affected by the same issue

Just for thorough reference, in C# projects the build fails with an error:

> Error CS1703: An assembly `System.Runtime.InteropServices.WindowsRuntime'
> with the same identity has already been imported. Consider removing one of
> the references

## GOOD Results with Xamarin.iOS

If I try the same steps to replicate in a Xamarin.iOS project, the NuGet package manager does install the "System.Runtime.InteropServices.WindowsRuntime.4.0.1" package, but it does _not_ add a reference to the redundant facade assembly.

This seems like it is the correct behavior in this scenario.

## BAD Results in Visual Studio 2015 Update 3

The NuGet package manager in Visual Studio 2015 Update 3 shows the same inconsistent behavior between Xamarin.Android and Xamarin.iOS projects.
Comment 3 Brendan Zagaeski (Xamarin Team, assistant) 2016-09-12 16:33:49 UTC
*** Bug 44165 has been marked as a duplicate of this bug. ***
Comment 4 Kent 2017-04-08 08:44:32 UTC
Any update on this? It's kinda a big deal, and is gonna be a huge blocker in the coming weeks as the community migrates towards netstandard.
Comment 5 Brendan Zagaeski (Xamarin Team, assistant) 2017-04-08 22:34:02 UTC
Non-engineering team status update

> It's kinda a big deal, and is gonna be a huge blocker in the coming weeks as
> the community migrates towards netstandard.

I'm not sure those statements are accurate for the exact symptom in this bug report.  This issue is not as generalizable as those statements seem to suggest.  As described in Comment 2, this issue appears to be a small upstream mistake in the files provided by the System.Runtime.Interop.Services.WindowsRuntime version 4.0.1 NuGet package.  It is possible to solve the issue by removing the superfluous reference.  (The package authors did not intend for System.Runtime.InteropServices.WindowsRuntime.4.0.1\lib\netstandard1.3\System.Runtime.InteropServices.WindowsRuntime.dll to be compatible with Xamarin.Android.)

For a bit of extra "volunteer weekend fun," I'll do a clean-up pass on this bug to check on various aspects of the current status.  That will perhaps help solidify how the issue is a packaging issue in the System.Runtime.Interop.Services.WindowsRuntime NuGet package.

## Verification status: verified UPSTREAM

NuGet package System.Runtime.Interop.Services.WindowsRuntime version 4.3.0 resolves this issue because it now properly includes the file (as mentioned in Comment 2) that instructs Xamarin.Android not to use the extra assembly:

(See also https://github.com/Reactive-Extensions/Rx.NET/issues/261)

> GOOD: System.Runtime.Interop.Services.WindowsRuntime NuGet version 4.3.0, installed by hand after adding the System.Reactive NuGet package
> BAD:  System.Runtime.Interop.Services.WindowsRuntime NuGet version 4.0.1, installed as a dependency of System.Reactive version 3.0.0 or version 3.1.1
Presumably the next time the System.Reactive NuGet package is updated, the package will be adjusted to take a dependency on the newer 4.3.0 version of System.Runtime.Interop.Services.WindowsRuntime.  In the mean time, System.Runtime.Interop.Services.WindowsRuntime can be updated by hand.

## Steps followed to test

1. Create a new "Android > App > Android App > F#", or a new "Android > App > Blank Android App > C#" (I tested both).

2. Add the System.Reactive NuGet package version 3.0.0 or 3.1.1 to the project (I tested both versions).

3. Attempt to build.

4. Install version 4.3.0 of the System.Runtime.InteropServices.WindowsRuntime NuGet package (https://www.nuget.org/packages/System.Runtime.InteropServices.WindowsRuntime/).

5. Attempt to build again.

The warning (for F#) or error (for C#) no longer occurs at step 5.

## Alternate workaround (as discussed in duplicate Bug 44165)

Manually remove the extraneous reference from the Android project.  The reference to remove is:


## Test environments

(I intentionally used the same older Stable versions from the last time I checked this bug's status to ensure that any changes in behavior could be attributed to the upstream NuGet package version.)

### Mac, Cycle 7 - Service Release 1

Xamarin Studio 6.0.2 (build 73)
Mono 4.4.2 (mono-4.4.0-branch-c7sr1/f72fe45) (64-bit)

### Windows, Cycle 7 – Service Release 1

The C# project demonstrates the same behavior as on Mac.  For some reason the F# project in this environment ignores the explicit reference to System.Runtime.InteropServices.WindowsRuntime.dll entirely (it doesn't appear anywhere in the diagnostic build output).  In any case, that does not alter the verification status for this particular bug: as on Mac, neither the C# nor F# build produces any warnings or errors about System.Runtime.InteropServices.WindowsRuntime when using version 4.3.0 of the NuGet package.

Visual Studio 2015 Update 3
XamarinVS (fcbe082)
Comment 6 Kent 2017-04-08 23:40:50 UTC
Thanks Brendan. I had already upgraded to 4.3.0, but now that I look at my error message again, it wasn't picking up the correct version - it was still complaining about 4.0.1. I've just tried a complete clean and rebuild, and now it works :)