RegAsm regfile switch not giving same output as co

Question

Ok, I know this is pretty specific, but I lost my whole working day on it so I really need some rational explanation to it, so my boss and my wife wouldn't fire me

According to MSDN :
The /regfile switch "Generates the specified .reg file for the assembly"
The /codebase switch "Creates a Codebase entry in the registry specifiying the file path for an assembly"

I guessed that it was 2 different ways of doing the same stuff. Truth was, I was wrong :

METHOD 1

C:\>"C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" "C:\SERVER.dll" /regfile
Registry script 'C:\SERVER.reg' generated successfully

Reg File output :

REGEDIT4

[HKEY_CLASSES_ROOT\xfeed.server.X]
@="SERVER.XLS"

[HKEY_CLASSES_ROOT\xfeed.server.X\CLSID]
@="{8F4A5B5E-8DD7-30A3-993F-18C7E2C457CF}"

[HKEY_CLASSES_ROOT\CLSID\{8F4A5B5E-8DD7-30A3-993F-18C7E2C457CF}]
@="SERVER.XLS"

[HKEY_CLASSES_ROOT\CLSID\{8F4A5B5E-8DD7-30A3-993F-18C7E2C457CF}\InprocServer32]
@="mscoree.dll"
"ThreadingModel"="Both"
"Class"="SERVER.XLS"
"Assembly"="SERVER, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6e3de07ee666a5f5"
"RuntimeVersion"="v2.0.50727"

[HKEY_CLASSES_ROOT\CLSID\{8F4A5B5E-8DD7-30A3-993F-18C7E2C457CF}\InprocServer32\1.0.0.0]
"Class"="SERVER.XLS"
"Assembly"="SERVER, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6e3de07ee666a5f5"
"RuntimeVersion"="v2.0.50727"

[HKEY_CLASSES_ROOT\CLSID\{8F4A5B5E-8DD7-30A3-993F-18C7E2C457CF}\ProgId]
@="xfeed.server.X"

[HKEY_CLASSES_ROOT\CLSID\{8F4A5B5E-8DD7-30A3-993F-18C7E2C457CF}\Implemented Categories\        {62C8FE65-4EBB-45E7-B440-6E39B2CDBF29}]

METHOD 2

But when I execute the codebase switch command directly rather that using the reg file, the keys impacted in the regsitry are different (and work, on the contrary of the preceding output)

C:\>"C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" "C:\SERVER.dll" /codebase
Types registered successfully

Registry ouptut with codebase :

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{8F4A5B5E-8DD7-30A3-993F-18C7E2C457CF}]
@="SERVER.XLS"

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{8F4A5B5E-8DD7-30A3-993F-18C7E2C457CF}\Implemented Categories]

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{8F4A5B5E-8DD7-30A3-993F-18C7E2C457CF}\Implemented Categories\{62C8FE65-4EBB-45e7-B440-6E39B2CDBF29}]

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{8F4A5B5E-8DD7-30A3-993F-18C7E2C457CF}\InprocServer32]
@="mscoree.dll"
"ThreadingModel"="Both"
"Class"="SERVER.XLS"
"Assembly"="SERVER, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6e3de07ee666a5f5"
"RuntimeVersion"="v2.0.50727"
"CodeBase"="file:///C:/SERVER.DLL"

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{8F4A5B5E-8DD7-30A3-993F-18C7E2C457CF}\InprocServer32\1.0.0.0]
"Class"="SERVER.XLS"
"Assembly"="SERVER, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6e3de07ee666a5f5"
"RuntimeVersion"="v2.0.50727"
"CodeBase"="file:///C:/SERVER.DLL"

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{8F4A5B5E-8DD7-30A3-993F-18C7E2C457CF}\ProgId]
@="xfeed.server.X"

As you can notice, stuff is now in the Wow6432Node and infos are much more comprehensive (notably CodeBase !!!)

If anyone could give me a rational reason to this, so I could avoid mentioning paranormal activity as a cause for a lost working day, I would be very grateful

Answer 1

The codebase flag tells regasm that you want to register a DLL with a reference to the actual location of the file. This is useful if you have a dll being stored with a deployed application and you dont want it in the GAC. Without using this flag you must put your DLL in the GAC for its full functionality.

The regfile flag tells regasm that you want to output a registry file INSTEAD of actually registering the dll.

These can be used together if you want a registry file output that also contains the data for a dll location other than the registry, and I think you were assuming it was an either-or situation.

EDIT: Further explanation based on your Comment.

RegAsm normally registers the basic information about a .dll because the assumption is that it will be loaded into the GAC. Anything in the GAC is registered in a way that allows the system to control and load the assembly into memory. When you are on a 32bit system and use the codebase flag, it almost directly adds the "codebase" valuekey to the registry keys where the assembly is defined, then sets the value of this to the path where the .dll is physically located.

When registered this way, it basically tells the computer and anything looking to use the assembly where it can find the code, and how to load it into memory. Sometimes this causes extra keys beyond what the GAC would need so that a calling process knows the best way to access the assembly.

Now, since you are on a 64 bit system, you face an additional challenge. There are rules in place for keeping 32-bit and 64-bit applications separated throughout the computer. That is why there is 2 program files folders, and why the registry has the wow32 section. If a 32 bit dll gets registered, it needs to be stored in this section of the registry when it is done with the /codebase flag so that 32 bit applications can find it (this is the only part of the registry that they have access to). If it was a 64 bit dll, it would not need to be in this part of the registry.

Now, because of this information, if you are using the output of the file to write a registry script portion of an installer, you will want to check the target machine to determine whether the information needs to be in the users wow section, or normal section of registry, and make the appropriate change to this script before running it.