Member Avatar

I know how to create shortcuts on desktop and program files but i want to make an option with that you can select if you want those two shortcuts or if you don't them.
I've tried this with checkboxes (in User Interface), i've set checkboxes properties and changed "User's desktop" and "User's Start Menu" conditions (in File System). "CHECKBOXA1" for desktop shortcut, "CHECKBOXA2" for start menu shortcut...but it doesn't work... both icons are visible every time.
Does anyone know solution for this?

Recommended Answers

All 2 Replies

This functionality is beyond what visual studio deployment projects are capable of. Basically if you want to do anything except a vanilla install you should consider using Windows Installer XML (WiX) toolset which will be part of Visual Studio 2010.

You could add a custom action to your application for creating shortcuts in VB.NET code, or use a workaround that I found in this article:

Q: Is it possible (in a 2003 deployment project) to make the installation of a desktop shortcut conditional (on the value of CHECKBOXA1 for example)?

A: It is not possible to conditionally install shortcuts. However, it is possible to conditionally install files. The work-around is to add 2 copies of the file you would want to add a shortcut to. Set the condition on each of these files to be based on your check box dialog result, and create your shortcut to point to this file.

So you could deploy your application 3 times with different file names and create a shortcut to different binaries. Set a conditional install on the project output and if the file is not created it will skip creating the shortcut. If you decide on a method and need more help with it please let us know which route you decided to go.

Some notes on the different approaches:
1) WiX - Difficult to learn. I use a combination of InstallShield and WiX. You can use a WiX custom action project to get access to the installer session.

2) Visual Studio Custom Actions -- There is a bug in the deployment projects for custom actions. If you create a custom action DLL for your installer named "Proj.CA.dll", for example, then when you install a product for the first time everything executes as expected. When you upgrade an installation and launch your new installer it will in turn launch the uninstaller for your old installation which loads the custom action DLL in to the main app domain. After your uninstallation is complete it starts the installation process and when it attempts to load your custom action DLL it already has a DLL with that name loaded from the uninstallation so you're actually running an older version of the library.

To work around this you either need to never change change your custom action DLL or give it a unique name for each version

3) The creating multiple files method from MSDN will work but in my opinion is a cludgy solution. It makes your installer needlessly larger to combat a limitation with deployment projects.

Member Avatar

Thanks for answer... i thought it will be something easier to do so I don't know if i will try this. thank you anyway

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, learning, and sharing knowledge.