I have a problem with the code from trunk, when running a simple web service asmx file, eg. using the example from http://www.mono-project.com/Writing_a_WebService
It works fine, if there is no bin directory.
But as soon as there is a bin directory containing a dll that references "mscorlib, Version=18.104.22.168, Culture=neutral, PublicKeyToken=b77a5c561934e089", then I get the exception logged below.
I investigated the mscorlib files in my installation, and these are the files I find interesting:
I opened the 4.0 and 4.5 mscorlib.dll in ILSpy, and though they are different binary files, they have the same identity:
mscorlib, Version=22.214.171.124, Culture=neutral, PublicKeyToken=b77a5c561934e089
Would you be able to fix that in trunk, please?
Thank you very much,
Here is the exception:
CS1703: An assembly with the same identity `mscorlib, Version=126.96.36.199, Culture=neutral, PublicKeyToken=b77a5c561934e089' has already been imported. Consider removing one of the references
Description: Error compiling a resource required to service this request. Review your source file and modify it to fix this error.
Details: CS1703: An assembly with the same identity `mscorlib, Version=188.8.131.52, Culture=neutral, PublicKeyToken=b77a5c561934e089' has already been imported. Consider removing one of the references
Error origin: Compiler
Error source file: ~/DefaultWsdlHelpGenerator.aspx
Exception stack trace:
at System.Web.Compilation.AssemblyBuilder.BuildAssembly (System.Web.VirtualPath virtualPath, System.CodeDom.Compiler.CompilerParameters options) [0x00000] in <filename unknown>:0 at System.Web.Compilation.AssemblyBuilder.BuildAssembly (System.Web.VirtualPath virtualPath) [0x00000] in <filename unknown>:0 at System.Web.Compilation.BuildManager.GenerateAssembly (System.Web.Compilation.AssemblyBuilder abuilder, System.Web.Compilation.BuildProviderGroup group, System.Web.VirtualPath vp, Boolean debug) [0x00000] in <filename unknown>:0 at System.Web.Compilation.BuildManager.BuildInner (System.Web.VirtualPath vp, Boolean debug) [0x00000] in <filename unknown>:0
I found now a workaround:
mv 4.0 4.0bak
ln -s 4.5 4.0
As far as I understand: xsp4 is started from the 4.5 directory, and there is no xsp4.exe in the 4.0 directory.
Somehow, if the 4.0 directory has its own version of mscorlib.dll, that is wrongly linked in for dlls in the bin directory. By creating a symbolic link for 4.0, to point at 4.5, we are always using the same versions of mscorlib.dll
Perhaps this helps to fix the problem properly in the build for Mono 2.12
Happens also with Mono 2.11.3. I have searched in the default aspx file for web services and mscorlib.dll is not even imported in its web.config (for 4.5 directory)
This happens when using xsp4 with a recent version of Mono.
I investigates this a bit and the problem is that System.Web.UI.TemplateParser adds a reference to the 4.5 corlib, but Microsoft.CSharp.CSharpCodeProvider adds "/sdk:4".
You get the same error when you invoke:
mcs /r:"/Workspace/INSTALL/lib/mono/4.5/mscorlib.dll" /sdk:4 -- A.cs
Not sure what the correct fix it: make System.Web not include a reference to corlib when compiling ASP.NET web pages or make mcs decide the target framework based on the corlib reference.
Should be fixed in master
I built mono 3.0.3 from source and I'm having this same problem. How do I take action based on this incredibly cryptic error? It suggests removing one of the references, but I only have one reference to an assembly with that identity, and furthermore it's generating it for *all* of the references.
Is upgrading from previous versions of mono to 3.0.3 not supported?
I recently have built mono 3.0.3 from the tar file, and it worked fine, without any workarounds.
You might need to remove the previous version of mono, which is easier if you installed mono to a special directory, eg. rm -Rf /opt/mono.
Or you can try to install mono to a new directory, and change your paths accordingly:
Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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.
Create a new report for Bug 3582 on Developer
Community or GitHub if you have new information to add and do not yet see a matching
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
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.