This question may seem really dumb, my apologies for having very minimal programming experience. We just need to make an inventory system exe given to us run and "work" on some computers.
The exe file itself is an inventory system made using Visual Basic 6. It runs fine on computers that have visual basic 6 installed.
However, on computers without VB6, we encounter crashes. The exe's themselves run fine but as soon as we perform something (logging in/clicking buttons/etc.), we get runtime errors 339. On one machine it says, "Component 'MSCOMCT2.OCX' or one of its dependencies not correctly registered: a file is missing or invalid. on another machine, we have a similar error but points to MSFLXGRD.OCX
I figured these problems may be caused by missing system files/dependencies and we need to first install those. How do I make an installer wizard (similar to those Windows app installers that installs system files alongside the actual app) for installing these missing dependencies?
You could do a lot worse than the free Inno Setup. I've used it for many VB6 projects and it's never failed me. There's a learning curve but it's a very flexible package.
I used to use (and contributed to) the WiX toolkit for this purpose.
This will build a standard .msi installer for you. Start with the heat program which will inspect your software and generate much of the WiX project for you, be sure to use the -svb6 option.
You will need to source the appropriate merge modules for VB6 as well, which will provide the components you are missing.
Related
The app I work on is written mainly in VB6.
Some users report that when they start up my app a different MSI installer will automatically run and try to repair its own installation. Often this is for AutoCAD but sometimes other programs also.
Usually this occurs every time they start the app.
What is a procedure that we can use to diagnose why this occurs? Since it is a third-party's installer which is running we don't have any visibility into what it is doing.
AutoDesk does have some info published on this:
Unexpected installer launches
Windows Installer displayed unexpectedly
but these do not directly provide enough information. Ideally I want to be able to completely prevent this from occurring to my end users, rather than just telling them how to avoid it or clean it up.
Your installer is acting on a directory, file or registry key that Windows Installer knows is part of the AutoCad installation.
First, I would turn on global Windows Installer logging. This means that any Windows Installer activity - including AutoCad's installer - is written to an external log file (in %temp%).
How to Enable Windows Installer Logging
Next, run your installer, and let the AutoCad installer run.
Now go to %temp% and you should find files MSIXXXX.LOG - one for your installer, one for AutoCad. Open these and you can work your way through them and identify which file or registry key the AutoCad MSI find is missing or changed.
You may find WiLogUtl.exe helpful for this:
Wilogutl.exe
With any luck you will identify that the directory, file or registry key triggering autorepair is also in your installer. If you're really in luck you can identify it as an item you should not be installing anyway - perhaps you are referencing a system component that would be present anyway, something protected by Windows File Protection.
If not, you will have to look at something like RegFree COM to move files out of shared directories into your private directory and reduce registry conflicts. Also, if you are using (consuming) the Visual C++ Runtime MSMs to make your MSI, consider using the Microsoft EXE installer instead or (best of all) placing the DLLs directly in your program folder, since I've found that the MSMs can cause just this sort of problem.
With regards to Peter Cooper Jr's comment on VB6 causing self-repair. Please check out the heat.exe documentation for Wix. You will see that there is a special switch the tool supports to suppress extracting certain registry values that are owned by the VB6 runtime itself (and hence shouldn't be messed with or updated by any other MSI): http://wixtoolset.org/documentation/manual/v3/overview/heat.html
Go down the list to the switch -svb6 and read the description to the right. (Reproduced here:)
When registering a COM component created in VB6 it adds registry
entries that are part of the VB6 runtime component:
CLSID{D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}
Typelib{EA544A21-C82D-11D1-A3E4-00A0C90AEA82}
Typelib{000204EF-0000-0000-C000-000000000046}
[as well as] Any Interfaces that reference these two type libraries
Does your installer write to these keys? If so try to exclude them - this is good to do even if it isn't the culprit in this particular case.
Other than that there is a lengthy description of what can cause Windows Installer self-repair here: How can I determine what causes repeated Windows Installer self-repair?. It is a long article because there are so many different ways self-repair can occur. The common denominator is that different installers on your system are fighting over a shared setting that they keep updating with their own values on each application launch in an endless loop.
I have a freeware software, which i want to install on a network share. The reason is, if the software is installed on a network share, all users which has access to this network share folder should be able to use the program.
Now, I run the setup.exe on my machine and choose on the step "destination installation" my network share \sharename\TestFolder.
The software was installaing on this sharefolder and after the installation it was possible to run the program on my computer without any errors and use it..
After that I try to start the program on other client but there is always an error message, that it starts with a false operator.
Now my question is, is there a software, which can observe on which files the program want to access when I make double click on the (program.EXE).
Thank you, I hope you can help me.
Yes, there are several tools that can monitor or observe system changes performed by a setup.exe.
Many of these tools are quite old and may not operate correctly in new versions of Windows. The most recent one I found that looks acceptable was EMCO MSI Package Builder. I never tested the monitor feature, but it is at least an updated capture product.
In my experience these monitor tools capture way too much low-level system stuff, and you will need to spend quite a bit of time to sort out what is really needed for the software to operate. If you have experience with software development you may get just as much information from using a System Internals tool such as RegMon, FileMon or ProcMon. See Microsoft site: http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx . These tools are exceptionally useful and known for their small size and great feature set. You can run a ProcMon on the launch of the application executable.
It is also possible that the setup.exe is a wrapper for an MSI file. These files can be viewed with free tools such as Orca and EMCO MSI Package Builder and you can basically see what registration settings are needed for the application to operate. Try opening a command prompt and write setup.exe /a and see if it offers to create an "administrative installation point" - or similar.
If I were to guess I'd say that the software needs to have COM servers registered locally, registry keys added to each local computer and possibly you need to install a couple of runtimes on each system - for example Microsoft C runtime of a particular version. This is just a wild guess. What is the name of the software? If it is a .NET application you may need assemblies installed to the Global Assembly Cache GAC.
I got a weird problem with my VB app that has got me very confused. I am updating an existing program. I had to add some processing queue capabilities. On my system, unit testing worked great but when I compile it and run it on a different computer (a network server machine) it first tries to open an office install. If I cancel this, the program seems to run fine. The problem is that this program will be run in the background and I can't be hitting cancel each time it runs.
So my question is this: what is going on here? I'm usually a java developer we eclipse so I'm used to being able to include all the needed libs into the jar files automatically. It doesn't seem like the case with VB6. it seems like it expects all the same libs to be on all the systems. Is there any way to tell what might be triggering this?
The only thing I can think of that is causing it is that I'm using the "OpenProcess" function in the kernal32 lib. that the only major change I have made.
any help would be very appricated. thanks!
EDIT:
It seems that multiple versions of word were installed on the system and it was screwing things up somehow. We uninstalled one and it fixed it.
I ran into this a while ago and it was related to my installer for the VB6 app overwriting some system files for Office that it shouldn't have. Any time one of the System dlls was accessed Windows would determine that something was wrong and the Office installer would start up.
The short-term fix was to let the Office Installer repair the broken chain of dlls.
The long-term fix was to never overwrite built-in Windows System dlls.
You could also check out the Microsoft Fix it Center.
Using VB6
i created a software in vb6 with xp operating system, In my system, software is working perfectly. When i run my software in other system(xp operating system), it showing error as cannot find project or library, showing error in Date, Left...,
Now i moved to vista operating system, i try to run my software, It showing the same error.
How to solve this issue.
My software is running in my system, when i try to run my software other system it showing error and also i try to run my software in vista also it showing a same error.
What happen in my code. There is any system32 file problem?
How to solve this issue.
Sounds like you need to create an installation for your VB6 project, to install the VB6 runtime and any non-standard components used. The runtime should be present by default on Vista, so it's probably non-standard components that are missing.
Consult the answers to your own previous question in August, when you asked how to make an installation for a VB6 program. (Even that August question was already a duplicate.)
You need to also copy the controls, and referenced files to the machine running your code. Some controls and referenced files will already be on the machine, but without experience you generally will not know which files are already installed. You can look at the checked files in the Project|References and Projects|Components dialogs to see what is included in your project. You will need to scroll through the components dialog to find all referenced files, but in the references dialog all the references are organized at the top. Also, to confirm what file(s) a machine is missing you can look at the Events log. An error with the missing file will be logged. A drawback of this approach is that you will only get one missing file at a time as the Application quits on the first missing reference encountered.
Also MarkJ and Konamiman are both correct in that the VB6 runtimes are required, although it is common for other VB6 programs to have already installed it. If you are not building in-house applications you do not want to take anything granted and should build a complete install for your application.
The other computers must have the VB6 runtime in order to run applications generated with VB6. Maybe is this the problem?
The VB6 runtime can be donwloaded from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=bf9a24f9-b5c5-48f4-8edd-cdf2d29a79d5&displaylang=en
Use the Package and Deployment Wizard to create a setup.exe. The Wizard will automatically include all the files you might need for distribution.
I have an old legacy application around for which I only have the installer. it doesn't do anything more than uncompress and register itself and his library's.
As i don't have the source-code it gives me a lot of headaches in maintenance problems. In some particular computers (Acer Aspire One with Windows) just do not run.
I would like to extract the files and re-create this installer with NSIS. Is this possible or I'm nuts?
The original installer has been created with Ghost Installer Studio.
One option is to find a machine that it does run on, and then install some "install guard" software (often called things like Acme Uninstaller). Use this to track what actually gets installed and then copy the relevant files and write your own.
It looks like a lot of hassle to me, and you may be on thin ice with regards to the licence.
You could try using a program that monitors new files being installed and then get the files that were installed from their respective paths.
For instance, I found this in about 10 seconds with Google, there are more programs like it, but I am inexperienced with those available for Windows.
If it uses a MSI file, you can use Orca or SuperOrca to get at the stuff packed inside.
This is typically the job of Repackaging Software. There are a few ways such tools work but typically it is by taking a look at a system before and after you install it on a clean system and building a custom installer from the detected changes. This is normally done to generate a customized installation and/or one that can be automated in its deployment. I'm not aware of one that generates an NSIS package, the standard format today is MSI (Windows Installer).
If you have the original installer any repackager will do, but even without the original setup program you can do as some of the others here suggest and monitor the use of the application for its requirements. The two most popular repackaging tools are InstallShield AdminStudio and Wise Package Studio. The feature may also be part of a setup authoring solution, so check with your in-house developers if you can.
A full list of repackaging tools can be found here at AppDeploy.com
One free repackaging tool available for creating Windows Installer setups from another [legacy] setup tool (with which I must divulge I'm involved) is the AppDeploy Repackager. Another free repackager is WinINSTALL LE.