Bug 13370 - Compiler complains I am using System.ServiceModel when I am not
Summary: Compiler complains I am using System.ServiceModel when I am not
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild ()
Version: 4.8.x
Hardware: Macintosh Mac OS
: High normal
Target Milestone: 4.12.0 (KitKat)
Assignee: Jonathan Pryor
: 17790 ()
Depends on:
Reported: 2013-07-21 20:41 UTC by James Wilson
Modified: 2014-02-15 00:55 UTC (History)
11 users (show)

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

working case, or "I can't understand the issue at all" (330.81 KB, application/zip)
2013-07-24 04:56 UTC, Atsushi Eno
Test case that shows the error (13.78 KB, application/zip)
2013-11-21 17:48 UTC, Brendan Zagaeski (Xamarin Team, assistant)

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 Wilson 2013-07-21 20:41:59 UTC
I am using the new Portable Class Libraries and I am running into a few problems.  However, the biggest one is that I am getting an error from Xamarin Studio that says I am trying to use an assembly that is only accessible from the "Business Edition".  I use WCF with the regular .NET framework at work.  I am very familiar with the APIs and I am certain that I am not using it in my iOS and Android projects.  So I don't understand why I am getting the error.  I am on the beta channel for your products and just updated yesterday (July 20, 2013).  Any help would be appreciated.  Also, while we are on the subject, is there a list of assemblies that are not supported in the Indie version of Xamarin.iOS, Xamarin.Android, and Xamarin.OSX?  It would be really useful since a developer is apparently capable of adding the assemblies without any error until they build the project.  Below is a sample error message that I am receiving....thanks!


/Users/james/Dropbox/MyProject/MyProjectSolution/MyProjectAndroid/MyProjectAndroid.csproj (Build) ->
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets (_ScanAssemblies target) ->

	:  mandroiderror XA9003: Assembly `System.ServiceModel, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35` requires Business (or higher) License.

	 25 Warning(s)
	 1 Error(s)
Comment 1 Jonathan Pryor 2013-07-22 16:14:26 UTC
Related: the error messages should be improved to specify what assembly/type/member was referencing System.ServiceModel. As is, things are very opaque.

> It would be really useful since a developer is apparently capable of adding the
> assemblies without any error until they build the project.

A list of "assemblies to avoid" won't necessarily help either; the compiler and MSBuild projects only need an assembly reference for types that you directly use. "Implicit" assemblies references don't need to be explicit.

For example, assume that A.dll contains a reference to System.ServiceModel.dll, and A.dll is added to your project. Your project will not also need a reference to System.ServiceModel.dll unless you explicitly use a type that comes from System.ServiceModel.dll; the System.ServiceModel.dll reference is thus implicit, and may not be easily known by the developer. (This will be particularly true if reusing libraries that you didn't write, or if your memory is as bad as mine...)
Comment 2 Mikayla Hutchinson [MSFT] 2013-07-22 16:17:53 UTC
Normally the IDE would prevent you from adding the assembly without upgrading, however the issue in this case is that while building aby project that references a PCL 4.5 assembly, it implicitly references all the PCL type "Façade" forwarder assemblies, including System.ServiceModel, even if they're not actually used. The Android build code needs to check whether assemblies are used, not simply whether they're referenced.
Comment 3 James Wilson 2013-07-22 17:51:59 UTC
That makes a lot of sense.  Just an FYI, it is also happening with Xamarin.iOS as well.  Please let me know if there is any other information I can provide.

Compiling to native code
/Developer/MonoTouch/usr/bin/mtouch -sdkroot "/Applications/Xcode.app/Contents/Developer" --cache "/Users/james/Dropbox/MyProject/MyProjectSolution/MyProjectiPhone/obj/iPhoneSimulator/Debug/mtouch-cache" --nomanifest --nosign -sim 
"/Users/james/Dropbox/MyProject/MyProjectSolution/MyProjectiPhone/bin/iPhoneSimulator/Debug/MyProjectiPhone.app" -r 
"/Users/james/Dropbox/MyProject/MyProjectSolution/NoesisIngenuity.Framework.iOS/bin/Debug/NoesisIngenuity.Framework.iOS.dll" -r 
"/Users/james/Dropbox/MyProject/MyProjectSolution/MyProject.BusinessLogic/bin/Debug/BrewNote.BusinessLogic.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.dll" -r 
"/Developer/MonoTouch/usr/lib/mono/2.1/System.Xml.dll" -r 
"/Developer/MonoTouch/usr/lib/mono/2.1/System.Core.dll" -r 
"/Developer/MonoTouch/usr/lib/mono/2.1/monotouch.dll" -r 
"/Developer/MonoTouch/usr/lib/mono/2.1/System.Xml.Linq.dll" -r 
"/Developer/MonoTouch/usr/lib/mono/2.1/System.Data.dll" -r 
"/Developer/MonoTouch/usr/lib/mono/2.1/MonoTouch.Dialog-1.dll" -r 
"/Users/james/Dropbox/MyProject/MyProjectSolution/Components/xamarin.auth-1.0.2/lib/ios/Xamarin.Auth.iOS.dll" -debug -nolink -sdk "6.1" -targetver "5.0" --abi=i386 "/Users/james/Dropbox/MyProject/MyProjectSolution/MyProjectiPhone/bin/iPhoneSimulator/Debug/BrewNoteiPhone.exe"

error MT9003: Assembly `System.ServiceModel` requires Business (or higher) license.
Comment 4 Atsushi Eno 2013-07-22 18:40:49 UTC
I don't quite support the idea of scanning everything in depth and search for any use of WCF or other business-only assemblies because it adds extraneous assembly scan cost.

What we could do instead is skip any business-only check for PCLs. Non-business user won't be able to ship any WCF-dependent apps anyways.
Comment 5 Jonathan Pryor 2013-07-23 11:51:28 UTC
@Eno: I largely agree with you: scanning everything would really slow things down.

@James: Can you please run an experiment for me?

"Normally", the resulting assembly only contains assembly references for assemblies which are actually used:

$ cat > hw.cs <<EOF
class Hello {
    public static void Main () {
        System.Console.WriteLine ("Hello, World!");]
$ mcs hw.cs -r:System.Data.dll
$ monodis hw.exe | grep Data
# no matches

In the above, even though the compiler is referencing System.Data.dll, the resulting hw.exe assembly does not contain an assembly reference.

The same is true if I use .NET CSC.EXE.

The question is, do PCL assemblies behave the same way? I would expect them to, but apparently not?

James: can you create a PCL "v2" (System.Runtime-based) assembly which references but does not use an assembly, and see if the resulting assembly contains an assembly reference to the unused assembly?

If it doesn't, then there shouldn't be a problem (and there shouldn't be a bug here!)

The fact that there is apparently a bug here implies that the assembly reference is being preserved, which seems rather odd.

 - Jon
Comment 6 Atsushi Eno 2013-07-24 04:56:23 UTC
Created attachment 4408 [details]
working case, or "I can't understand the issue at all"

Actually I quite don't understand the issue, or the scope of the issue, or the entire thing (I believe anyone who understand the problem, instead of totally irrelevant person == I, should work on it). I tried to reproduce the issue like this:

- Create a PCL using VS2012 (as XS cannot create valid PCL)
- Create an XA app using XS.
- Reference the resulting dll in the XA app.
- Build.

IT just worked without any licensing limitation (as long as I did it right).

How could this problem even reproduce? Sounds like such a problem indeed exists but the description is broad and does not seem to precisely limit the repro condition.
Comment 7 James Wilson 2013-07-24 09:32:28 UTC
Hi Jon,

I will do that tonight or tomorrow evening and let you know what I find.


Comment 8 James Wilson 2013-07-28 18:18:01 UTC
Hi Jon,

I don't know what happened.  I think on Friday there was another update to the Mono framework.  I updated it, and now when I make a new Portable class library I get the old options (.NET 4, Silverlight 4, Xbox 360, and Windows Phone 7).  Sorry I couldn't help more.  When the PCLs arrive on the Beta channel again, I'll give it another try.

Comment 9 Atsushi Eno 2013-08-06 01:18:33 UTC
NEEDINFO as per comment #6
Comment 10 James Wilson 2013-08-06 06:39:08 UTC
Hi Atsushi,

At the time I filed the bug, XS on Mac OS was able to create PCLs from the beta channel.  Maybe it was prematurely released up to that channel, I'm not sure.  However, PCLs are no longer supported on the beta channel (after my last upgrade) so I am unable to try and reproduce the problem.

The issue was that XS was saying at the end of the build process that I was trying to use System.ServiceModel.  As an owner of the indie version of Xamarin.iOS and Xamarin.Android I do not have access to any WCF components.  I've worked heavily with WCF and am 100% positive that I was not referencing them.

I can't test it out on VS2012 like you did because I do not have a copy of that IDE.  From what Michael said, it seems that XS was trying to build all the dlls that were available from the PCL configuration I setup, and not just the ones I was using.

Essentially System.ServiceModel was compiling into my project because it was available from the PCL configuration I had, even though I didn't actually add or reference System.ServiceModel in my PCL project.  Does that clarify the issue?
Comment 11 Atsushi Eno 2013-08-06 10:49:40 UTC
Yes thanks. Yet there could be updates from our developers, so I'd keep it NEEDINFO. I'd close it once the issue is really gone.
Comment 12 René Ruppert 2013-10-17 16:23:07 UTC
Maybe this forum post adds more insight: http://forums.xamarin.com/discussion/9124/mvvmcross-example-n-22-cannot-be-built-with-xamarin-indie-edition-why
Comment 13 Atsushi Eno 2013-10-18 00:17:57 UTC
No it doesn't...
Comment 14 René Ruppert 2013-10-19 16:16:29 UTC
I've got it now in and Android project where I reference a PCL that contains only one single class/file. That class used to be in the Android project directly and it worked. Moving it to the PCL results in:

:  mandroiderror XA9003: Assembly `System.ServiceModel, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35` requires Business (or higher) License.
	Task "ScanAssemblies" execution -- FAILED
	Done building target "_ScanAssemblies" in project "/Users/rene/Documents/Develop/Test.Android/QUIWeek1.Android/Test.Android.csproj".-- FAILED
Done building project "/Users/rene/Documents/Develop/Test.Android/QUIWeek1.Android/Test.Android.csproj".-- FAILED

The only references in the PCL are:

System, System.Collections, System.Core, System.ObjectModel, System.Runtime and System.Xml

The only class in there is an implementation of ICommand.

Referencing the same PCL in another solution that does not contain an Android project works fine.
Comment 15 Brendan Zagaeski (Xamarin Team, assistant) 2013-11-21 17:48:37 UTC
Created attachment 5505 [details]
Test case that shows the error

## Steps to reproduce

Attempt to compile the "TestApp" project in this test case while logged in with an Indie license.

## Result

> Assembly `System.ServiceModel, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35` requires Business (or higher) License.

Some additional discussion on [1], where I suggested incorrectly that Profile136 does not reference the System.ServiceModel facade assembly. *All* of the PCL profiles available for Xamarin reference the System.ServiceModel facade assembly [2]. I'm not sure why Profile136 behaves differently.

> [1] http://forums.xamarin.com/discussion/9132/system-servicemodel-requires-business-edition-but-system-servicemodel-is-not-referenced

> [2] http://msdn.microsoft.com/en-us/library/vstudio/gg597391(v=vs.100).aspx

## Additional interesting result

1. After freshly unzipping the test case, change the Profile78Library to Profile136 under "Project Options -> General."

2. Build the TestApp.

3. The build succeeds.

### Compare this to...

1. After freshly unzipping the test case, attempt to build the TestApp.

2. Close the upgrade dialog.

3. Switch the Profile78Library to Profile136.

4. Clean both projects, and optionally manually delete the `bin/` and `obj/` folders from the projects.

5. Attempt to build the TestApp.

6. The build fails again.

7. Close the solution.

8. Reopen the solution.

9. Build the TestApp.

10. The build succeeds.

## Version information

Tested in Xamarin.Android 4.10.1.
Xamarin Studio 4.2.1
Comment 16 Brendan Zagaeski (Xamarin Team, assistant) 2013-11-21 18:07:31 UTC
After a few more minutes of testing, it appears that all the "4.0" profiles work, while all the "4.5" profiles fail.

Steps used to test the various profiles:

1. Switch the profile of the Profile78Library project.

2. Quit Xamarin Studio.

3. Delete the `bin/` and `obj/` folders from both projects.

4. Re-open the solution in Xamarin Studio, and build the TestApp.

Using these particular steps seems to be the best way to keep the behavior consistent.
Comment 17 Todd Aspeotis 2013-12-11 03:09:29 UTC
I need the .NET 4.5 PCLs for MvvmCross. I'm running the trial of Xamarin Android Business to make it work (for the moment).

Xamarin Studio 4.2.2 (build 2)

PRE: Install NuGet support for Xamarin Studio
1. Make new Android app
2. Add MvvmCross.HotTuna.MvvmCrossLibraries
3. Build
Comment 18 Jonathan Pryor 2013-12-20 12:12:51 UTC
The problem is due to the interaction of PCL facade assemblies and how Starter edition blacklists assemblies.

In certain scenarios, such as this one, when a PCL assembly is referenced they _all_ are implicitly referenced by the compiler, even if no types are actually used. Because of this, the System.ServiceModel.dll is implicitly referenced by the PCL assembly [0].

Meanwhile, Starer edition blacklists some things by their assembly name, while other things are blacklisted by their type name. System.ServiceModel.dll was on the assembly name blacklist.

Result: XA9003 because System.ServiceModel.dll was implicitly referenced.

This is fixed in monodroid/7a132c38 by changing the blacklist to blacklist by-type instead of by-assembly name. This allows the implicit System.ServiceModel.dll assembly referenced to succeed, and removes the XA9003 error.

[0]: Compilation; note that System.ServiceModel.Http.dll has an implicit reference to System.ServiceModel.dll, which is blacklisted.

> Target CoreCompile:
> Skipping target "CoreCompile" because its outputs are up-to-date.
> Target _ResolveAssemblies:
> 	ResolveAssemblies Task
> 	  ReferenceAssembliesDirectory: path/to/xbuild-frameworks/MonoAndroid/v4.4;path/to/lib/xbuild-frameworks/MonoAndroid/v1.0;path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/
> 	  I18nAssemblies: 
> 	  LinkMode: None
> 	  Assemblies:
> 	    bin/Debug/TestApp.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/System.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/System.Xml.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v4.4/Mono.Android.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/System.Core.dll
> 	    ../Profile78Library/bin/Debug/Profile78Library.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Collections.Concurrent.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Collections.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.ComponentModel.Annotations.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.ComponentModel.EventBasedAsync.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.ComponentModel.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Diagnostics.Contracts.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Diagnostics.Debug.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Diagnostics.Tools.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Dynamic.Runtime.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Globalization.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.IO.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Linq.Expressions.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Linq.Parallel.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Linq.Queryable.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Linq.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Net.NetworkInformation.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Net.Primitives.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Net.Requests.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.ObjectModel.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Reflection.Emit.ILGeneration.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Reflection.Emit.Lightweight.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Reflection.Emit.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Reflection.Extensions.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Reflection.Primitives.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Reflection.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Resources.ResourceManager.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Runtime.Extensions.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Runtime.InteropServices.WindowsRuntime.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Runtime.InteropServices.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Runtime.Numerics.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Runtime.Serialization.Json.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Runtime.Serialization.Primitives.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Runtime.Serialization.Xml.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Runtime.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Security.Principal.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.ServiceModel.Http.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.ServiceModel.Primitives.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Text.Encoding.Extensions.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Text.Encoding.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Text.RegularExpressions.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Threading.Tasks.Parallel.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Threading.Tasks.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Threading.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Windows.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Xml.ReaderWriter.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Xml.Serialization.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Xml.XDocument.dll
> 	    /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Xml.XmlSerializer.dll
> 	  Assembly /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/System.dll is ignored: system assembly is used instead.
> 	  Assembly /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/System.Xml.dll is ignored: system assembly is used instead.
> 	  Assembly /path/to/lib/xbuild-frameworks/MonoAndroid/v4.4/Mono.Android.dll is ignored: system assembly is used instead.
> 	  Assembly /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/System.Core.dll is ignored: system assembly is used instead.
> 	  Assembly /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Windows.dll is ignored: system assembly is used instead.
> 	  Assembly /path/to/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Xml.Serialization.dll is ignored: system assembly is used instead.
Comment 19 Prashant manu 2014-01-03 01:36:20 UTC
I have checked this issue with following builds:

All Mac
X.S 4.2.3(build 23)
Mono 3.2.6
X.Android 4.12.0-1

I have build the attached test project when logged-in with Indie account. Now project build successfully and dose not prompt us to upgrade license. It is using profile 4.5 with Indie license.
Comment 20 James Wilson 2014-01-06 03:52:23 UTC
Thanks for all the hard work.  Once it gets to the beta build I can retest it myself.
Comment 21 Mikayla Hutchinson [MSFT] 2014-02-15 00:55:43 UTC
*** Bug 17790 has been marked as a duplicate of this bug. ***