Use OCX without registering it

Question

Is it possible to use an ocx (ActiveX Control) on a winform (probably adding it programatically) without first having the ocx registered with regsrv32?

What I'm trying to achieve is to enable xcopy installation. I've had the "AxInterop..dll" and "Interop..dll" file generated from my dev machine.

I've seen the possibility of calling a COM dll without first registering it (ProSysLib, according to the author, but I haven't tested it yet), since ocx is also COM based, thus I assume that there must be some way to do that as well.

Solution 1

Yes, this can be done. You must assume your application will only be deployed on Windows XP (or Windows Server 2003) or later, and then you can use what is called 'registration free COM' to make this happen.

Essentially what you do is create a manifest file for the ActiveX control DLL so the Windows loader & COM DLL's know what its registration is without having to put that in the registry.

A walkthrough of what to do is in this article on MSDN: Registration-Free Activation of COM Components: A Walkthrough

"Step 6" and "Step 7" in that article contain everything you will need.

I just tried this out on one of my own C# programs that uses a Microsoft ActiveX grid control (the old "MS Flex Grid") and it works just fine. Make sure you create a manifest file for both your application and the COM DLL, and substitute the appropriate GUIDs in the right places. You may need to use OLEVIEW to dig out the right IDs to use from the ActiveX DLL if you don't have them handy.

Solution 2

Be warned that apparently using registry-free COM for COM components authored in .NET can randomly cause crashes on Windows XP!

Links: Stackoverflow question where I learned this, Microsoft knowledgebase article referred to in that question. There is a hotfix but you aren't allowed to redistribute it.

Solution 3

It is even a lot simplier in Visual Studio: just go to References, find positions created by your ocx (there should be 2, AxSomething and Something) and set for both of them Isolated: true in their properties. No manifestes, no code. You should now distribute your exe with dll file containing ocx. On your developement machine, the ocx can be registered.

Solution 4

Now, there is a copy of the unreachable click site solution: mmm4vb6.atom5.com/yes-update-0-12-5479.html#c on web archive: http://web.archive.org/web/20140828233304/http://mmm4vb6.atom5.com/yes-update-0-12-5479.html

and the context of:

Make My Manifest

Sunday, April 7, 2013

Yes, An Update

While I am not as active using VB6 for day to day work anymore, along the way my colleagues and I have needed to repackage some existing applications after bug fixes and just to cope with the changing Windows landscape.

We've made a few changes since the last version posted and things look good. I decided to post this update but please note that it has not been tested as thoroughly as most of the earlier releases!

So be sure to test your MMM'ed applications packaged using MMM 0.12 thoroughly before releasing them.

See the Change Log (Related\MMMChangeLog.txt) for details. Here are the notable changes though:

Another attempt to improve/correct the DPI-Aware node of the manifest. A change to TLB handling to prevent them from being included. TLBs are not normally needed at runtime. If you do need to include them add them yourself via Add Files or copy them to the target folder afterward. An attempt to cope with Microsoft patches that ended up causing "duplicate" coClass entries in MMM's manifests. Better (we hope) handling of non-creatable classes contained in some VB6-supplied OCXs. I hope this addresses some concerns you too may be facing in these areas. And of course I hope this version doesn't break anything or make things worse in some way.

Get the new version by downloading:

MMM-0-12

Posted at Sunday, April 7, 2013 02:59 PM ...

View more solutions