Standalone visual basic executables.

[Eamon]

I want to distribute vb executables in work but they wont let me because of the support files that go with the aplication may overwrite other files already on the systems.

I did see a runtime 'remover' on a shareware disc but didnt buy it.

Can I make a single vb executable?
If so, how?

[parksie]

Not unless you pay for Fusion from Bit-Arts. Anyway, the support files will be the same so overwriting them doesn't matter too much...does it?

[Eamon]

Trouble is that other programs may be looking for a different version of the support files than the setup program with VB uses. I have to be sure thatt this wont happen. Our systems department temm me I'm not allowed to install any VB programs unless I can prove this wont be the cas (we use NT in work by the way). Cheers for the reply anyway.

[parksie]

I hate DLL hell
(Never tried this, BTW) - try putting the support files into the app's folder - it'll find them from there.

setup packages will not replace a new DLL with an old one. As DLL's are almost always backwards-compatible overwriting them shouldnt matter.

[mikegt]

Eamon, I can understand your mis department's concerns.

One solution is to make a setup set for your app and place this setup on a shared folder on the server. Go to each workstation that you want to run this app and run the setup from the mapped folder. After install, delete your exe file off the workstation. Drag a shortcut of the exe app from the server to the workstation's desktop. In this manner all the dll's are installed on the workstation not the server. When you make changes to your program, just copy the new exe file back to the server, unless of course you have added new controls.

If you need to actually install the app on the server, you may just copy the compiled exe to the server. Run your app by double clicking the exe and make a note of what dll's or controls that are needed. Copy the missing file to the system32 folder and register it. Run the app again, copy the missing file and resister. Repeat this process untill your app runs correctly. If you get a message that says that a certian file is incorrect version, then that would be one file that your setup would replace. If this is the case, send me an email. This method is a pain and will take a while to complete.

I have had problems installing my vb apps on an NT4 terminal server. The problem were due to file security and not my app. Hope this helps.

[Konan555]

http://www.moonlight-software.com/vbpower.htm

[Eamon]

Many thanks for all the replies. I'm afraid ours systems dept is so finneky that the only real solution is to have an all in one executable. Even then I'm going to have to be very persuasive. Thanks again.

[Konan555]

The software avaliable at the link I posted before DOES inbed it all into one exe

Are they worried about the actual vb runtime files, or third party controls. If it's the actual vb runtimes then exclude them from the distribution, get a list of em and verify with the sysop that these files exist on the servers/clients and that the versions are the same as the ones you are trying to distribute.

Then when you generate the vb distribution, take them out of the distribution list. Trial and error with a simple "Hello World" app should get you to the correct stage.

Have trialed Fusion....and my opinion is it is over priced. You get a download, no cd no manuals for approx $1000(AUD)...for that sort of money l expect a cd, at least one manual, and a demonstration app.

Will try Konan555 link and see what that does.

Your only other options are to move to Delphi, c++, or a similar langauge that generates stand alones.

Downloading the trial version now. At $143 odd oz dollars is certainly better value than Fusion.

ummm fusion is not really worth it if you think about it..

All fusion basicly does is compresses all the runtimes your project requires adds them to the end of your exe (anything added to the end of an exe windows ignores) then it puts a bootstrap program at the beginning of the exe making it the new exe to run because as I said windows ignores all data at end of exe file and since this is the new data at the beginning the original exe file is now at the end. The bootstrap program decompresses the runtime files into that directory or your system directory then it runs the original exe data and removes itself.

Pretty simple concept but since its binary files you cant be off by much ..couple bits at the most. This is a mundane explanation really...To seperate the data in the binary file you really dont need anything but if your planning on seperating them I would recommend adding a type of seperator in the binary code...If you know delphi or if you know c++ or pascal you can code this method extremly easily.

[funkyd77]

Yes any given DLL of a newer version should cause no problems for existing programs that use older versions of the dll. However this quite often is not the case. It seems lots of people (microsoft included i'd say) create dlls that are not backwards compatible. I've had all sorts of hassles with this and testing distributiions of my applications.

One time the solution was to go back and dig up my old vb5 disc and use the dlls off that because they should work but the newer ones wouldn't.

so really the problem is that its very hard to guarantee that any dlls you install (even if they are of higher version numbers - because lower version numbers should not overwrite anything) could still cause hassles - and as far as i know its a fairly hit-and-miss, trial-and-error type of process to see if you have any problems. ie you need to try it and then deal with it. theres not any tools that will forewarn you of problems you'll encounter (is there???)

my 2 cents..

[RCharlton]

add all your ocx's etc to a resource file and then make a program which opens the fnames for binary access in App.Path and writes the resdata to the files and then shells those/

[Lyla]

Hi RCharlton,

Would you please give more information about what U R suggesting?

Thanx.

[RCharlton]

Try adding a resource file to your project and then adding all the ocx/dll's you need (except for the basic VB runtime files - you will need to get them to download those if they don't already have then in a nice microsoft exe, but they are likely to have at least those) to custom with indexes 101-... (you get the fname list from the same list). Then code like this:

Dim installDir As String ' get the user to enter the install dir
        installDir = GetRealDir(installDir) ' make sure there is a trailing slash
        Dim fnames(3) As String
 
        fnames(0) = "comdlg32.ocx"
        fnames(1) = "cmy.ocx"
        fnames(2) = "another.ocx"
        fnames(3) = "yetanother.ocx"
 
        Dim buffer() As Byte
        For i = 0 To UBound(fnames)
        buffer = LoadResData(101 + i, "CUSTOM")
        Open installDir & fnames(i) For Binary As #1
            Put #1, 1, buffer
        Close #1
        Next i
 
Function GetRealDir(dirr As String)
        If Right$(dirr,1) <> "\" Then
                  dirr = dirr & "\"
        End If
        GetRealDir = dirr
End Function

Obviously you will need to check overwrite stuff and things like that.

[Konan555]

Couldn't the dll's just be put in the same directory as the executable?

[RCharlton]

Yes, but you may want to put some other executable (or something else away in a different folder - for users not to find ;-) or for some other reason - eg the startup folder.)