(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.
Related
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
I have been planning to create a installer using the "Setup Project" included in visual studio. I want to create this in such a manner that it allows separate Client/Service installation using a single MSI file.
Can anyone guide me the right direction/Steps to follow.
To elaborate it a bit more the client application will be a desktop application and the server app will be windows service.
In general, you add a RadioButtons (2) dialog to your setup from the canned list, and make the user choose one, or checkboxes if both are allowed. If it's radio buttons, there's a property BUTTON2 which will be 1 or 0 depending on which was selected. Then each file for client or server you set a condition BUTTON2=1 as appropriate.
There are some nasty gotchas. One is that a repair will go through reinstall and the value of BUTTON2 will be undefined so you'll get unexpected results. One way to deal with this is to create a registry item with the value [BUTTON2] so that the value is saved in the registry, then you can add a search for that value to re-initialize it in case of repair.
VS setups don't have a good way of doing this because they don't have multiple features that you can choose from, and that can be modified by going into Programs&Features and changing them. VS setups all have a single feature, so all you can do is condition the files/components being installed based on checkboxes and radio buttons.
The properties window of every file being installed (Solution Explorer pane) includes a Condition property. Selecting the file in Solution Explorer then doing F4 shows the properties window.
Hi I'm trying to get an optional desktop shortcut integrated with a VS2010 deployment project. I'm at the part where I have set added a shortcut to the "User's Desktop" of the TargetMachine file system, and I have set up a Checkboxes Dialog in the User Interface. How do you get the Checkbox1Property to transfer over as a conditional for creating a shortcut to the desktop? I don't see any options to add a conditional statement that can link the Checkbox1Property when I view the property for the shortcut in the targetmachine file system. The shortcut is always created as of now.
Thanks
For a complete understanding of this, I'd recommend reading:
http://www.codeproject.com/KB/install/vsSetupCustomDialogs.aspx
In short, you've already added the shortcut and created a new dialog window from the "View" -> "User Interface". All that's left is setting the condition property. You can't change this property of the shortcut itself, but you can change it for "User's Desktop".
For that condition you might want: CHECKBOXA1=1 which means the item is created/activated only if the CHECKBOXA1 is checked. 0 for unchecked.
A reference to conditional syntax is here:
http://msdn.microsoft.com/en-us/library/aa368012.aspx
EDIT : I just tested this and it looks like the Visual Studio installer is pretty unintuitive. The answer I provided doesn't work. You have to go about this is an ass-backawards way. This article better describes the process than I can: How do I specify Visual Studio Installer Conditions?
Overall, the Visual Studio installer is intended for fairly vanilla installs. It can do a LOT more, but it's cumbersome to do so. You can even have custom actions run during the installation (ie: run your own executables). The Visual Studio installer is included with VS 2010, but it will be removed in favor of InstallShield LE in future version.
I have some documents I want to install (using the Setup project) onto a Windows 7 system which is accessible by everyone. These documents should not be hidden. They should be visible for all users to double click on. I believe the best place for this is C:\Users\Public or C:\Users\Public\Documents.
Since there isn't a special folder for either of these folders in the Setup project, the only way I have found so far is to create a custom folder and set the DefaultLocation to [%public][Manufacturer][ProductName] etc.
(see http://community.flexerasoftware.com/archive/index.php?t-164246.html)
However, this seems very brittle; what if someone deletes the environment variable for public? Also, would this work on a different language version of Windows 7? Is there a better way to define the DefaultLocation to the Public folder for a Windows 7 install?
The public folder isn't stored in a standard environment variable (System -> Advanced -> Environment Variables) so I think it is very unlikely too many people are doing this, but I understand the need to create a robust installer.
This page has instructions on changing the location of the public folder. The accepted solution is quite involved and requires command line work. The suggestion by Luviana is much simpler. I would test them out and see if they break the %public% shortcut. My guess is that they will not. My best advice is to check it out for yourself and if it still works then you can count on the fact that %public% will be available.
I have a pretty basic c# winforms project that has an associated setup project. It has one custom dialog (Textboxes (A)). When I run the installer, it freezes when I click Next to go to the Select Installation Folder dialog. Then after several minutes, it unfreezes. When I finally click Install, the window disappears but msiexec.exe is still running in the background (two of them actually).
Could someone please tell me what the heck is going wrong?
EDIT: Here's the msiexec log: http://www.mediafire.com/?jqmmimwjgni
The problem does not seem to be the length of the name, but the fact that the name DATABASE is used as an internal MSI property containing the full filename of the installer file1.
If you bind your edit field to that property the value of this property will be overwritten with whatever the edit field contains.
MSI doesn't like that. Unfortunately, I could not find any place where it is documented that the name DATABASE is reserved (The built-in MSI properties are documented here). So I wouldn't say this is a bug in MSI, but bad documentation/developer usability (as it is unfortunately too often the case with Windows Installer).
In your log file you will find the following entries:
MSI (c) (64:1C) [19:30:12:339]: PROPERTY CHANGE: Modifying DATABASE property. Its current value is 'd:\ ... mysetup.msi'. Its new value: 'ProgressNotes'.
And later on when the installer is hanging:
MSI (c) (64:68) [19:30:41:701]: Note: 1: 1314 2: ProgressNotes
Here should probably appear the full path to your MSI file...
Solution: Use any other name that is not reserved.
1You can easily see this if you set Edit1Property to 'DBProperty' and Edit1Value to '[DATABASE]' (without the single quotes).
I found it! I'm pretty sure this is a bug of some sort with the Setup project (can someone else confirm this?).
EDIT: See 0xA3's answer for the real reason as to why this fails.
Steps to reproduce:
Add Textboxes (A).
Add a set one of the Edit1Property, Edit2Property etc to DATABASE something GREATER than 7 characters.
Rebuild and install the project (it should hang on the Select Installation Folder screen).
Hope this helps someone.
PS - Worst bug ever to track down :)
A bug report has been logged with Microsoft.