VB6 Reg-Free Packager
For the past few years I've been working off and on developing an XCopy packager for VB6 programs. For those using other development tools this isn't as important, but there is still a bit of VB6 programming going on out here.
The crux of the utility involves creating an effective application manifest that's compliant with the SxS isolation features introduced in Windows XP. While this is still very much a work in progress, I'm close to something that might be worthy of a semi-open beta distribution. It may end up as freeware or low-cost shareware, but I'm not fooling myself that it's any sort of goldmine.
Essentially the utility scans the VBP file of a compiled VB6 project for dependencies, then looks for DEP files to follow for those dependencies, etc. It uses this and other information to create an application manifest and copies the EXE and its dependencies, etc. into an XCopy deployment folder. Manual entries can be made to package late-bound libraries or standard DLLs as well. It will embed the manifest in the EXE for you, or write a manifest file at your option.
Within certain limits the current version of this utility does a great job. It's much smarter about VB6 manifests than VS 2005's primitive "isolation" strategy intended for interop. This tool is not meant as an interop solution though, it's for VB6 applications. It isn't One Touch, but perhaps a step toward it.
The main applications I see for it are probably things like "no installation" deployments, deploying to removable media (portable flash drive applications), and building "green" installer packages (those that don't deploy anything to System32 or write to the Registry). The bonus for admin folks is a reduced risk of DLL Hell that breaks other mission-critical applications.
My question is, does this look useful to anyone and is this the sort of forum even to discuss it? I'm not advertising, I'm really wondering who might be interested in trying something like this out and what experiences they've had with Reg-Free COM themselves.
The crux of the utility involves creating an effective application manifest that's compliant with the SxS isolation features introduced in Windows XP. While this is still very much a work in progress, I'm close to something that might be worthy of a semi-open beta distribution. It may end up as freeware or low-cost shareware, but I'm not fooling myself that it's any sort of goldmine.
Essentially the utility scans the VBP file of a compiled VB6 project for dependencies, then looks for DEP files to follow for those dependencies, etc. It uses this and other information to create an application manifest and copies the EXE and its dependencies, etc. into an XCopy deployment folder. Manual entries can be made to package late-bound libraries or standard DLLs as well. It will embed the manifest in the EXE for you, or write a manifest file at your option.
Within certain limits the current version of this utility does a great job. It's much smarter about VB6 manifests than VS 2005's primitive "isolation" strategy intended for interop. This tool is not meant as an interop solution though, it's for VB6 applications. It isn't One Touch, but perhaps a step toward it.
The main applications I see for it are probably things like "no installation" deployments, deploying to removable media (portable flash drive applications), and building "green" installer packages (those that don't deploy anything to System32 or write to the Registry). The bonus for admin folks is a reduced risk of DLL Hell that breaks other mission-critical applications.
My question is, does this look useful to anyone and is this the sort of forum even to discuss it? I'm not advertising, I'm really wondering who might be interested in trying something like this out and what experiences they've had with Reg-Free COM themselves.
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
jib
17 years ago
Hi there,
I don't really think this is the right forum to discuss details of vb6 application manifests or interop - I say so not because it is not interesting, but rather it's not what we (the application re/packaging specialists) would like to deal with on a daily basis. Most of the resources here are geared towards solving deployment the easiest way possible, and so these finer points you present here are of little interest. Also I think XCOPY is dead ;-) and you need to move on, hehe.
A more useful idea could be to take what you have and make some sort of wix automation tool out of it. Might be worth looking at!
I don't really think this is the right forum to discuss details of vb6 application manifests or interop - I say so not because it is not interesting, but rather it's not what we (the application re/packaging specialists) would like to deal with on a daily basis. Most of the resources here are geared towards solving deployment the easiest way possible, and so these finer points you present here are of little interest. Also I think XCOPY is dead ;-) and you need to move on, hehe.
A more useful idea could be to take what you have and make some sort of wix automation tool out of it. Might be worth looking at!
Posted by:
dilettante
17 years ago
I appreciate the constructive feedback. You might be correct that this is the wrong place to discuss such issues.
The utility I'm developing is specifically not an interop tool and doesn't deal with .Net interop issues, it's a packaging tool. Interop only comes into the picture because until now anyone trying to create this kind of deployment package has been directed to look into Visual Studio's interop facilities for assistance.
It also eliminates the details of preparing application manifests by completely automating the process. Once you begin deploying to Vista this becomes an important issue, especially if you're trying to cope with UAC and the AppCompat shims Vista applies that can lead to Registry and filesystem virtualization headaches. It becomes even more important in Windows Server 2008.
Users of tools like WiX could view it as a pre-packaging step, while developers might tend to view it as a post-build process. It doesn't replace installer packaging in most scenarios. Its role is to make VB6 applications easier to deploy to recent Windows versions from XP to Server 2008. It also assists in avoiding both being trampled by other faulty software installations and becoming a DLL Hell culprit yourself.
But if it doesn't fit in with the ongoing conversation about package development here I'm happy to let the matter drop.
The utility I'm developing is specifically not an interop tool and doesn't deal with .Net interop issues, it's a packaging tool. Interop only comes into the picture because until now anyone trying to create this kind of deployment package has been directed to look into Visual Studio's interop facilities for assistance.
It also eliminates the details of preparing application manifests by completely automating the process. Once you begin deploying to Vista this becomes an important issue, especially if you're trying to cope with UAC and the AppCompat shims Vista applies that can lead to Registry and filesystem virtualization headaches. It becomes even more important in Windows Server 2008.
Users of tools like WiX could view it as a pre-packaging step, while developers might tend to view it as a post-build process. It doesn't replace installer packaging in most scenarios. Its role is to make VB6 applications easier to deploy to recent Windows versions from XP to Server 2008. It also assists in avoiding both being trampled by other faulty software installations and becoming a DLL Hell culprit yourself.
But if it doesn't fit in with the ongoing conversation about package development here I'm happy to let the matter drop.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.