There are two scenarios I need to clarify:
An executable compiled with .NET 3.5 needs to use a library compiled with .NET 1.1 and the library must run on the 1.1 runtime.
An executable compiled with .NET 1.1 needs to use a library compiled with .NET 3.5.
I cannot find a reliable source stating that it is not possible to load two versions of the .NET runtime and Microsoft's documentation is very vague on this matter.
No -- you can't load the CLR into the same process twice. See the documentation for CLR Hosting
As with earlier versions of the runtime, the CorBindToRuntimeEx function initializes the runtime. You can choose which version of the runtime to load, but a process can host only one version.
For case #1, is there any particular reason (say, breaking changes) which requires the library to be hosted in the 1.1 runtime? Is it possible to expose the library via a 1.1-compiled web service, and have the executable point to the web service instead? (Or some other remoting technique, to get the library in its own process?)
For case #2, is it possible to recompile the 1.1 app under 2.0/3.5, such that it can reside in the same process?
In any event, Rob Walker is right (and I upvoted) -- you simply can't host 2 versions of the runtime in the same process. So you need to work around it somehow. I'd imagine that in both cases, source must be available, so recompilations and retesting should play.
.NET 4 promises to enable hosting of different CLR versions in the same process by means of In-Process Side by Side.