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...
Alias: None
Product: Runtime
Classification: Mono
Component: JIT ()
Version: unspecified
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2012-11-23 07:06 UTC by Pablo Ruiz García
Modified: 2012-11-30 12:57 UTC (History)
4 users (show)

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

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 GitHub or Developer Community 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 Pablo Ruiz García 2012-11-23 07:06:26 UTC

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:


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/'.
Mono: Assembly Loader probing location: '/usr/lib/mono/gac/System.ServiceModel/'.
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/

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

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.