Compile with all dependencies

[ihsaan]

WHen I compile my app and run it on another computer im always getting the missing DLL error. Cant I compile the app and include all the DLL's?

[Arnoutdv]

No you can not bind the external dlls into a single exe using the VB6 compiler.

[techgnome]

Not natvely with VB... there are tools that allow dll packing... results vary... some virus scanners will see such packed exes as a threat and may shut it down. I've also heard of others with success stories with packing. Personally I just go with the tried & true installation program to install the app.

-tg

[Niya]

Cant I compile the app and include all the DLL's?

Compiling a DLL into an EXE defeats the purpose of a DLL in the first place. DLL means dynamic link library. Its meant to be dynamically linked. What you're describing is called static linking. That was the standard way of integrating libraries in the DOS era. However, I think the VC++ compiler can still do static linking.

[DataMiser]

WHen I compile my app and run it on another computer im always getting the missing DLL error. Cant I compile the app and include all the DLL's?

What you should be doing is creating an installer package and then installing it on the target system. This way all the dlls, ocxs and other required files are properly installed and registered, shortcuts created, folders created and so on.

[ihsaan]

Thanks guys.. Any particular Installer package you can recommend?

[dilettante]

Just start with the Package and Deployment Wizard that comes with every copy of VB6 that can create programs legal to redistribute.

Ideally after some experience you'd move on to Visual Studio 6.0 Installer 1.1, which was released as a free update to the VB/VS 6.0 products. However the downloads are no longer hosted by Microsoft. There are also high quality 3rd party packaging tools on the market.

Personally I'd avoid the InnoSetup product several people here are likely to recommend to you. It relies on hand-crafted scripting that is very easy to get wrong, and in my experience is the leading cause of DLL Hell today because of poorly written scripts loose in the wild and blindly copy/pasted by so many novices.

It gets really old taking support calls from customers to "fix" my applications when some defective InnoSetup package was the culprit. This is so common now I'd prefer that anti-virus tools start treating InnoSetup as malware.

[Niya]

Thanks guys.. Any particular Installer package you can recommend?

You can try the Visual Studio Installer project templates that come with VS2008 and up. Although they are made to create installers for VB.Net/C# projects, they are flexible enough to create decent enough installers for VB6 applications. They can register COM libraries, alter the registry, create shortcuts. Only caveat is that you're going to have to specify all the dependencies for yourself since it wasn't made with VB6 apps in mind. Also, I think you have to have Pro editions of VS2008 and up to get the installer project template.

[Nightwalker83]

Well, if you have the source code of the dlls try adding the classes to the exe and the compiling the executable.

[dilettante]

When packaging an application it is also important to know which DLLs are deployable and which ones aren't. A lot has changed since the Win9x days when VB6 first came out, and many things you used to have to deploy are now part of the OS and either can't be or shouldn't be deployed. People get tripped up over the VCRT DLLs quite often for example.

Reg-free COM packaging is another alternative to conventional installation. But it is an advanced topic since Microsoft never provided simple VB6 tooling for it even though VB6 was the original intended target. Works great in most cases where you need to create "portable" apps or ones that can be installed per-user when no admin rights are available since nothing needs to be registered. This is also useful for getting around DLL Hell even when you create a conventional installer, since you provide private copies of the libraries you need.

Reg-free COM can make a VB6 application easy to package using the IExpress wizard that ships as part of Windows. You just write a sort of stripped down version of Setup1.exe that copies files from the unpacked temporary location to a folder under %LOCALAPPDATA%\Programs, creates Start Menu shortcuts, etc.

But in many cases the PDW does a good enough job.

[dilettante]

You can try the Visual Studio Installer project templates that come with VS2008 and up.

You might do some checking.

Microsoft Removes Installer Project Templates from Visual Studio 2012

But I don't keep up with VS, so I can't say what the real situation might be today.

[dilettante]

Ahh, see:

Microsoft Re-Installs Visual Studio Installer

Microsoft has brought back a much-missed bit of functionality from Visual Studio 2010 and put it back in Visual Studio 2013: Visual Studio Installer projects.

Visual Studio 2013 Requirements

OS: Windows 8.1 (x86 and x64), Windows 8 (x86 and x64), Windows 7 (x86 and x64), Windows Server 2008 R2 SP1 (x64), Windows Server 2012 (x64)

[Schmidt]

Well, if you have the source code of the dlls try adding the classes to the exe and the compiling the executable.

Well, that would be entirely against the principles of "pre-compiled modularization".
I never understood the obsession of the VB-Community, to have "everything in one Exe" -
especially not since the advent of regfree loading-approaches for COM-libs.

Isolated development of Components which are tested and compiled outside the
Main-Project (outsourcing larger/shared parts of the codebase from the concrete Application,
not cluttering it with the additional code - and thus ensuring fast startup- and compile-times
of the main-project) is part of normal engineering and the recommended way to do things.

COM-libs (ActiveX-Dlls especially) are really nice "interface-selfdescribing binary-containers",
which in VB(A) only require a single "Check-in-Click" to become immediately usable with intellisense.

The deployment-part can be done in a \Bin\ SubFolder of the Application itself.
In case of Dlls the loading of (instancing classes from) such ActiveX-Dlls can be done
regfree with only a few lines of additional code in your VB-Project.

Olaf

[techgnome]

I never understood the obsession of the VB-Community, to have "everything in one Exe" -
especially not since the advent of regfree loading-approaches for COM-libs.

I've seen it extend from two lines of thinking:

1) Other languages allow it
2) lack of understanding that deploying also needs to include the dependencies

Both have their merits, but that's not the foundation that VB was built on.

-tg

[Nightwalker83]

Well, that would be entirely against the principles of "pre-compiled modularization".
I never understood the obsession of the VB-Community, to have "everything in one Exe" -
especially not since the advent of regfree loading-approaches for COM-libs.

Well, that would depend on what you needed to do with the code! As you know dll files can be used in other applications. Going from memory, compiling an execute project that contains a class does not allow access to the class from outside sources (at least not through normal means).

[dilettante]

At this late date people probably shouldn't be trying to learn VB6 from scratch anyway.

Microsoft has only gone out of its way just enough to allow old programs to still run, with a little care. With each new Windows version things have gotten a little bit tougher, so if you don't already have a deep investment in VB6 experience I wonder why you aren't looking elsewhere.

With Windows itself stumbling so much post-Win7 it might even be wise to consider investing your effort into cross-platform languages. There are some easy gateways from the VB world to Java such as B4J.

[Schmidt]

Well, that would depend on what you needed to do with the code! As you know dll files can be used in other applications. Going from memory, compiling an execute project that contains a class does not allow access to the class from outside sources (at least not through normal means).

Well, in case you want to develop a "protected" COM-library - the approach would be,
to include a cFactory - or cConstructor-Class which would be the only Class in your Dll,
which is included with its Instancing-Property at '5 - MultiUse'...

All other Classes could be included with Instancing at '3 - PublicNotCreatable'.

Then only the cConstructor or cFactory Class being able, to hand out Instances of
those Classes into Applications (then, with e.g. cConstructor.AuthenticateAndEnable
you could include a Method there, which would require the right credentials, to
switch the cConstructor-Class into a Mode, which allows the other Constructor-
methods to hand out new instances of the other Classes (the ones with Instancing = 3).

Sounds a bit complicated, but can be accomplished with only a few lines of code -
so (aside from that it's rarely needed) protecting "intellectual Property" in Classes
of ActiveX-Dlls is not a big deal really.

Olaf