> You need to extract this processing into an executable of its own and
> give it a manifest that forces it to use Fx1.1.

"Phill W." wrote:

> Edgile wrote:
>
> > 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?
>
> 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.