I have created a custom installer dll & everything is working fine. I just want to call another installer's Uninstall method from my current installation. When I do this, I get error code 1618 (signifies another installer is already running). However when I call the uninstall of the same product from a test project, it is working fine.
Could anyone suggest a solution to this?
Can I uninstall another application from the current installer?
AFAIK calling an installer (either to install or uninstall) from another installer is not supported. It was supported in earlier versions of Windows Installer, but is now deprecated, and even then I'm not sure uninstallation of an other product was supported.
The recommended way now is to use a bootstrapper to check for and install any prerequisites. Theoretically you should also be able to uninstall a product using a custom bootsrapper, however writing one is not a trivial exercise.
Also silently uninstalling something from a users machine is not necessarily a nice thin. Using the Visual Studio 2005 Generic Bootstrapper you should be able to generate a bootstrapper that checks if the other product is installed and asks the user to uninstall it.
If this other product is your own (and hence you have access to what the installer should be doing), or you want to do something dirty, you could try removing the files/registry entries/etc yourself then unregistering the program in the registry (HKEY_LOCAL(MACHINE|USER)\Software\Microsoft\Windows\CurrentVersion\Uninstall\{PROGRAM}). Not really the greatest idea ever, but if you have access to what the installer should be doing, then it'll work for you.
Related
I developed a windows service in C#. and my project has Installer, and Setup project.
the setup project, installs service very well and it doesn't have any problem, but when I change project and create other setup, the new setup doesn't install new service, because it's already exist!!!
is any way to create setup that it uninstalls the service then install it?
The problem is that upgrades in VS2008 setups and later use installer classes and an install sequence which is 1) Install newer product over older product, use file version checking, run install custom actions 2) Remove the old product running uninstall custom actions and getting rid of files that are no longer used. VS 2005 wasn't like this. So the installer class custom action that installs the service is running when the service already exists. Sometimes you can revert to the VS 2005 upgrade mechanism that removes ALL the older installed files first, including databases etc, so keep that in mind. You can do that by modifying the MSI file with Orca, InstallExecuteSequence table, and re-sequence the RemoveExistingProducts action to immediately after InstallValidate. Otherwise do both these:
Always install the service binary to a fixed location (that means not the browsable Program Files folder). The uninstall custom action for the service should have a condition of NOT UPGRADINGPRODUCTCODE so that an upgrade doesn't try to uninstall it (but a straight uninstall will). It needs to be in a fixed location because this upgrade solution doesn't install or uninstall the service - it just updates the binary - but obviously you don't want service entries referring to a service that has changed location.
In the upgrade have a condition of NOT PREVIOUSVERSIONSINSTALLED on the install custom action for the service. This means it will not try to re-install the service (which is why you get the "already exists" error) but it will update the exe if you have incremented its file version.
If you search the MSDN setup forum http://social.msdn.microsoft.com/Forums/en-US/home?forum=winformssetup for PREVIOUSVERSIONSINSTALLED many of the posts are to do with this issue and there is more discussion and explanation.
Editorial: Installer classes are not required because Windows Installer can do all this for you, which is why this is only ever an issue with VS setup projects. Moving to a tool that uses MSIs ServiceInstall and ServiceControl tables will get you out of the need for any code to install/uninstall/stop/start services.
You could do it by properly configuring MSI properties. Click on Installer project and press F4 to view MSI's properties window.
When you go to properties you could see two type of properties that are Upgrade code and Product Code. Every Time you create/release a new Windows service installer make sure to keep the same Upgrade code but change the Product Code.
Change DetectNewerInstalledVersions property to true.
Set RemovePreviousVersions to true.
Now Change the version number to a higher version from previous release, if your previous release version was 1.0.2, change the new version to 1.0.3.
When you install a MSI with abovementioned settings, MSI will check if any other product installed with same Upgrade code, if it finds a product then it will check if the new installation has a higher version. If all the conditions are satisfied it will first remove the existing(Older) version and install the newer version.
The application I'm talking about consists of vb6 (80%) and c#, .Net Framework 4.0 (20%).
All new components are created with c#. With Microsoft Interop Forms Toolkit 2.1 we create the COM UserControls that we later embed in vb6. For Forms we use normal classes to create and open in vb6 (COM Visible project).
To create the setup we use wise.
Locally everything works fine - The problems only occur when we install the application on a non-developer machine with the wise created setup.
We added a class to open a c# Form to an existing interop toolkit project. It works fine on the developer machine and also when we make a new installation on a pc(non-dev-machine). The new class is just used to open the form.
But when we update our application to a newer version, that class is not working anymore. We have to uninstall the old version and install the new version to make it work again.
Anyone had a similar problems before?
I'm grateful for any advice
This seems like it is an issue with Windows Installer and the sequencing during the upgrade. Does your application allow side by side installs (e.g. Version 1 and Version 2 can be installed at the same time) or does your installer upgrade earlier versions to the latest version? You might try logging the installation and reviewing the log file to see exactly what is happening during the install / upgrade process.
You can log an msi installation by invoking Msiexec from a command line.
This may provide greater insight and help focus your efforts to debugging the problem.
Edit
From what you've described it seems that on fresh installation the install works as expected. When you upgrade earlier versions it would seem that the COM Interop components are not registered properly. This could be an indication that the sequence of events is a little off with regards to when the components are copied to the machine and registered vs. when the existing product is removed. While not exactly identical, see this SO Question and answer for more details. Also, have a look at the RemoveExistingProducts action in Windows Installer for more information.
I would log an installation that you know works without issue (e.g. on a "clean" machine) and then log an installation that you know will fail (e.g. an upgrade) and then compare the two log files using a tool to see if the output is identical. If not, that gives you a clue as to where to look. If they are identical it might be time to engage with the vendor and see if they can assist with determining what's causing the issue.
I have created a successful deployment project using Windows Fourms that work as intended but there are two things that need to be solved:-
First: I have to click the setup.exe file in order for the installation to check for the perquisites, and if click the setup.msi it proceeds to install the software directly without checking anything.
Second: When i click on the setup file while the software is already installed on my PC, i get an error message "Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel" while i should get a Repair and Remove options.
Can anybody help me solve this problems ?
As said by Morten, that's how it works. You want to make sure that the prerequisites are (get) installed before your product is installed.
This probably is caused by a rebuild of the deployment package after you installed it. Windows installer notices that you use a different MSI (with a different package code), that contains the same product version. This situation, apparently, is inconclusive enough to leave it up to you what to do with it. The logic of this, I think, is to prevent a "Repair" that in fact installs a different product. Inconvenient for testing, but very much desirable in production environments. If you try to install the same MSI you should get the repair/remove options.
BTW, after building a release, you can right-click the setup project in VS and choose "install". This executes a setup that kindly removes a previous installation with the same version.
I have to make a rather complex installer for a C# add-in for Word. I've been researching this for almost two days now and I still haven't found something that can do everything needed.
The main issue here is due to the constraints regarding prerequisites. They mustn't be included in the main installer to keep it small so they'll have to be downloaded.
Additionally, they have to be installed silently without bothering the user. It is ok to show a progress bar or something similar but nothing that requires user input.
After reading about the Windows Installer, Inno, bootstrapper packages and dotNetInstaller I have finally reached the conclusion that the later would be best suited for this scope. However, there's a nasty downside which I have yet to resolve: prerequisites checking.
Is there a standard way to check whether a Microsoft redistributable is installed? The add-in needs the following components:
Windows Installer 3.1
.Net Framework 3.5
PIA
VSTO
Furthermore, I haven't been able to find the direct URLs for these components. I'm wondering how Windows Setups in VS get them.
As a last resort I could host them somewhere to have them at a known location but I'd like to avoid that.
Furthermore, I haven't been able to find the direct URLs for these
components. I'm wondering how Windows Setups in VS get them.
If your using the Visual Studio Setup Project, you can embed them into the setup, and make them required for your application to be installed.
At least for the case of Windows Installer 3.1 and .NET Framework 3.5 SP1
Is there a standard way to check whether a Microsoft redistributable
is installed?
Checking the registry is a quick way.
I would first prompt the user about the downloads first because there would be an uproar if it secretly downloaded files without the users consent. It could also be used for malicious reasons if it were unsecure.
use this tool http://www.advancedinstaller.com/ for creating installer project it has the simple ui interface using which u can handel many comple scenarios in an easy way. U can purchase the tool or can use freeware edition
I have a Windows service written in C# using VS2005.
The installation is via a wizard that calls msiexec to install the msi file also created using VS2005.
I am having trouble generating an msi file that will upgrade from one version of the service to another. The wizard program handles detection of the currently installed version, stopping the service, coming up with an appropriate command-line for msiexec and then re-starting the service.
The existing msi has a version property of 1.1.02, the new one is 1.1.03. The product and upgrade codes are identical.
Uninstalling 1.1.02 manually via add/remove programs works fine, as does installing 1.1.03 onto a "clean" system.
Upgrading 1.1.02 to 1.1.03 goes through the motions but the end result is 1.1.02 installed.
The command line that the wizard uses for upgrading is:
msiexec /qb /i "MyProduct.msi" REINSTALL="ALL" REINSTALLMODE="vos"
Where am I going wrong? I'm assuming I must have missed something fairly fundamental...
The fall-back position is to inform customers that they need to manually uninstall 1.1.02 before running the wizard to install 1.1.03 but I'd rather not have to do that.
Edited to add:
Changing the product code (as VS2005 also prompts you to) actually removes the ability to upgrade at all, as it the installer won't let you do a reinstall if that product code hasn't previously been installed.
All it will then let you do is install (and then you get the usual "service already exists" -type message).
There are several things that need to be done to get "upgrades" to work with MSI's if you want to automatically remove the previous version.
First some background information about the mysterious "codes". There are 3 codes (GUID's) associated with an MSI:
Package Code - This identifies a particular version of the MSI installer and should never be reused across builds. It must always be updated.
Product Code - This identifier is used to ID a particular version of the application. It is up to the installer author to decide when to assign a new product code.
Upgrade Code - This identifies the application and should not change through it's lifetime
The Upgrade Code should never change. For you upgrade scenerio, the Product Code must be changed for each version. Additionally, as you mentioned, you must bump the version number. The Product Code and Upgrade Code can be found by selecting your setup project and going to the Properties Window. The Package Code is hidden in Studio and will always be updated.
The item you are probably missing, is that you also need to set the RemovePreviousVersions setting in the Properties Window to true.
One more thing in addition to mohlsen's answer (For Visual Studio 2008):
In order for your Primary Output (your EXE!) to upgrade properly, you must increment the FILE VERSION
This setting can be found in the Project Properties: Application Tab -> Assembly Information
An easier way to manage this is to REMOVE the AssemblyFileVersion from all assemblies, including the main executable and all the managed DLLs.
In each of your AssemblyInfo.cs files, I recommend doing something like this if you don't care about the version numbers, but want to have some traceability.
[assembly: AssemblyVersion("1.1.*")]
// don't need this [assembly: AssemblyFileVersion("1.0.0.0")]
Everything still compiles fine, and if you don't have the AssemblyFileVersion defined, then the installer assumes that everything is different every time (which is probably fine if you are installing all of the DLLs next to the main EXE).
I spent a long time figuring this out, especially if I don't want to have to increment anything manually!