Hello everyone,
I have a little app the generates and saves assemblies on the fly, similarly
to xsd.exe. While xsd.exe creates you source code, my stuff creates the dll
directly using System.Reflection.Emit.AssemblyBuilder. The app is built for
.NET1.1 therefore I do not use any .NET2.0 features like generics. However,
when the assembly generation process is executed on runtime 2.0 (e.g. the
process is started from VS2005) then the resulted assemblies are not willing
to run on the old 1.1 runtime anymore. That means that the AssemblyBuilder
class on framework 2.0 adds something to the resulted assembly that is only
2.0 compatible. Is there any way that I programatically can enforce backward
compatibility?
Thanx in advance!
Phill W. - 12 Sep 2007 13:42 GMT
> I have a little app the generates and saves assemblies on the fly, similarly
> to xsd.exe. While xsd.exe creates you source code, my stuff creates the dll
[quoted text clipped - 6 lines]
> 2.0 compatible. Is there any way that I programatically can enforce backward
> compatibility?
I suspect the answer is "no" and the reason is /far/ more fundamental
than just language features like Generics.
The output from this process is a compiled assembly - if that's
generated by an Fx2.0 tool/compiler, then it will have a hard-wired
dependency on Fx2.0.
Generally speaking, an Fx2.0 process can load an Fx1.1 assembly; an
Fx1.1. process /can't/ load an Fx2.0 assembly.
You need to extract this processing into an executable of its own and
give it a manifest that forces it to use Fx1.1.
HTH,
Phill W.
Edgile - 12 Sep 2007 15:04 GMT
Hello Phill,
Thanx for the quick answer.
> You need to extract this processing into an executable of its own and
> give it a manifest that forces it to use Fx1.1.
Currently the code is in two assemblies. A library with all the code
generation logic and an executable with the GUI. If needed, I can merge them
of course. But could you ellaborate a bit more on how do I "give it a
manifest that forces it to use Fx1.1"?
> > I have a little app the generates and saves assemblies on the fly, similarly
> > to xsd.exe. While xsd.exe creates you source code, my stuff creates the dll
[quoted text clipped - 22 lines]
> HTH,
> Phill W.
Günter Prossliner - 12 Sep 2007 15:42 GMT
Hallo Edgile!
> ...
> my stuff creates the dll directly using
[quoted text clipped - 3 lines]
> the process is started from VS2005) then the resulted assemblies are
> not willing to run on the old 1.1 runtime anymore.
Regardless if you use features of .NET 2.0 that has not been available
before... The new Compiler (and System.Reflection.Emit) generates the
Assembly's Metadata using the new Metadata-Format (which has been changed
from Version 1.x). The .NET 1.x CLR is not able to load 2.0 Assemblies.
> That means that
> the AssemblyBuilder class on framework 2.0 adds something to the
> resulted assembly that is only
> 2.0 compatible. Is there any way that I programatically can enforce
> backward compatibility?
You have to generate the Assembly using .NET 1.x. There is no other way.
Because you do not use the new CLR Features I'm wondering why you are using
.NET 2.0 in this case (.NET 1.x is still fully supported). Maybe
roundtipping with ILDASM / ILASM would be a (theoritical) possible way, but
I would not recomment such things.
GP
Edgile - 12 Sep 2007 22:56 GMT
Hello guys,
> The new Compiler (and System.Reflection.Emit) generates the
> Assembly's Metadata using the new Metadata-Format (which has been changed
> from Version 1.x).
First of all, thanx to everyone for the contribution. This explains the
problem and also that there is no direct solution.
> Because you do not use the new CLR Features I'm wondering why you are using
> ..NET 2.0 in this case (.NET 1.x is still fully supported).
Don't laugh! My VS2003 kept crashing and I got fed up and upgraded to VS2005
thinking that the output IL will still be the same as long as I forbore from
using 2.0 features. So you guys gave me the verdict for the ultimate
solution: format C: + reinstall. Or alternatively, I can ask my colleague to
compile it for me. He has a working VS2003 installed :))
Phill W. - 13 Sep 2007 13:07 GMT
>> Because you do not use the new CLR Features I'm wondering why you are using
>> ..NET 2.0 in this case (.NET 1.x is still fully supported).
>
> Don't laugh! My VS2003 kept crashing and I got fed up and upgraded to VS2005
You're not running on Vista by any chance are you?
The '2003 IDE is /not/ [officially] supported on Vista - only '2005 SP1 is.
HTH,
Phill W.
Mattias Sjögren - 12 Sep 2007 18:17 GMT
>Is there any way that I programatically can enforce backward
>compatibility?
If you have the .NET 2.0 SDK installed you can try running
Corflags.exe /Revertclrheader and see if the resulting binary loads
correctly under 1.1.
Mattias

Signature
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.