Running vb system without install VB software in PC

[girl81]

Hi all,

Please let me know..can i run my vb system (.exe) without install VB software in the computer.If can please tell me the solution..

Thanks in advance

[Doogle]

Generally you can't, unless the .exe only uses the vb runtime libraries (which have been distributed with the Operating System since W2K, I believe).
You should use a packager (eg the Package & Deployment Wizard) to create a set-up package which you would run on the target machine. The set-up would install and register the necessary files (eg .dlls , ocx). Of course you could manually copy and register the dependent files, but why would you want to do that ?

[HanneSThEGreaT]

Do you want to run it from a CD ¿
It may be ( depending on what you want to do ) possible by using a .local file - do a search here for .local file, you'll get numerous results

[girl81]

Thanks all,

I just wondering..i have developed a simple vb system and want to run it at many PC..that is why i want to know if there is a way we no need to install the VB Software in that PC.

Tq

[dilettante]

Where it fits the situation reg-free COM goes far beyond .local files. I think people forget that using .local still requires component library registration, and if necessary your VB program ends up calling DLLSelfReg on the .localized libraries. Misunderstanding of .local results in a trashed registry, because the self-reg'ed libraries next to the EXE become the system copy. If you ever remove them other programs will fail.

See Implementing Side-by-Side Component Sharing in Applications (Expanded)

Note: In Visual Basic there is currently no easy way for developers to write inherently side-by-side ActiveX controls. This is because the registration of Visual Basic-authored ActiveX controls writes the fully qualified path to the OCX file into the registry when the control is registered.

This applies to most of the regular VB-supplied OCXs and DLLs too.

For example I "dot localed" a small program in a desktop folder using the DatePicker in MSCOMCT2.OCX and ran it. Checking the registry I now find:

[HKEY_CLASSES_ROOT\CLSID\{20DD1B9E-87C4-11D1-8BE3-0000F8754DA1}\InprocServer32]
@="C:\\Documents and Settings\\*username*\\Desktop\\DatePickLocal\\MSCOMCT2.OCX"
"ThreadingModel"="Apartment"

If I ever remove the DatePickLocal folder I have now broken every other program on the system that uses MSCOMCT2.OCX!

You don't even need the .local file in such a case. I didn't use one.

Its purpose is to allow you to run a version that is different from the registered version. This misunderstanding of the dot-local scheme is not a way to willy-nilly deploy VB programs without an installer. It can be dangerous.


If you're running on XP (preferably SP2 or later, or Vista or Win2008) reg-free lets you just copy the files to deploy them. One tool for prepping your programs VB6 for XCopy deployment is MMM. This way nothing ever gets registered (or requires pre-registration). It will never mess up the registry, thus never leading to DLL Hell.

Also look at DLL/COM Redirection on Windows which says:

Windows XP SP2, Windows Server 2003, Windows Vista, and Windows Server 2008: The use of DLL/COM redirection strategies is not recommended because isolated applications that use manifests and side-by-side assemblies can be easier to update and service. The presence of a .local file is ignored if a manifest is present. The DLL/COM Redirection strategy using .local files works if the application does not have a manifest.

[dilettante]

This really should be in the Deployment section of the forum.

[Hack]

This really should be in the Deployment section of the forum.

Agreed.

Moved

You don't have to install VB itself, but you do need to put together and installation and setup package which would include the necessary runtimes and dependency files required by your exe. That is simlpy the nature of windows programming.

[dilettante]

You don't have to install VB itself, but you do need to put together and installation and setup package which would include the necessary runtimes and dependency files required by your exe. That is simlpy the nature of windows programming.

And this is still as true as ever, with one exception.

Simplify App Deployment with ClickOnce and Registration-Free COM

It is interesting that history is being rewritten at Microsoft though. This article now says:

The ability to isolate a COM component was primarily designed to enable Reg-Free COM deployment of Visual Basic 6.0 COM components within Visual Basic .NET or C# applications.

The original version stated (more accurately) that "The ability to isolate a COM component was primarily designed to enable Reg-Free COM deployment of Visual Basic 6.0 applications." This was one the of advantages XP offered VB6 developers. Sadly they didn't get it right until XP SP2 though - prior to that a few things are still broken in it.

The good news is that it works great in XP SP2+, Win2003 R2+, Vista, and Win2008.

The article ends with:

Conclusion

Reg-Free COM is a great way to overcome the headaches that typically go along with deploying applications that use COM components. It works for ActiveX controls, but it can also work with nonvisual business objects. It brings native and COM components to level of parity with managed components in terms of both application isolation and ease of deployment. The only significant drawback is the higher minimum-platform requirement of Windows XP. But as more and more desktops are migrated to newer platforms, the benefits offered by these new capabilities become increasingly more compelling.