How do I register ActiveX DLLs and OCXs using an application manifest?
Printable View
How do I register ActiveX DLLs and OCXs using an application manifest?
You can't. However you can use manifests instead of registering many components.
See Make My Manifest.
Could you be a bit more specific what I can and can't do with an application manifest? I have an executable and a DLL side by side, how do I make the exe realize it doesn't have to go to the registry to find the DLL?Quote:
Originally Posted by dilettante
An alternative I have had to use for a program updater is this
The dll goes into a resource file and sub Main checks if it exists, if not it is extracted and registered.
Well it isn't a simple topic but here is a partial list of things a manifest can be used for:Quote:
Originally Posted by alkatran
- Declare dependent side by side assemblies.
- Declare COM type information without registering components.
- Declare DLL redirection for standard (non-COM) DLLs.
- Select among alternate SxS code assemblies (this is the common way to use "XP styles" and to select alternate MSXML 4.0 assemblies).
- Declare a program to be DPI aware.
- Declare a program to be Vista+ aware and request an execution level.
- Declare a program to be specifically Vista/2008 or Win7/2008R2 aware.
What manifests don't do is register anything. Instead they offer a way to not need to register many DLLs and OCXs.
There is no nice digest of information on the topic or tutorial of any depth that is meant to help a VB6 programmer learn about application, assembly, and deployment manifests. There is some general information to be found in articles like:
Registration-Free Activation of COM Components: A Walkthrough
Simplify App Deployment with ClickOnce and Registration-Free COM
Deploying COM Components with ClickOnce
MSXML 4.0 Legacy Installation
High DPI
These only scratch the surface of a complex topic though. It is easier and in most cases more than adequate to use a post-build utility like the one I provided a link to earlier. That one is VB6 oriented and will generate and embed the necessary manifests into VB6 EXEs with only a little guidance, on the order of using the Package and Deployment Wizard that shipped with VB6.
In more complex cases you might still need to use a more advanced tool or create the necessary manifests by hand.
Most 3rd party articles on this topic are pretty rudimentary. Almost all of them go no deeper than adding an "XP styles" manifest to a VB6 program.
A very few people are successfully building manifests by hand that contain COM type info (i.e. bypassing registration) but most haven't written much on the subject. It only seems to be understood by a few VB6 programmers, and probably not that well really by any of us.
I only meant 'registration' in the sense of replacing registry entries with application manifest entries.
You've pretty much confirmed what I was guessing at, which is nice in a disappointing sort of way. I'll end up just continuing to use the registry.
usually when i dont have the dll file i need on my computer i either ask my brother if he has it or i go to dll-files.com and download them then put in same dictionary as the exe.
I think you may have missed the point of the question. Unless your brother happens to be on call for my customers and has all the DLLs I've written. hahahaQuote:
Originally Posted by Justa Lol
Well it works fine for me, but I use MMM to do the heavy lifting.Quote:
Originally Posted by alkatran
alka, no i didnt, i mentioned that i would download them too... if they are in the same folder as the exe, you usually dont need to register them.
If you put them in the EXE folder the VB6 runtime will self-register them in place.
This is bad because if you later delete your program folder, any other programs that use the same DLLs/OCXs will trip over the now-broken registration (that points to files no longer there).
Never do this!
I already have the DLLs in the same folder as the EXE, and they definitely don't self-register when I run the program.Quote:
Originally Posted by dilettante
Standard DLLs don't of course. But a COM DLL has to be or your program has no other source for the interface information it needs.
I've tested this and it does register the stuff if it isn't already registered on the machine. You can see this by using RegMon on first run on a clean system, or simply by doing a Find in RegEdit after the first run. Search for your library's full pathname or any of its progId or classId values.
My program has DLLs referencing other DLLs, so perhaps the executable doesn't add references to the indirectly referenced DLLs.Quote:
Originally Posted by dilettante