We Keep Coding

After installing Application it ask me admin credentials

I am a bit confused. I have a C # WPF application. This works as I wish when I run the EXE file.
Now I have set up an installer (Visual Studio Installer project). This installer installs the application as desired and creates a desktop shortcut.
If I start the application now via the desktop icon, then installer is executed again and it is asked for the admin access data. After entering the data, the application starts directly. And that happens every time I click on the desktop icon.
I use in the application project the costura.fody package to bind one executable.
Have someone ideas whats wrong?
I've read the desktop icon from Visual-Studio-Installer-Project check always the application state. I think this is why the installer start every time I click the app icon on the desktop.

Short Answer: This is an MSI self-repair problem.
Work out what component triggers the self-repair. Details below.
Correct the situation by making changes to the setup eliminating the conflict situation.
Self-Repair: This is self-repair, or self-healing or "resiliency" depending on who you ask. I have a description here: Why does the MSI installer reconfigure if I delete a file? Towards the bottom there are three links. I would go for the one saying "how to avoid in your own package".
Understanding: There is a longer explanation of self-repair here. Section "The Primary Causes of Self-Repair" explains 3 main causes, yours being the first one.
Culprit: You should check the event log for clues as to what file / component is triggering the self-repair:
Stefan Kruger's debugging procedure
My own version here (longer) (section "Finding the trigger or culprit for the self-repair").
Once you have worked out what component triggers the repair there are a variety of fixes. But first maybe check the list of common mistakes in your own package.
Previous Answer: Come to think of it there are several previous answers:
Window's pop-up constantly appears when installed application is launched (seems better than the above)
Visual Studio 2015 msi build initiates another installation

How to skip folder selection form when update installed application via Windows Installer setup project

As the title describes, I am trying to skip the folder selection form when update the installed application via setup project in visual studio(casue the user already selected folder path when they installed the app). I googled online and find a way to disable folder form: http://www.codeproject.com/Tips/437285/Visual-Studio-Deployment-Setup-Disable-Installatio. However, How to know if it is installation or upgrade? If we know it is upgrade, how to get the installation path?
Thanks in advance!
I do not find any approaches to skip that folder form. This should be the reason that many installer tools exist in the market. Since my app is very small, I simply disabled the folder selection dialog. For anyone who are interested, please check this URL: http://www.codeproject.com/Tips/437285/Visual-Studio-Deployment-Setup-Disable-Installatio

If you saved the original install location in the registry, for example by saving [TARGETDIR] in a registry item, then you can retrieve it during an upgrade. You find out you're doing an upgrade because it will set a property called PREVIOUSVERSIONSINSTALLED. The problem is that there is no way to wire it all up in a VS setup project. You want the browse dialog there (not deleted) but you want to skip it if PREVIOUSVERSIONSINSTALLED has been set, and there's no support in VS setup projects for that. You'd need to go into the ControlEvent table in the MSI file and figure out how to skip the browse dialog, as well as have the Back button skip over if necessary, and that's just very difficult.
What's the actual issue? Visual Studio upgrades are complete installs that uninstall the previous product and install the new one wherever the user wants, so why is it necessary to install in the same location as the previous install?

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.

Optional User's Desktop shortcut issue

(Using VS 2010 with a Visual Studio Installer project.)
I have added a 'Checkboxes(A)' dialog to the 'User Interface' under the 'Start | Welcome' dialog and set a checkbox with the property set to "DESKTOPICON". The option is being displayed.
In the 'File System' the 'User's Desktop' has the condition property set to DESKTOPICON=1.
When I run the install on my VM the option appears to be ignored and the desktop shortcut under the User's Desktop list is always installed.
I looked at these similar posts but it does not seem to work for the desktop icon?
How do I specify Visual Studion Installer Conditions?
Visual Studio Deployment Project Optional Desktop Shortcut
Is it normal for the User's Desktop to ignore it's condition property or am I doing something wrong?

Visual Studio setup projects create only shortcuts to installed files. This type of shortcuts are linked to their target and share the same component.
Since in Windows Installer you can condition only components and features, you cannot condition a shortcut directly.
A common approach is to write a custom action which removes the shortcut. You can then condition the action instead of the actual shortcut or its folder.

Well, I know it's been a long time but today I faced exactly the same issue as mentioned. I wanted to try creating a windows installer in VS 2013 using "Installer Projects" extension thing and wanted to make a checkbox with condition whether create a desktop shortcut or not.
Like above, shortcut under User's Desktop was always installed.
After wasting almost 3 hours I found a workaround on the old Microsoft Connect feedback post: (which apparently was already dead for some time)
Ok I got this to work by adding the main file twice to the folder (the
file you are creating your shortcut to). I tie the shortcut to one of
the files and on that file I set the condition to CHECKBOXA1=1 so it
will only create that file and the shortcut if they check the the
"Create Shortcut" box. For the other file I set the condition to
CHECKBOXA1<>1 so it will create it when the check box is anything but
1 (not checked).
originally posted by Chancea on 7/1/2010
I tried to do it that way - it works as intended. Not really convenient whatsoever (can mix up the same looking names etc). For a really, really simple installer thing (which I needed) with an only additional feature, adding shortcut to desktop, it might be fine however.
Nevertheless I still think it only proves that this is just a port of an Installer Project from earlier versions of Visual Studio, now added by an extension.
The idea may be good and useful I think, but I wish they fixed just some of the Windows Installer project in VS issues and lack of features.
Like I said, it would be great option for people (... like me) who want to publish some pretty small and lightweight apps, and needs only some basic features from the installer like (optional desktop shortcut, adding to startup, installing some additional files etc etc).
Well, I guess the conclusion is that I'd just have to start learning WiX or try out the InstallShield

After another 2 1/2 years in VS2019: The problem remains that the shortcut created in the "User's Desktop" folder can not handle the condition imposed by the checkbox. Thus a somewhat simpler (but also not "clean") solution would be not to duplicate the exe (e.g. myApp.exe) like in Skippers solution (it did not work for me), but to create an additional myApp.bat file doing nothing but starting the myApp.exe.
The simplification consists in the fact that only a condition on the myApp.bat file is necessary, and no one on the myApp.exe file.
The following steps worked here:
Create a myApp.bat file doing nothing but starting myApp.exe, i.e. containing the single line "myApp.exe" (without the quotes). Of course, commandline parameters would be possible if necessary.
Put myApp.bat into the "Application Folder" of your installer project.
Set the condition on myApp.bat to CHECKBOXA1=1, meaning it is created only in case of the CHECKBOXA1 having been set.
In the "User's Desktop" folder of the installer project, create a shortcut to myApp.bat (Context menu "Create new shortcut"), give it the icon of your app ("Icon" property). Do not specify a condition. Here in my case (VS2019 on Win10) this resulted in a NOP action when the myApp.bat was not created (checkbox unchecked), and properly created the link on the desktop when myApp.bat was present (checkbox checked).
For this shortcut, you might wish to set the "ShowCmd" property to vsdscMinimized, to avoid the large command line window of the bat file.

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).