Reg-Free COM for VB6 Projects

[dilettante]

Has anyone else been working with this "new" feature? It came out as part of Windows XP (and later Windows versions) and offers an improved answer to DLL Hell. Basically it takes the ".local" DLL Redirection feature in Win2K and its contemporaries (WinMe and Win98SE?) and then pushes it to the next level.

The idea is to take the COM registration metadata of your dependencies and place it into XML manifests, either as files or embedded as resources. Then you just place those dependency libraries alongside your EXE. No component library installation, no regsvr32 runs. It just works.

Microsoft hasn't done much to document it for VB6 developers, and they've done nothing that I've seen in the way of tool support. They're still developing it though, and the VB6 SP6 runtime and WinXP SP2 work together to expand Reg-Free COM for VB6 programs. Works great in Vista too!


It can't help with ActiveX EXEs and DCOM, and there are a few bumps and roadblocks I haven't worked around yet. So far I have it working for a number of my projects though. I quickly found I needed to automate the manifest generation process, it just takes too long by hand.

 

[BobRodes]

The concept has been fully developed in the .Net world. The reason that they haven't documented it is because they are attempting to move everyone off of the VB6 platform and onto the .Net one. What you're talking about is analogous to the concept of manifests in the .Net world.

 

[dilettante]

While .Net's Fusion/CLR does piggyback on Windows SxS isolation it only uses it directly to a limited extent. The use of manifests in Windows goes much further.

The de-emphasis of native code development is probably what led Microsft not to document it thoroughly. I suppose they don't provide many tools for creating isolated native code applications and assemblies for the same reason. The few they do offer are embedded in newer editions of Visual Studio or buried in the Platform SDK.

Microsoft intended isolation to support VB6 programs though. We can even find places where they modified the software to make sure it would work: FIX: Windows side-by-side execution is not supported for Visual Basic 6.0 ActiveX controls.

The title of that KB article is slightly misleading, and should really say "Windows side-by-side execution WAS not supported for SOME Visual Basic 6.0 ActiveX controls." Now nearly any in-process VB6 control will work with SxS isolation.

You can also find tidbits like:

Incidentally, existing code does not generally need to be altered to take advantage of Reg-Free COM. Setting up the proper configuration of manifests is all that may be required. In fact, the original intent of Reg-Free COM was to enable existing native applications, such as ones written in Visual Basic 6.0, C++, or some combination of languages.

Simplify App Deployment with ClickOnce and Registration-Free COM.


So you're absolutely right, it does use manifests. But it isn't .Net tech at all. I think that message has escaped people.

The only tricky part is creating sufficiently sophisticated manifests, something that is quite a clumsy process by hand. So far I haven't seen much to help a VB programmer, which is why I wrote my own VB6 manifest generator. Since then I've found one generalized commercial tool but that's about it.

The rewards can be fantastic: run from CD/flash drive, create cleaner & "greener" installs that don't put anything into System32 and don't write to the Registry, deployment to shared hosting where registering components isn't allowed, run different programs on the same machine using different versions of a component library, XCopy deployment, and so on.

It works for both early- and late-bound components, and it doesn't require any program changes. With a little more work we can probably even use ClickOnce to deploy VB6 programs... and I don't mean .Net-interop!


I've been working with this off and on for about 2 1/2 years now. My manifest generator is getting more mature, but I still find ways to improve it. I can now fully isolate a VB6 program that uses VB6 OCXs and DLLs that in turn use constituent OCXs and DLLs... well, ad infinitum basically. And the process is all but automatic.

So I was hoping to exchange tips and resolve issues with other programmers using reg-free COM. This is such a "dark corner" in need of exploration that I thought people might enjoy the challenge of discovery while getting some tangible benefits in return.

 

[BobRodes]

<But it isn't .Net tech at all.
No, I didn't mean to imply that it was. I should emphasize the word "concept" in what I said. And clearly, you know a great deal more about it than I do!

 

[dilettante]

Well if when you say "know a lot" you mean "have fooled around with it" ... why yes, guilty as charged. I've learned enough about it to realize how much I DON'T know.

I'm beginning to wonder if anyone knows a lot about the subject - though as I said there is one commercial tool out there. It looks like the product of a one-man microISV, and seems to be a sophisticated product.

If you wanted to look at the concept without spending time on research and theory you might try my reg-free packager in its current form. It is targeted at the P&D Wizard level of usage, as a tool and not a development speciality in itself. MMM Next Gen.

It's not even freeware grade, but I keep hoping Microsoft will release something that'll let me drop it.

 

[BobRodes]

<"know a lot" you mean "have fooled around with it"
Yes, isn't that the way of things?

 

[Chard07]

Hi Dilettante, thanks for MMM.

I am trying to use it to create manifests to invoke a small ActiveX DLL. The code of the DLL I have complete control over however the calling program I do not. I can configure the calling program to call my ActiveX DLL and if the DLL is registered it all works fine. However I would like to get this working without registering my DLL. Do you think that is possible?

What I have done is create a manifest for my DLL, and placed the DLL and the manifest in the same folder as the calling application. Then I created a VB6 exe with the same name as the calling application and referenced my DLL. Using MMM I created a manifest for this exe and placed it in the same folder as the calling app.

Now when I launch the app I get this error:

---------------------------
Microsoft Visual C++ Runtime Library
---------------------------
Runtime Error!

R6034

An application has made an attempt to load the C runtime library incorrectly.
Please contact the application's support team for more information.


Do you have any ideas on how I might get around this and accomplish my original intention?

Many thanks
Paul

 

[Chard07]

Ha! With a little more digging I think I found the answer to my problem.

I need to use mt.exe to embed the manifest in the C++ app. Of course, this may not be so desirable as then I would have to do the same thing every time a new version of the app is released.

Paul

 

[dilettante]

MMM creates only a simple "flat" application manifest instead of the more general scheme of application manifests that reference assembly manifests. Normally your DLL would have its own assembly manifest, and only that should be embedded in the DLL.

You seem to have created a template app manifest, hoping it will generically serve any client. Be warned that app manifests are expected to be tailored to each app, with a proper unique <assemblyIdentity/> with a correctly matching version attribute. It looks as if this doesn't matter all the time though or a lot of programs with a monkey-copied Styles manifest would be blowing up left and right.

How this is working for you with the app manifest embedded in a DLL escapes me. The specs don't seem to allow the scenario, but if it works! Have you tried this on various OSs? XP SP3? Vista?

Your component's dependencies (for example the VCRT) ought to be in an assembly manifest embedded in your DLL. The application manifest really isn't the right place for such things.

Once again though it seems to be working for you which is the main thing.

 

[Chard07]

Hi dilettante,

I am embedding the Manifest in an EXE not a DLL.

To summarize the EXE is not under my control and is written in C++. It has a feature where I can configure it to call out to my ActiveX DLL via COM. I was hoping to use a Manifest and thus avoid the need to register the DLL.

Is there a way of doing this without enbedding the Manifest?

Thanks
Paul

 

[dilettante]

The alternative may be to use an external manifest, one that is named [tt]your.exe.manifest[/tt].

If the EXE has an embedded manifest the external manifest will be used in Windows XP (through SP2) and Windows 2003 server. In Vista and WS08 the embedded manifest always takes priority.

I'm not sure what happens in XP SP3 yet.

 

[dilettante]

Small correction: WS03 also gives priority to embedded manifests.

All of the post-XP OSs have a registry entry that can be used to reverse this to XP behavior.

 

[Chard07]

Thanks Dilettante.

I couldn't get the external manifest to work. I may look at it again.

 

[wgcs]

I'm hoping that those experts who posted in this thread might take a look at the problem I'm having that I described in thread708-1491444 ... Please help... I'm tearing my hair out!!

(I've researched this alot... here's all the references I've found:

http://del.icio.us/wsteinford/reg-free-com

)

- Bill

Get the best answers to your questions -- See FAQ481-4875.

 

[kzmm]

Hi ,

i am trying to encapsulate reg free com component in a .net dll to make it easy to work in a collaborative development environment. So not everyone have to register the com component on their machine for the development in the project.
They just reference the .net dll. I am not able to figuring out what will be in the manifect file as .net dll is going to be use in main .net project.

Please help me in designing the manifect file for this scenario.

thanks

kazim

 

[dilettante]

I suspect you need to use your VS 200x IDE to set the component as "isolated" to do this. MMM only creates VB6 application manifests and so it won't be helpful to you in this.

 

[HughLerwill]

dilettante,

I have been interested by your MMM for some time but finally got it downloaded over the weekend; I thought it may be very complicated but it has not been and so far 'it just works'. It has taken you ages I expect, thanks and keep up the good work.

It seems very attractive to be able to have an 'App on a Stick', however, upgrade of an 'existing stick' can be complicated as you have noted elsewhere, and use of illicit copies of a 'Stickable' app would seem difficult to prevent.

Another issue to consider in 'Stickable' apps is they should consider data stored on the stick in relative paths rather than paths including the disk id letter because the disk id letter of a stick may be subject to change when the stick is moved from one computer to another.

 

[dilettante]

Glad to hear it works for you!

Those are some excellent points. I find that when making portable applications for use on flash "disks" relative paths are indeed usually the best solution. I typically put them in a Data, etc. folder under the EXE's folder, and rely on App.Path which is common practice anyway for one-off programs in VB6.

Upgrades can be done using a form of self-updater, but it is almost as good to use a self-extracting EXE for updates. There are a few around that will unzip everything to a temp folder on the hard drive, then run a specified program from the archive that can prompt the user to insert removable drives and provide the application path to be updated. This "installer" EXE can then copy in updated programs, etc. without disturbing data files or INI files.

If you're worried about copy protection for removable-drive software there are certainly some new challenges though.