Bug 3582 - Cannot run XSP4 with Mono 3.0
Summary: Cannot run XSP4 with Mono 3.0
Status: RESOLVED FIXED
Alias: None
Product: Class Libraries
Classification: Mono
Component: System.Web (show other bugs)
Version: master
Hardware: PC Linux
: --- critical
Target Milestone: Untriaged
Assignee: Marek Safar
URL:
Depends on:
Blocks:
 
Reported: 2012-02-22 09:21 UTC by Timotheus Pokorra
Modified: 2013-02-18 01:00 UTC (History)
5 users (show)

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


Attachments

Description Timotheus Pokorra 2012-02-22 09:21:16 UTC
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=4.0.0.0, 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:
/opt/mono-2.10-git/lib/mono/2.0/mscorlib.dll
/opt/mono-2.10-git/lib/mono/2.0/mscorlib.dll.mdb
/opt/mono-2.10-git/lib/mono/2.0/mscorlib.dll.so
/opt/mono-2.10-git/lib/mono/4.0/mscorlib.dll
/opt/mono-2.10-git/lib/mono/4.0/mscorlib.dll.mdb
/opt/mono-2.10-git/lib/mono/4.5/mscorlib.dll
/opt/mono-2.10-git/lib/mono/4.5/mscorlib.dll.mdb
/opt/mono-2.10-git/lib/mono/4.5/mscorlib.dll.so

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=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

Would you be able to fix that in trunk, please?

Thank you very much,
  Timotheus


Here is the exception:

System.Web.Compilation.CompilationException
CS1703: An assembly with the same identity `mscorlib, Version=4.0.0.0, 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=4.0.0.0, 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
Comment 1 Timotheus Pokorra 2012-02-27 04:22:38 UTC
I found now a workaround:

cd /opt/mono-2.10-git/lib/mono
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
Comment 2 Dylan Borg 2012-09-11 12:27:58 UTC
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)
Comment 3 Martin Baulig 2012-11-09 02:10:21 UTC
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.
Comment 4 Marek Safar 2012-11-12 03:57:07 UTC
Should be fixed in master
Comment 5 Kevin Gadd 2013-02-17 19:38:27 UTC
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?
Comment 6 Timotheus Pokorra 2013-02-18 01:00:27 UTC
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:
./configure --prefix=/opt/mono-3.0.3
make
make install
export PKG_CONFIG_PATH=/opt/mono/lib/pkgconfig
export PATH=/opt/mono/bin:$PATH

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.


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 report.

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

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.

Related Links: