Bug 42702

Summary: Unnecessary dependency checks
Product: [Mono] Compilers Reporter: Nate McMaster <nate.mcmaster>
Component: C#Assignee: Marek Safar <masafa>
Status: CONFIRMED ---    
Severity: enhancement CC: atinc, luis.aguilera, masafa, mono-bugs+mono, mono-bugs+monodevelop, oleg.demchenko
Priority: Normal    
Version: 4.4.0 (C7)   
Target Milestone: ---   
Hardware: Macintosh   
OS: Mac OS   
Tags: BZSRC7, C8Beta1 Is this bug a regression?: No
Last known good build:
Attachments: Sample app

Description Nate McMaster 2016-07-20 23:15:06 UTC
# Steps to reproduce

1. Use an assembly that references “System.Data.Common, Version=”. Example: Microsoft.Data.Sqlite which is built for netstandard1.3 and references this asembly.
2. Install via NuGet.
3. Add instance of type that references a system.data.common type. (e.g. Microsoft.Data.Sqlite.SqliteConnection)
4. Add reference to System.Data
5. Build

# Expected behavior
Compiler should unify System.Data.Common to types from System.Data

# Actual behavior
 The type `System.Data.Common.DbConnection' is defined in an assembly that is not referenced. Consider adding a reference to assembly `System.Data.Common, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

# Supplemental info
MSBuild in VS 2015 works fine. This only applies to Xamarin Studio on OSX

# Test environment (full version information)

Xamarin Studio Business
Version 6.0.2 (build 69)
Installation UUID: 4a799370-fcb0-4bf4-afd8-de1edaf4ec61
	Mono 4.4.2 (mono-4.4.0-branch-c7sr1/4dff7a3) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 404020004

Not Installed

Apple Developer Tools
Xcode 7.3 (10183.3)
Build 7D175

Version: (Xamarin Business)
Hash: db3d76f
Branch: cycle7-sr1
Build date: 2016-07-18 15:40:25-0400

Version: (Xamarin Business)
Android SDK: /Users/namc/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		6.0 (API level 23)

SDK Tools Version: 25.1.2
SDK Platform Tools Version: 24.0.0
SDK Build Tools Version: 23.0.2

Java SDK: /usr
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

Android Designer EPL code available here:

Xamarin Android Player
Not Installed

Version: (Xamarin Business)

Build Information
Release ID: 600020069
Git revision: 9e0e96423ed474edf179c070b64ad03634012766
Build date: 2016-07-15 16:53:35-04
Xamarin addins: affe3f734f88d4f1ca34083ae3dde40dfc53d07a
Build lane: monodevelop-lion-cycle7-sr1

Operating System
Mac OS X 10.11.5
Comment 1 Lluis Sanchez 2016-07-28 17:36:36 UTC
Which kind of project are you adding the reference to? What's the target framework?
Comment 2 Nate McMaster 2016-07-28 21:22:24 UTC
@Lluis this happens when using a Xamarin.iOS or Xamarin.Android application.
Comment 3 Lluis Sanchez 2016-07-29 18:35:19 UTC
How are you adding Microsoft.Data.Sqlite to a Xamarin project? netstandard libraries are not supported by Xamarin.iOS or Xamarin.Android.
Comment 4 Nate McMaster 2016-07-29 20:30:19 UTC
Via NuGet. The latest beta release adds initial support .NET Standard.

Comment 5 Oleg Demchenko 2016-07-30 01:15:34 UTC
Setting this bug CONFIRMED, since I was able to reproduce this issue with latest C8 builds.

In attachments, you will find a sample app where PCL app references System.Data.Common NugGet build for .netstandard 1.3.

Env. details:
Comment 6 Oleg Demchenko 2016-07-30 01:16:28 UTC
Created attachment 16842 [details]
Sample app
Comment 7 Marek Safar 2016-08-10 14:07:35 UTC
Fixed in master and Mono 4.6
Comment 9 Marek Safar 2016-08-10 19:13:10 UTC
They should have the fix. Could you attach your test project
Comment 11 Marek Safar 2016-08-12 17:27:03 UTC
The issue is actually somewhere else. mcs is compatible with native csc (pre-Roslyn) but not with Roslyn which does better job in checking required dependencies.

The error is about missing reference not about unification.

Same error can be triggered with Roslyn if you use more realistic example like

    var oo = new PCL.CustomException();

This is not easy to fix with current design, would probably have to introduce LookupType path as alternative to Resolve