This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 8565 - Failed to create shadow copy (CopyFile). when referencing System.Runtime.Serialization from an 3.5 assembly running under mono 3.x (master)
Summary: Failed to create shadow copy (CopyFile). when referencing System.Runtime.Seri...
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: JIT (show other bugs)
Version: unspecified
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-11-23 07:06 UTC by Pablo Ruiz García
Modified: 2012-11-30 12:57 UTC (History)
4 users (show)

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


Attachments

Description Pablo Ruiz García 2012-11-23 07:06:26 UTC
Hello,

I am upgrading from mono 2.10.x to mono 3.x (3.0.1 with many backports from master) and I found that one of my apps (which uses ShadowCopy and which is still targeting .net35) fails due to an assembly remapping problem with System.Runtime.Serialization.dll.

The problem is related to a fix for issues #8037 & #6528 (e3b9881e5707953bd37fb3ed0dbeab93e6603a5e) which seems to be breaking shadow copy with programs targeting .net35 and referencing System.Runtime.Serialization.dll, as this assembly is installed at:

  mono/gac/System.Runtime.Serialization/3.0.0.0__b77a5c561934e089

But during remapping mono maps v3.0.0.0 to v3.5.0.0 and hence, shadow copying code does not finde the assembly there:

Mono: The request to load the assembly System.Runtime.Serialization v3.0.0.0 was remapped to v3.5.0.0
Mono: Assembly Loader probing location: '/usr/lib/mono/gac/System.Runtime.Serialization/3.5.0.0__b77a5c561934e089/System.Runtime.Serialization.dll'.
Mono: Assembly Loader probing location: '/usr/lib/mono/gac/System.ServiceModel/3.0.0.0__b77a5c561934e089/System.Runtime.Serialization.dll'.
Mono: Assembly Loader probing location: '/usr/lib/System.Runtime.Serialization.dll'.

However, I'm not sure if the correct fix for this should be made inside assembly remapping code, or if it should be just changing Makefile's infrastructure so System.Runtime.Reflection.dll gets installed into mono/gac/System.Runtime.Serialization/3.5.0.0__b77a5c561934e089.

Please I would be really thankfull to however can advise me on this.. ;)
Comment 1 Pablo Ruiz García 2012-11-23 07:07:08 UTC
Related to #8037 so, adding Marek to cc.
Comment 2 Pablo Ruiz García 2012-11-23 07:11:13 UTC
As additional context: Note that e3b9881e5707953bd37fb3ed0dbeab93e6603a5e fixes another problem with assembly remapping, but this time on .net40.

Just fyi.
Comment 3 Marek Safar 2012-11-23 07:24:32 UTC
This looks like the remapping logic is somehow broken. I don't know why it does v3 -> v3.5 remapping when 3.5 version does not exist (and should not exist)
Comment 4 Pablo Ruiz García 2012-11-23 07:30:30 UTC
From what I see, one fix could consist on adding another version_set to each MonoRuntimeInfo defined at mono/metadata/domain.c so I we cope with the case of assemblies which must be remapped to v4.0 on net4/net45, but which should be remapped to v3.0 (instead of v3.5) when targeting net2 or net3x.

This way I will increase MonoRuntimeInfo's version_sets array by one, and then rewrite supported_runtimes array as follows:

static const MonoRuntimeInfo supported_runtimes[] = {
 {"v2.0.50215","2.0", { {2,0,0,0}, {8,0,0,0},  { 3, 5, 0, 0 }, { 3, 0, 0, 0 } }},
 {"v2.0.50727","2.0", { {2,0,0,0}, {8,0,0,0},  { 3, 5, 0, 0 }, { 3, 0, 0, 0 } }},
 {"v4.0.30319","4.5", { {4,0,0,0}, {10,0,0,0}, { 4, 0, 0, 0 }, { 4, 0, 0, 0 } }},
 {"v4.0.30128","4.0", { {4,0,0,0}, {10,0,0,0}, { 4, 0, 0, 0 }, { 4, 0, 0, 0 } }},
 {"v4.0.20506","4.0", { {4,0,0,0}, {10,0,0,0}, { 4, 0, 0, 0 }, { 4, 0, 0, 0 } }},
 {"moonlight", "2.1", { {2,0,5,0}, {9,0,0,0},  { 3, 5, 0, 0 }, { 3, 0, 0, 0 } }},
};

NOTE: The '3, 5, 0, 0' version_set was already there, the one I would be adding is the found on the last 'column'. However, I think this is the reason for the v3->v3.5 remapping which Marek refers to.

With suchs changes, I could set System.Runtime.Serialization at framework_assemblies[] to point to the new version_set:

        {"System.Runtime.Serialization", 3},

However, as this is a crucial part of mono's runtime.. I am not sure if there some thing missing..
Comment 5 Pablo Ruiz García 2012-11-23 07:31:31 UTC
Adding kumpera to cc, as he might now about the remapping logic. (By inspecting github he added this v3.5 remapping (circa june 2010, 1d73b15a3b474570b82db3fb53e486f5505d7f50).
Comment 6 Pablo Ruiz García 2012-11-23 20:04:34 UTC
I just sent a pull-request with my proposed solution: https://github.com/mono/mono/pull/511

Greets
Comment 7 Rodrigo Kumpera 2012-11-27 12:32:47 UTC
Patch looks good. It must be under the MIT/X11 license for us to accept the contribution.

Thanks for looking into this.
Comment 8 Pablo Ruiz García 2012-11-27 12:34:44 UTC
Hi Rodrigo,

What's the procedure to comply with MIT/X11? Should I add some sort of header to changed files? or should I submit any sort of document to Xamarin?
Comment 9 Pablo Ruiz García 2012-11-30 11:01:00 UTC
I forgot to point here to the new pull-request: https://github.com/mono/mono/pull/513
Comment 10 Rodrigo Kumpera 2012-11-30 12:57:12 UTC
Merged. Thanks for the contribution.

Note You need to log in before you can comment on or make changes to this bug.