tags:

views:

548

answers:

2

I have written a snap-in in c#.

I tried installing it using installutil and it didn't work at first. I notice that on the msdn page they said to run mmcperf to install the management.dll into the GAC.

Doing this, I was able to install my snap in and run it. I have an xp machine.

My question is how am I to deploy my custom snap in on a customer machine ... What are the things I need to consider ? (the OS?, the .net framework, is mmc 3.0 installed, etc?)

Can I run mmcperf during the installation of my snap in? Is this a good approach?

+1  A: 

You problem may be different, but I once ran into a similar issue on a 64-bit machine and found out the following. If your problem isn't related to 32/64-bit I can't say what the issue is, and I apologize for taking your time.

You should be able to install the snap-in using InstallUtil. However, note that there are two separate versions on InstallUtil: One (the default) for x86 binaries, and one for x64 binaries.

Even if you compile your C# code for Any CPU, using the standard InstallUtil will only register the MMC snap-in as a 32-bit snap-in. If you are running on a 64-bit OS, try starting MMC as a 32-bit process (MMC /32 IIRC) and see if your snap-in isn't available there.

To register the snap-in as a 64-bit snap-in, you must use the 64-bit version of InstallUtil (normally found in C:\Windows\Microsoft.NET\Framework64\v2.0.50727).

To register both versions of the snap-in, you must register it twice.

Mark Seemann
Thanks, even though it doesn't address directly my issue, it's good to know. I'm creating MSI with custom actions that Install the project output. If it's a 64 bit machine, Am I correct to assume that it will run installutil the 64 bit version during installation process?
pdiddy
I'm really not sure, but AFAIR msi files are either 32-bit or 64-bit, so unless it's explicitly a 64-bit MSI, I think it will be using the 32-bit version. However, you can pretty easily test this by opening MMC in 32-bit mode to see if your snap-in is available there. It really all boils down to under which node in the registry the snap-in is registered.
Mark Seemann
+2  A: 

Adding to Mark Seemann's response:

You can also check the MMC registry entries directly, to verify whether your snapin was registered in the 64 bit registry entries, or the 32-bit redirected registry (the one that shows up under Wow6432Node):

  • 64 bit snapin: HKLM\Software\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID}...
  • 32-bit snapin: HKLM\Software\Wow6432Node\Microsoft\MMC\SnapIns\FX:{SNAP-IN-GUID}...

If your entries are only under HKLM\Software\Wow6432Node then you've registered 32-bit snapins, and Mark's advice about running "MMC /32" should make them visible. That's not the end of the world: if you save your MMC session as a snapin shortcut, I think it opens the 32 bit version of MMC when run.

If you really want a 64-bit snapin registration (and why not?), MSDN has a page on MMC 64-Bit Versus 32-Bit Considerations with some more details, including which InstallUtil paths to invoke to get 64- vs 32- bit registry entries.

Note however that some MSI packaging applications actually include a copy of InstallUtil.exe within the MSI itself as a binary, instead of invoking the one on the target machine. (You can check if this is happening by looking at the MSI binary table and custom actions using Orca.) If only the 32-bit InstallUtil is included, it would put your registration in the wrong place (Wow6432Node), tough luck for you.

As I understand, the Windows Installer "Right Way"(TM) is to not use InstallUtil at all (I think mostly due to issues involved in running managed MSI custom actions?). In any case, if you avoided the use of InstallUtil you'd fully register your snap in by creating the registry entries explicitly in the MSI, putting Windows Installer in control of creating and removing them.

Alternately, you could make a custom action to invoke the InstallUtil.exe under the target machine's Framework64 folder. That would get the right snapin registration location, but then you'd have to deal with the fact that the custom action would pop up a CMD shell window while running, if that bothers you. Not sure if your MSI authoring tool has the equivalent, but in WiX there's the Quiet Execution Custom Action. (I suppose if you're not using WiX you could still include WixUtilExtension.dll and invoke "CAQuietExec64" after setting up the QtExec64CmdLine property appropriately... but if you're working at that level of MSI authoring you'd probably be better just to switch and use WiX :)

Daryn