Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Differentiating Between Win32 and .NET Assemblies Using ILDASM

Created: 19 Oct 2007 • Updated: 19 Oct 2007 | 2 comments
Language Translations
R-Vijay's picture
0 0 Votes
Login to vote

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.

Information Needed

  1. Gather all of the assemblies, Win32 and .NET, and their associated manifests into a common location.
  2. Determine where the assemblies are to be installed.
  3. 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

Win32 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 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:

ildasm WordCount.exe

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.

Comments 2 CommentsJump to latest comment

R-Vijay's picture

Hi All,

Does anyone of us have any better idea than the one which is mentioned in this article?
If yes, then please share the same. I am need of detailed steps to re-package a .NET application.

Cheers'
Viju

Microsoft MVP [Setup-Deploy]
Weblog: www.msigeek.com

0
Login to vote
R-Vijay's picture

When installing assemblies to the global assembly cache, the installer cannot use the same directory structure and file version rules it uses when installing regular Windows Installer components. Regular Windows Installer components may be installed into multiple directory locations by different products. Assemblies can exist only once in the assembly cache. Assemblies are added and removed from the assembly cache atomically, and so the files comprising an assembly are always installed or removed together.

The Windows Installer uses a two-step transactional process to install products containing common language runtime assemblies. This enables the rollback of assembly installation and removal.

A two-step process extends the Windows Installer's transaction model to products containing common language runtime assemblies. This enables the installer to rollback unsuccessful installations and removals of assemblies.

During the first step, the Windows Installer uses the Microsoft .NET Framework to create one interface for each assembly. The Windows Installer uses as many interfaces as there are assemblies being installed. Committing an assembly using one of these interfaces only means that the assembly is ready to replace any existing assembly with the same name, it does not yet replace it. If the user cancels the installation, or if there is a fatal installation error, the Windows Installer can still rollback the assembly to its previous state by releasing these interfaces.

After the Windows Installer completes installing all assemblies and Windows Installer components, the installer may initiate the second step of the installation. The second step uses a separate function to do the final commit of all the new common language runtime assemblies. This replaces any existing assemblies with the same name.

Microsoft MVP [Setup-Deploy]
Weblog: www.msigeek.com

0
Login to vote