We Keep Coding

C# Setup Project Installer Not Removing Previous Version

I want to write an msi installer that uninstalls the previous version when it is run. I have a setup project in VS 2013 with DetectNewerInstalledVersion=True and RemovePreviousVersions=True. Here is what I do:
I change the version number (eg from 1.0.3 to 1.0.4).
I make sure the ProductCode changes and the UpgradeCode does not.
I right click the setup project and click Build.
I run the msi file in the Debug folder.
The msi runs just fine, but the old EXE is still in the programs folder. It successfully installs the program if it's a fresh installation though. What am I doing wrong?

I've finally found the answer actually, and I'll post it here for people who stumble across this. Here's the one step I was missing:
You need to go to Properties > AssemblyInfo.cs in your project and update the AssemblyVersion and AssemblyFileVersion numbers. Otherwise your EXE for this project won't actually update. Hope this helps!

Why don't you plant a custom action to backup and delete previous installation folder for additional safety :)

Issue faced during uninstall MSI using its Product Code in c#(DTF)

I am creating a CustomBA which will replace the existing install shield Bootstrapper( I don't really know what it's called).
We are installing the same number of MSI as the install shield use to do, so no problem in that.
All the MSI entries in the ARP are removed, as we are making MSI's Visible="no".
Only the Custom BA entry is available in the ARP along with the Install shield Bootstrapper entry, both having the same name.
So after some research I got to know that Windows Installer XML (WiX) ships the Microsoft.Deployment.WindowsInstaller interop library as part of Deployment Tools Foundation (DTF), which can be used to uninstall the MSI.
I am using the below code to uninstall the MSI.
Microsoft.Deployment.WindowsInstaller.Installer.SetInternalUI(InstallUIOptions.Silent);
Microsoft.Deployment.WindowsInstaller.Installer.EnableLog(InstallLogModes.Info, #"C:\Uninstall.log");
Microsoft.Deployment.WindowsInstaller.Installer.ConfigureProduct(productCode, 0, InstallState.Absent, "");
Issue that I am facing are as mentioned below
Firstly I have to run the CustomBA as Administrator to uninstall the existing MSI else it throw as error "Error 1730.You must be an Administrator to remove this application.". Is there a way to run the CustomBA without Administrator and uninstall the MSI.
While uninstall( when I run the customBA as admin), the above mentioned code also remove's the chain packages with it, which I don't want it to do.
After the uninstallation code has been run it does not remove the MSI entry from the ARP.
I've found these links but I don't know if it's relevant:
https://stackoverflow.com/questions/17523974/how-to-uninstall-msi-using-its-product-code-in-c-sharp
Checking for successful uninstall

If you need to be admin then you need to be admin. Allowing a limited user to change areas of the system that are restricted would be a security breach.
You used the word "chain", so it looks like that InstallShield setup was a multiple-MSI install, perhaps with embedded UI that is suppressed. So it appears that the previous MSIs were installed as single-product view and it looks like they are all uninstalled, also as a single product view - they all uninstall. That was probably the intention in the first place - to make multiple MSIs appear as a single product, all installed and all uninstalled. Also, if that IS install was a chain of MSIs then surely you are going to replace them all (or upgrade them) anyway, yes? That's what Burn and BAs will do too.
Which MSI's ARP entry? It's not clear from your post which MSI, assuming you may be referring to one of the chained MSIs installed by IS. And are you sure it is an MSI entry that remains? It might be the chained product's entry that was put there by InstallShield, not an MSI entry. Certainly if your uninstall of the MSI worked its ARP entry would be removed, but may need a refresh to see that it's really gone (but that's a Windows issue). Keep in kind that chained MSI products (and often Burn too) will suppress the individual MSI ARP entries in favor of a single entry that encompasses the multiple MSIs.

Visual Studio Setup Project not removing DLL

I have a problem regarding the Visual Studio Setup Project and uninstalling an application.
This is a very basic installer, installing an ApplicationLauncher.exe C# .NET 4.0 console application and an Application.Common.dll (a dependency of the application ApplicationLauncher.exe).
The installation is a success, copying both the exe and DLL into the program files folder C:\Program Files (x86)\Company\ApplicationLauncher\.
My problem comes when uninstalling the application (through the MSI) - the uninstall seems successful, however it leaves Application.Common.dll behind, and doesn't remove it as I would expect.
I've used ProcessExplorer to make sure nothing else is using the DLL, no explorer windows are open during the uninstall.
Is this the expected functionality and do I have to create a custom action to remove this DLL? Or have I done something wrong? :S

It seems I was able to fix this issue by renaming the solution and product name of the application, I'm not sure how this fixed it, but it did.
My only thoughts here is this traversed through to the installer, where the application installed into a different folder, thus not applying the same permissions to the DLL..

It's not expected, no. It will happen if you ever done any of the following with your setup and installed it:
Marked the file Permanent.
Marked the file SharedLegacyFile true.
These are project settings, but if you set either of them and do the install it will stay behind. You can unset them in the setup project but that's too late - you've marked that component permanent or sharedlegacy on the system. If you use a brand new system, like a fresh virtual machine, reset these values if they are set and rebuild the MSI and do the install/uninstall does it still happen?

I had the same problem. Then I have tried to install and unistall my app on Windows XP and that had worked.

Renaming the ProductCode is treating the symptoms not the cause. The problem occurs when the uninstaller doesn't remove the dll. The next install will use the dll again and can't remove it on an uninstall event because it's still used by the other program.
These steps hopefully solve the problem:
Install your Software
Open CMD (with admin privileges) and run:
msiexec /x {ProductCode} /L*V "C:\CustomPath\FileName.log"
The ProductCode can be found when hitting F4 on the Setup Project
Open the log file and search for the lines that look something like this:
Disallowing uninstallation of component: {6CEC09F6-9108-7062-A692-2BCBACEE3BD8} since another client exists
Disallowing uninstallation of component: {A0A0FA84-CC0D-C5C4-1F57-169788C4482D} since another client exists
Disallowing uninstallation of component: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} since another client exists
All these components have to be removed from the registry by hand. To do this the GUID (e.g. {6CEC09F6-9108-7062-A692-2BCBACEE3BD8}) first has to be converted into a packed/compressed GUID (e.g. 6F90CEC6801926076A29B2BCCAEEB38D). I found a Website where one can run a script to do this. Find the following code on the website and replace the right side with the GUID from the log.
string inStrGUID = "{6CEC09F6-9108-7062-A692-2BCBACEE3BD8}";
Open the registry (as an administrater) and search (Edit -> Find...) for the compressed GUID (uasually it's somewhere in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\)
Delete the folder that is equal to the compressed GUID. The values inside the folder should be a path to the dll.
Once deleted select the parent folder (...\S-1-5-18\components) and hit Edit -> Find...
Repeat these steps (4-7) for all components from the log file.
It's also a good idea to delete all files still present in the original folder that weren't uninstalled.
Can one prevent this from happening?
I don't know. This really isn't that easy to reproduce. Some other post on SO have suspected the install/uninstall option in Visual Studio to be the cause of the problem but I have a different theory:
This bug might be the result of RemoveExistingProducts in InstallExecuteSequence in the Setup being executed too late and therefore not removing dlls at the right time. This bug is known for years and can be fixed by doing this. If you need help with Orca this explains how to install it.

MSI setup installation and uninstallation issues

I have an MSI installer, which have my custom installer project output and I added an exe file to run while installation.
So my MSI setup file will copy or remove files from source location and my custom GUI will install my window server call some server api's and updated its logon credentials etc stuff.
Copying and removing is of files is controlled by MSI on its action as its added as output for MSI project. If I am installing its will copy files or if I uninstall it will remove files.
Now I have below problems -
1) Now if I will go to control panel and try to uninstall my application and later from GUI if I abort it, my GUI will abort but MSI will clear all files.
2) If I will select uninstall and further from GUI, select repair. It will still remove files.
So my installer is not real custom installer, its just namesake one.
Now how can I quick fix above two options?
And is there any better approach to do this task - > my original question create single click msi file of custom installer of an application ?
Thanks in advance

It sounds like you are trying to do things at the wrong time. In any installation system you should gather all user input up front and then once the installation itself starts there should be no further requirement for user input until everything is done.
The easiest way to ensure integrity is to only let the user cancel during the UI gathering phase, not the installing phase. If you do want to let the user cancel during the install phase, you have to pass that on to the underlying engine so that it knows to cancel and rollback any changes made thus far.

It seems to me that you need to set proper conditions for your actions like one that initiates your exe-file execution. Try setting something like "Not installed" so that it would occur only during initial installation but not during remove/repair or upgrade.

How to find a Windows Forms Application's Product Code?

I need my application to uninstall itself.
Reason: It's come to my attention that my app is destroying its own files (my bad), but the user of my app doesn't understand why he needs to uninstall it and refuses to uninstall it. However, he still complains about the constant problems. And in the Terms Of Use, there is a line that says "...we reserve the right to remove the application from your computer and temporarily or permanently discontinue your use of the software."
So, I did some searching on how to uninstall a program, (which will be replaced by a new version), and came across Uninstall C# windows application from self and the accepted answer says you need a 'product code'. What exactly is that, and where can I find/get it from? I have searched for this but can't find anything.
Thank you

The productcode can be obtained from your MSI by opening with orca, the msi db editor and lookup the productcode in the Property table. Orca is part of the Windows SDK.
You can also run your msi
msi /i [your msi] -lvx* log.log
and harvest the productcode from the log.
The easiest way is by getting it from the author files of your setup as Ken White already pointed out.

You created the product code (if it exists) when you created your MSI to install your application. You need the same product code you used in the installation in order to uninstall it via Windows Installer.

I am not sure about VS 2010, but in VS2008 setup projects have a ".vdproj" project file, which can be opened with a simple text editor (like notepad). If you search for the word "ProductCode", you will find a line like
"ProductCode" = "8:{GUID}"
(the GUID is what you are looking for).