[Mono-bugs] [Bug 66237][Maj] Changed - remapping issue for assemblies targeting .NET 1.0 / 1.1 on Mono 2.0 profile

[bugzilla-daemon@bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by gert.driesen@pandora.be.

http://bugzilla.ximian.com/show_bug.cgi?id=66237

--- shadow/66237	2004-09-19 09:12:06.000000000 -0400
+++ shadow/66237.tmp.24054	2004-09-20 02:15:15.000000000 -0400
@@ -2,13 +2,13 @@
 Product: Mono: Runtime
 Version: unspecified
 OS: All
 OS Details: 
 Status: NEW   
 Resolution: 
-Severity: 
+Severity: Unknown
 Priority: Major
 Component: misc
 AssignedTo: mono-bugs@ximian.com                            
 ReportedBy: gert.driesen@pandora.be               
 QAContact: mono-bugs@ximian.com
 TargetMilestone: ---
@@ -90,6 +90,28 @@
 not : my apologies ...
 
 ------- Additional Comments From gert.driesen@pandora.be  2004-09-19 09:12 -------
 Created an attachment (id=10831)
 (gzipped) tar file containing repro
 
+
+------- Additional Comments From gert.driesen@pandora.be  2004-09-20 02:15 -------
+I was hoping to look into fixing this bug myself, but in order to 
+fix this bug I need to be able to determine the major, minor, build 
+and revision numbers that I should remap references too (meaning of 
+the current profile).
+
+When running on the 1.0 profile, references to 1.0.3300.0 System 
+assemblies need to be remapped to 1.0.5000.0, but when running on 
+the 2.0 profile then references to 1.0.3300.0 and 1.0.5000.0 need to 
+be remapped to 2.0.3600.0. And when the next .NET 2.0 beta or 
+release is supported, we'll also need to support remapping of 
+2.0.3600.0 system assemblies to that version.
+
+Until now remapping would only be done when the actual reference 
+could not be loaded, but in order to support remapping of 1.0 
+profile assemblies (1.0.5000.0) to 2.0 profile assemblies, we need 
+to perform remapping before the reference is loaded (as a reference 
+to a 1.0.5000.0 system assembly will succeed when running on the 2.0 
+profile, but you'd end up mixing 1.0.5000 and 2.0.3600.0 assemblies 
+which would lead to the results described above).
+