InstallUtil Publishing WMI Schema to 64 Bit Directory Instead of 32 Bit Directory

This is similar to this question, but it doesn't look like a good solution was ever determined, so I'm opening a new one with clarified details.

We wrote a .NET service, which among other things, publishes some of the class hierarchy using WMI. On a 64-Bit machine (running Windows 2008 R2 Server), we are running the 32-bit version of InstallUtil to install the service. It installs successfully, but when the service runs, we receive the following error message when publishing a WMI class using Instrumentation.Publish()

DirectoryNotFoundException - (Could not find a part of the path 'C:\Windows\system32\WBEM\Framework\root\MyNamespace\MyService'.)

However, this directory does exist in the C:\Windows\syswow64 directory. If we manually copy that directory structure to the system32 directory, then everything works. However, we are looking for an automated solution, because we have this packaged up in an MSI which we distribute onto many servers.

We have开发者_运维问答 tried running the 64-Bit version of InstallUtil, to see if that would work, however... and this is the really weird part... it gives us an error on install that says

Installing WMI Schema: Started

An exception occurred during the Install phase. System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Windows\system32\WBEM\Framework\root\MyNamespace\MyService.mof'.

It looks as if somehow, the WMI installer flipped around. Has anyone else experienced this, or know of a work around?

I was looking for an answer for this very same issue. I now this is a bit late but to you and the other readers. We have found that it works fine when we use command

C:\Windows\Microsoft.NET\Framework64\v2.0.50727\InstallUtil.exe

instead of,

C:\Windows\Microsoft.NET\Framework\v2.0.50727\InstallUtil.exe.

the 64 on the Framework directory is what tripped us up. If you have already solved your problem, then I hope I helped others searching for an answer to the same problem.

I know this response is even later, but perhaps it may help other people as well -

I found that if you're running the install utility from the command line, if you don't run it as administrator you run into bizarre issues, we had something similar to this and opened up the command using "run as administrator" and the issues evaporated. Might not solve your issue, but worth giving it a try.