views:

56

answers:

3

I have a test utility that depends upon an ocx file that is installed/registered on my development machine. We'd like to run this tool on a test machine without polluting the machine with any unnecessary files. Nothing should be installed except the target machine software. Running the tool on a network drive or from a stand-alone directory copied to the test machine would be ideal. But, registering the ocx on the test machine is out of the question. Placing the ocx file in the same directory as the exe doesn't work. No matter what it still gives me this error--"The application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem." What else can I try? FYI, I'm using Visual Studio 2008.

A: 

The COM layer uses the Windows registry to translate the GUID to the component (DLL, OCX, EXE) that implements the functionality. I don't think there is another way to get around this.

Luckily (but not for you) Microsoft realized that this was a bit too complex and therefore .Net components don't necessary need this registration. Just putting the .Net DLL besides the application just makes it 'discoverable' by the application.

In your situation, could you use a virtual machine to test your component? If it is, you could

  • make a virtual machine image (without the registered component, but with everything else you need from Windows)
  • backup the virtual machine image
  • then start up the virtual machine with the image, register the component and test your application
  • after the test you can throw away the image and take the backup again to start with a fresh environment again
Patrick
A: 

PSExec may help here. We use it in an in-house system test tool that uses PSExec to execute remote programs on a another Winodws machine. This allows the test harness and all the dependencies to run on a (polluted) developer/test-harness machine, but the code under test to run on a squeaky clean vmware image.

mdma
+3  A: 

If we are talking about Windows XP+, then Microsoft has a capability called Reg-Free COM. Basically you create a manifest file for your EXE that calls into your DLL/OCX and it has all the registration information needed to make the COM call without actually registering it in HKCR.

http://msdn.microsoft.com/en-us/library/ms973913.aspx

Christopher Painter
I came to this same conclusion. I ran mt.exe against my ocx to give me the ocx manifest. I added a dependency to this ocx in the app's manifest file. Visual Studio auto-generated it's own manifest file which had dependencies to MFC/CRT dlls. With the help from article found at http://www.codeproject.com/kb/cpp/vcredists_x86.aspx, I copied the right MFC/CRT dlls/manifests to the app's directory. The versions of MFC/CRT dlls in the auto-generated manifest didn't match those copied. So, I updated them to match and everything worked. Still, I think it should be easier. Poor design in my opinion.
bsh152s
Personally I try to avoid COM-Interop from managed code whenever possible. P/Invoke isn't too horrible but I really, really dislike COM.
Christopher Painter