I'm facing a problem with InstallShield installer.
I'd created a installer with a wrong custom action called in "After System Changes" event which should alert a message to the user.
This action was made in JScript, but in one of the builds I removed the JScript file and forgot to remove the custom action call.
Because that, I have the software installed on my pc and now I can't to uninstall it.
When I try, I get the message:
"Error 1720. There is a problem with this windows installer package. A script required for this install to complete could not be run. Contact your support personnel of package vendor. Custom action FeedbackInstallationComplete script error -2146823..."
I have no idea to solve this problem.
Does someone knows how to solve it?
Thanks a lot.
Typically the correct approach here is to create a minor upgrade that resolves the problem (either removing the custom action, or supplying the file), install it with REINSTALLMODE=vomus, then uninstall the corrected package.
This is, unfortunately, a little harder with the limited edition, but shouldn't be outright impossible.
Related
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.
Here is the error message: The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2869. The arguments are: ErrorDialog,
I found another link related to the problem. The link here
Will cleaning the registry work. I tried the tool mentioned there but it needs registration.
Can this be resolved
This cannot be answered without knowing more about your installer and the context that you are installing it. Generally you aren't following MSI best practices and you are getting into a situation where you don't have the proper privs to do the install.
This really doesn't have anything to do with the fact that you have a service although if you are using an InstallUtil custom action consumed by an Visual Studio Deployment Project installer then your problem is probably that VDRPOJ is so broken it schedules deferred custom actions with impersonation instead of system context.
I have resolved my problem. It was a critical one really.
Here is what happened:
The service I wrote crashes soon after starting. While crashing, it probably holds onto few resources and hence when I try to uninstall it, it wont be removed from the list of services, that is, it is never removed from registry.
Now that it's still entered on the registry, I can neither install or uninstall it. The .exe has been removed in last un-installation, therefore there is nothing to uninstall.
The solution was to manually remove the entry from registry. I have changed my code so that it doesn't crash or at least it's handled as an exception.
We found a bug in Web Service Software Factory a description can be found here. There has been no updates on it so we decided to download the code and fix it ourself. Very simple bug and we patched it with maybe 3 lines of code. However* we have now tried to repackage it and use it and are finding that this is seemingly an impossible process.
Can someone please explain to me the process of PLKs? I have read all about them but still don't understand what is really required to distribute a VS package.
I was able to get it to load and run using a PLK obtained from here, but i am assuming that you have to be a partner to get a functional PLK that will be recognized on other peoples systems?
Every time i try and install this on a different computer I get a "Package Load Failure". Is the reason I am getting errors because I am not using a partner key? Is there any other way around this? For instance is there any way we can have an "internal" VS package that we can distribute?
Edit
Files I had to change to get it to work.
First run devenv PostInstall.proj
Generate your plks and replace ##Package PLK## (.resx files)
--Just note that package version is not the class name but is "Web Service Software Factory: Modeling Edition"
-- And you need to remove the new lines from the key
ProductDefinitionRegistryFragment.wxi line 1252(update version to whatever version you used in plk)
Uncomment all // [VSShell::ProvideLoadKey("Standard", Constant in .tt files.
The short answer is no, you don't need to be a VSIP partner registered with Microsoft to obtain and use a PLK. The PLK you obtained from the site should work on any VS install. (On a related note, Microsoft has eliminated the requirement for PLK's altogether for VS 2010.)
The following pages should help with debugging what the issue is:
http://msdn.microsoft.com/en-us/library/bb164677.aspx
http://blogs.msdn.com/dr._ex/archive/2006/12/14/debugging-package-load-failures.aspx
There is also a tool in the Visual Studio 2008 SDK called the Package Load Analyzer that should help you debug the load failure (and confirm that it's actually a PLK issue and not something else). Copy and run VSSDK_PLA.exe (under VisualStudioIntegration\Tools\Bin under the VS SDK install location) to your test machine to install the Package Load Analyzer tool.
You don't have to worry about package load keys when rebuilding the Web Service Software Factory because it is a guidance package that depends on GAX, which has the only PLK needed. To build guidance packages, like the Service Factory, you also need to have GAT installed.
The Service Factory source should contain the setup projects you need to build and redeploy it. If you have an issue, the discussion forums on its community site (http://servicefactory.codeplex.com) are monitored by team members. Response is pretty good.
Aaron is right that this whole story gets a LOT easier in VS2010. VSIX is pretty sweet. We are updating the Service Factory to VS2010. It should be ready for release within a month.
Don
MS p&p
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!
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.