Differentiating Between Win32 and .NET Assemblies Using ILDASM
Before you create an installation for a .NET application you need to identify some key information in your application -- some of the info is hidden pretty deep. Here are some tips to help you find the info you need to succeed.
- Gather all of the assemblies, Win32 and .NET, and their associated manifests into a common location.
- Determine where the assemblies are to be installed.
- Generate PrivateKeyTokens for the assemblies and digitally sign all the assemblies if they are to be installed to the Global Assembly Cache.
Win32 and .NET assembly
They are basically normal dll, ocx and exe not created on dot NET platform but still using the side-by-side sharing on Windows XP. They have external .manifest file. You can make any normal dll, ocx or exe into a win32 assembly by creating the proper .manifest file for it and keeping it with the file itself. .manifest has dependency dll and com information if any. Win 32 assembly can be two types: shared or private. Shared win32 assembly goes into folder C:\windows\winsxs and can be used by many applications. When we have .manifest isolation, in WPS we basically create a win32 assembly.
.NET assemblies are created using .NET and have an internal manifest. Just like win32, they can be one of two types: shared and private. Shared .NET assemblies goes into GAC (C:\windows\assembly). These assemblies should be installed using MSIassembly tables as mentioned in the earlier. Using GACUtil.exe is not a good practice to install assemblies into GAC.
Using ILDASM.exe to Differentiate
Identifying the difference Using ILDASM.exe
MSIL Disassembler (Ildasm.exe) ships with the .NET Framework SDK. The Ildasm.exe parses any .NET Framework .exe or .dll assembly, and shows the information in a human-readable format. Ildasm.exe shows more than just the Microsoft intermediate language (MSIL) code -- it also displays namespaces and types, including their interfaces. You can use Ildasm.exe to examine native .NET Framework assemblies, such as Mscorlib.dll, as well as .NET Framework assemblies provided by others or created yourself.
To get started, we open the WordCount sample, and load it into Ildasm.exe using the following command line:
This causes the Ildasm.exe window to appear, as shown in the following figure 1.
The tree in the Ildasm.exe window shows the assembly manifest information contained inside WordCount.exe and the four global class types: App, ArgParser, WordCountArgParser, and WordCounter.
By double-clicking any of the types in the tree, you can see more information about the type. In the following figure, the WordCounter class type has been expanded. See Fig 2.
The following figure explains what each graphic symbol means. Refer Fig 3.
Now double click on the manifest to see if this application assembly has any manifests.
To check whether a file is dot NET or win32 you can drag file to a utility ildasm and if shows manifest it is .NET otherwise a normal win32 dll.
This method is very useful to indentify and diffrentiate between a WIn32 assembly and .NET assembly.
Now you can install these assemblies in thier respective locations using Wise Package Studio and making the appropriate entries.