I am maintaining an application written in VB6 and we currently use package and deployment wizard to create installations for our project. When most users try to install this software they get the error message:
C:\WINDOWS\system32\vbajet32.dll
The destination file in in-use. Please ensure that all other applications are closed.
Can anyone tell me if there is a specific way that I can avoid this happening by changing something in the installation files/setup or writing some kind of script? I have no experience writing packaging/deployment scripts which is part of why we use P&D wizard.
Your installer is probably trying to replace a dll (vbsjet32.dll) that is being used by another app.
Maybe they are using Access (or another app) while trying to install and it's already using the dll.
You may be able to get around it by making sure users have closed all open programs before installing, or you may have to write custom code to handle it.
Related
I have a WPF app that I am planning on deploying with the Windows Application Packaging Project in Visual Studio that makes the MSIX bundle for installations and future updates. The installer automatically installs the app in C:\Program Files\WindowsApps. This is fine until the program needs to cache some data or it needs to modify the appsettings file since the app does not have permission to get to these resources.
Is there a setting I can change in the packaging properties/manifest so it can install somewhere else so I can avoid these problems?
Indeed, only the Windows can write in %ProgramFiles%\WindowsApps when installing the msix package (by design). If your app is writing log files or other data inside the installation folder it will crash.
You need to either update your code to write to %AppData% or, if you don’t have access to the code, use the Package Support Framework to fix it. You can read more about here:
Package Support Framework (aka PSF)
The PSF brings support for API redirection and hooking. Thus, you can fix an app that failed to write a file in the installation folder (this is no longer allowed) and redirects it to a recommended location, or maybe simply update the app’s working directory.
As mentioned above, you cannot write in the install location of an MSIX package - this is by design.
For apps that are no longer under active developer indeed using the Packafe Support Framework is the only way to fix them. However, from what I see you are preparing to launch the app, so you have access to its code.
In this scenario, it is recommended you save all your app settings in the AppData\Roaming folder. For apps deployed as MSIX Windows will automatically redirect it under the Packages folder, but that is handled automatically by the OS, so you don't need to worry about it. More details below.
How to save data under AppData\Roaming instead of AppData\Local\Packages
I was trying to create an msi setup for a windows form application. This msi should only installed if the local system has Access database engine 12.0 installed on it.
So I tried to put a lunch condition in the visual studio installer. Now if I want to make this driver as a prerequisite for the new application to get installed I need COMPONENETID of this driver So that I can put a condition in launch condition.
I have and exe for Access database engine 12.0 but can't figure out the componentid of it. I tried to use ORCA tool for this prupose but ORCA tool only work with .msi not with .exe. Can someone please help me out with this ? Thanks in advance.
If you have a tool like WinZip (there'a a free eval version at time of writing this) you can open that exe and WinZip will extract the files out for you without installing it. There will be an MSI file (called AceRedist.msi last time I looked) and then you can use Orca in the way you described.
Is there any reason that you are taking this approach to detect the presence of a pre-requisite? In your case, the pre-requisite here seems to be Access database engine 12.0.
IMHO, there are definitely standard ways to detect the presence of Access database engine 12.0. A simple google took me to the following link:
https://community.flexerasoftware.com/showthread.php?201524-Determine-Microsoft-Database-Access-Engine-Version
Relying upon a specific component GUID from a 3rd party vendor is definitely risky and might lead to unnecessary maintenance.
Regards,
Kiran Hegde
Our application is deployed to the target machine with an msi file. All works nicely. Our tester has gone through his plan, and one of the tests requires deleting the application's configuration file. The application is designed to alert the user with a dialog on startup saying "missing config". However, what happens is that - somehow! - the software starts the installer again and retrieves the missing file from the msi! Which is nice, but not what we want. How do we disable that behaviour?
without going into much depth of the windows installer mechanics (if you interested in that there a plenty of articles about this), the shortcut of the software is probably advertised, which means the windows installer checks if everything is in its place before the software is started.
if you can edit the msi, make the shortcut non advertised.
if you can't, install it with DISABLEADVTSHORTCUTS
e.g. msiexec /i myMsi.msi DISABLEADVTSHORTCUTS=1
please note that this is only a quick (and dirty) workaround,
to fix this proper you need to understand the whole windows installer advertising (also called repair or self resiliency) mechanism.
but explaining all the causes and the mechanism of the repair is far beyond this answer and there are quite some articles and posts about that on the internet (and especially on MSDN and stackoverflow)
There is a more correct answer to this, and it is NOT DISABLEADVTSHORTCUTS. You set the component id to null in the MSI file to prevent repair of that individual file. See ComponentId comments here:
http://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
Edit the MSI file with Orca to delete the Componenty ID, and write an uninstall custom action to delete the file at uninstall if it's there.
In addition, that's a redundant test. Windows will restore that file for you if it's missing, so the idea that you need a test to notify that it's missing is pointless. The true test should be that Windows will restore the file if it's lost, and your app needs to do potentially nothing about the missing file.
You don't mention what tool you are using to make your MSI but I'm going to go out on a limb and guess Visual Studio Deployment Projects (.VDRPOJ).
One of the (many) horrible things about this tool was that it fails to expose the foundational concept of components. Instead it makes every file a key file of it's own component and hides the existence of the component from you. I say 'was' because Microsoft killed this project type in VS. There are around 50k people complaining on UserVoice to bring this tool back and I'm guessing that 49,990 of them don't know what a key path is.
Windows Installer has a concept called the component rules and each component has a keypath. The keypath teaches MSI how to handle repair scenarios. But your tool has to allow you to be able to control this to make it work.
Windows Installer is functioning exactly the way it's supposed to function. You just aren't up to speed on what that is.
However, if you want to ignore Windows Installer best practices and continue using the tool you use today, the trick is to install the app.config file as a different file. Then have the application copy the file to the real file name on run. Windows Installer won't service what it didn't install.
Several answers have been provided that can work:
You can install the file with a blank guid. Then you need to remove it on uninstall using the RemoveFile feature. You will also run into issues if you want to replace it during an upgrade. Could be tricky at times.
You can disable the advertised shortcut(s), but this affects too much in my opinion.
Finally you can use my suggestion to install a separate non-advertised shortcut to use to launch the application. Such a shortcut bypasses the self-repair check. It may still be invoked by other means such as missing file associations, COM registration or similar, but those are exception states.
However, my preference is that an application can start without a config file present, if at all possible. I always suggest a good startup routine with "internal defaults" available. The startup routine should also degrade gracefully if faced with any file system access denied conditions.
Most importantly you should place this config file in the userprofile so you can generate the file on first launch for the user in question. It can even be copied from a read-only copy in the main installation directory.
When you generate a file from internal defaults and put it in a userprofile location, the file will have no interference with Windows Installer at all. The issues that results is how to clean up user data on uninstall. I discussed this with Stefan Kruger (MSI MVP) at one point, and I agree with his notion that user data is indeed user data and should not be automatically dealt with by your installer at all. Leave it installed, and clean it up via system administrator tools if necessary - for example logon scripts.
i have created a application in VB6.0 which is connected to MySQL through ODBC connection,there are two dsn which connects to application.Now i want to create a setup of the application that i can install on any computer.but how? I tried using Package and Development wizard in VB but it gives me error "access denied ieframe.dll" something like that while installing it AND also after using that wizard,now all my forms are corrupt.I craeted new and i don't want this to happen again.Help me!!
tired googling now!!!
I am not sure of the version of VB6 you are running, I do know that there was an InstallSheild Light version that shipped with Visual Studio 6 Professional. It was an optional install. If you have your original installation media try looking for it. There was also Visual Studio Installer 1.1 that used to be available from Microsoft. I found a link on Web.Archive.org that still works. I have used this to build msi files for VB6 in the past. You need to have Visual Interdev because it gets added as project type to it.
And since you mentioned that the Package and Deployment Wizard corrupted your project, you should make a backup of your data or use some type of source control. It will be a lot less painfull to recover when problems occur.
First of all, I take it that the two DSNs are not relevant to this problem?
I have never seen the error "access denied ieframe.dll", but I would guess that you are trying an installation via internet explorer. I would try creating a standard application installation.
I have to say that I am surprised to hear of "corruption" of your forms. Do you really mean your source code? Or this the forms in the executable. In any case, you really should be using some form of source control.
In any case, if you want a better answer, try giving a step by step run-throught of exactly what you are doing.
Regards,
Mark
Is it possible to install the entire database(postgresql8.2) via command prompt or batch file or registry file bypassing the trivial procedure for installation. But then to a question comes that, how can we supply default parameters such as name,password,language,default location of database? Currently I'm working on 'Windows XP' platform.
Thank you.
For 8.3 and lower the obvious answer is: http://pginstaller.projects.pgfoundry.org/ which supports or supported silent installations. For more recent versions, please read: http://forums.enterprisedb.com/posts/list/2135.page
Use of existing installers would simplify your life and be where I would start.
This being said there is no reason you can't generate a script to register dll's properly run initdb, etc. This will take some extra knowledge of both PostgreSQL and Windows, and will be mostly suitable for custom solutions (i.e. not cases where you merely are packaging software that runs with PostgreSQL). I don't think an complete answer can be given here because once you need such a solution you need to design your installation around if. Books could be written on that topic. The docs http://www.postgresql.org/docs/9.0/static/install-windows.html should get you started however since the only difference really between installing from source and installing from the precompiled source is just that you need to compile the source files first.
Failing that you could take a look at the binary zip packages. Typically these can be extracted and PostgreSQL can be run from inside them.