Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / CLR / September 2007

Tip: Looking for answers? Try searching our database.

enforcing .NET1.1 compatibility of autogenerated assemblies

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Edgile - 12 Sep 2007 09:48 GMT
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.


Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.