Here is a trick that I found while looking at ways to handle .NET 2.0 while continuing to support .NET 1.1. The obvious way to support both is to build with VS2003 and use application configuration to direct the loader to prefer .NET 2.0 if available:
<?xml version="1.0"?>
<configuration>
<startup>
<supportedruntime version="v2.0.50727">
</supportedruntime><supportedruntime version="v1.1.4322">
</supportedruntime></startup>
</configuration>
That is OK, but what if you want to bind your assembly to .NET 2.0 and you don’t have the time to re-engineer your build and release processes?
OK, that is a lot of ifs, but it occurred to me that maybe ILMerge might work. ILMerge merges multiple assemblies into one, but what if it works with a single assembly? It turns out that it does:
ilmerge input.dll /out:output.dll
creates a new assembly that is bound to the CLR that ILMerge is running. Of course, it is stripped of its strong naming key and signcode key; so you have to deal with this seperately. The good thing is, though, that all of your resources (both managed and Win32) are in your resulting PE.
Of course, you can use ildasm and ilasm to do this too, but it takes more steps (or at least more attention to the arguments) to get the intended result.
About me
Main feed
Email subscriptions
