Question

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.

Was it helpful?

Solution

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

OTHER TIPS

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

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top