Is it possible to create a desktop icon using ClickOnce

Is it possible to create a desktop icon using ClickOnce

• Remi Thomas

  How do you run this code at ClickOnce program startup
  

• wilsonLOP

  Ohhhhh, have you talked with novice Windows users My application is used by non power users, whenever I see their desktops they are FILLED with icons for their most-used applications. If I released my product WITHOUT a desktop icon my users wouldn't know how to execute it. This is a HUGE omission for Click Once and I'm not sure if I can actually use it when I upgrade my product from .Net 1.1 to .Net 2.0.

  Also, I don't want my users to see the Application Update confirmation dialog - is there any way to do that (and still put the program item on the start menu) This is a training and usability issue. 100 CSRs use my application - if I can't perform automatic upgrades without the confirmation dialog, I'll have to teach them to click "OK" on the confirmation dialog. CSR turn over is about 50% per year and my release cycles are every 4-6 months, so every time I release, 15-25 of the CSRs will not have seen the update dialog before and half of the other CSRs won't remember ever seeing it.

  TRZ

  
  

• Ananth Govindarajalu

  David,

  Thanks for the response.  I wrote my own version of no-touch deployment to get around the limitations of version 1 no-touch and now it looks like I can't just use point and shoot behavior of Click Once because MS doesn't feel as though I should use it that way.  I'm sure there are ways to get around the limitations that MS put in my way, but why did they feel that I needed those limitations in the first place (This is more of a statement and philosophical question, not an actual question). 

  Dan - thanks for the information, it's much appreciated.

   

  TRZ.

   

  
  

• jeffrafter

  In regards to auto-starting a ClickOnce app, I have written a funtion that utilized the registry to replace the Explorer shell with my own application. My application takes the place of the windows explorer shell (Start Menu, Desktop and all) and is very kiosk-like in nature.
  
  The code to replace the Windows shell is shown below:

  
  Dim path As String = My.Application.Info.DirectoryPath & "\" & My.Application.Info.AssemblyName & ".exe"
  Dim regKey As RegistryKey
  regKey = Registry.CurrentUser.OpenSubKey("Software", True).OpenSubKey("Microsoft", True).OpenSubKey("Windows NT", True).OpenSubKey("CurrentVersion").OpenSubKey("Winlogon", True)
  If Installing Then ' Installing so set the shell to the current application path
  regKey.SetValue("Shell", path)
  Else 'This will restore Windows Explorer as the default shell
  regKey.DeleteValue("Shell")
  End If
  

  The problem with this approach is that it must be repeated after each update as the link seems to be fixed to the current running version. Another problem is that the solution relies entirely on the Win NT/XP registry structure and probably wouldn't be compatable with Vista. In regards to creating a desktop shortcut, I would use the above method to determine the application path and then use the scripting object model to create the link in application code.

  It really isn't that much coding, although it does seem a little jury-rigged.

  Hope this is helpful,

  
  
  

• amiri

  To Create an link use the fallowing.

  CreateShortCut(1)

  CreateShortCut(2)

  CreateShortCut(3)

  
  'This is then sub function.
  Sub CreateShortCut(ByVal ShortCutType As Integer)

  Dim wss As Object, linkobj As Object, SpecialPath As String
  Dim LinkFilename As String, StartUpPath As String
  Dim fileExists As Boolean

  on error resume next

  wss = CreateObject("WScript.Shell")

  Select Case ShortCutType

  Case 1
  'Create a desk top icon
  SpecialPath = wss.SpecialFolders("AllUsersDesktop")
  LinkFilename = SpecialPath & "\" & My.Application.Info.AssemblyName & ".lnk"

  Case 2
  'Create a start up icon
  SpecialPath = wss.SpecialFolders("Startup")
  LinkFilename = SpecialPath & "\" & My.Application.Info.AssemblyName & ".lnk"

  Case 3
  'Create a Favorites URL
  SpecialPath = wss.SpecialFolders("Favorites")
  LinkFilename = SpecialPath & "\" & My.Application.Info.AssemblyName & ".url"
  End Select

  ' Checks to see if File Is Foundor not, no need to create again

  fileExists = My.Computer.FileSystem.FileExists(LinkFilename)

  If fileExists = False Then

  linkobj = wss.CreateShortCut(LinkFilename)

  If ShortCutType = 3 Then
  linkobj.TargetPath = My.Application.Info.DirectoryPath & "\" & My.Application.Info.AssemblyName & ".exe"
  Else
  linkobj.TargetPath = My.Application.Info.DirectoryPath & "\" & My.Application.Info.AssemblyName & ".exe, 1"
  linkobj.WindowStyle = 1
  linkobj.WorkingDirectory = My.Application.Info.DirectoryPath
  linkobj.Description = My.Application.Info.AssemblyName
  linkobj.IconLocation = My.Application.Info.DirectoryPath & "\" & My.Application.Info.AssemblyName & ".ico"
  End If

  linkobj.Save()
  End If

  End Sub

  
  

• Devz

   

  It is not a feature of the deployment.  In fact, it is not obvious that a ClickOnce application installs a shortcut in the start menu.  A user would really never know at install time. 

  I would recommend having your program script the shortcut at runtime.  (probably not the best practice, but certainly viable if your assembly has the permission).

  Brian Duper

  http://www.slickscreen.com

   

   

  
  

• Troup

  There's actually a lot of thought into the designs of ClickOnce, though I'm not up to speed on all the details.

  One major goal was to make the installs "non-impactful", so that they could be allowed in corporate environments that had locked down desktops so that .MSI's could not be installed. Not everyone agrees, but enough felt strongly enough that Desktop Icons were impactful enough, and not considered to be a best practice anymore. And, there are workarounds as I've pointed out.

  A non-goal was to be able to install anything and everything exactly the way anyone wanted. Windows Installer pretty much fills that spot.

  I'm pretty sure there were some other considerations as well.

  If there is enough user-feedback that says that a particular design decision was wrong and is blocking adoption, then we'll certainly re-evaluate it. For example, I know the ability to target per-machine installations is being reconsidered based on feedback.

  A great way to provide that feedback that goes directly to the product teams is the MSDN Product Feedback center at: http://lab.msdn.microsoft.com/productfeedback/ and enter a suggestion.

  Hope that helps. We really do want to hear the feedback and make as many customers happy as possible.

  
  
  

• Mathew N

  ClickOnce does not support the creation of desktop icons.

  Most feedback I've heard is that people don't like having a bunch of icons on their desktop anyway :-)

  However, if you want to create one, there is a workaround, provided your application has the needed file code access permissions. You can write code in the startup of your application (ClickOnce apps startup after install by default) that will create the desktop icon. Here is a link to a code sample for how to do it, you can convert it to VB.NET or any other managed language easily enough I think:

  http://msdn.microsoft.com/library/default.asp url=/library/en-us/script56/html/e6ac108b-15f6-4a54-891f-589e8b687ace.asp

  The downside is that if the app is uninstalled, the shortcut won't be removed.

   

   

  
  
  

• Meeta Kherdekar

  Having tried the wshshell way of creating shortcuts I found numerous problems with working like this the biggest being:
  i. Having to create a wrapper
  ii. If you run a ClickOnce app from a .lnk shortcut it doesn't seem to recognise it as a ClickOnce app and so using the handy System.Deployment classes like ApplicationDeployment.IsNetworkDeployed will return False not True.

  The easiest and neatest way that I have found to do this is to use System.IO to copy the .appref-ms file to the desktop. Because neither the coder, nor the user doing the install, seems (to my knowledge) to have any control over the shortcut put in the Start/Programs menu it is safe to copy. Be sure to add the file extension of ".appref-ms" to the shortcut name that is passed in!
  This seems to work well, although you still can't uninstall it automatically (I hope Microsoft will let us have custom uninstall actions in the next version).

  The code I am using is basically:

  private void copyShortcut(string manufacturerName, string shortcutName)
          {
              string desktopDir = System.Environment.GetFolderPath(Environment.SpecialFolder.DesktopDirectory) + name;
              string startDir = System.Environment.GetFolderPath(Environment.SpecialFolder.StartMenu);
              startDir += @"\Programs\" + manufacturerName + @"\" + shortcutName;
              try
              {
                  System.IO.File.Copy(startDir, desktopDir, true);
              }
              catch (Exception e)
              {
                  throw e;
              }
          }

  
  
  

• Jay Jones

  To confirm - it is by-design behavior that ClickOnce install does not create shortcuts directly on the desktop.

  One of the goals of ClickOnce was to make the user experience of installing and running rich client code as "web-like" as possible, with apps and updates coming in and off the system easily. Towards this end two styles of applications are supported - "online-only" which are only activate-able via URL and have no shell presence and "installed" which generate a startmenu shortcut, (and optional support url link) and as well an Add/Remove Programs entry so the app can be uninstalled or even rolled back to a previous version. In keeping with the web-like model we wanted to be as minimally invasive as possible in terms of shell footprint and opted to not "spam" the desktop with shortcuts (note that on the XP startmenu will light up with a notification that an app has been installed for ClickOnce apps).

  Why ClickOnce doesn't provide other "enhanced presence" install options in its first release:

  Application shortcuts and ARP are probably one of the simplest examples of system extensibility - these are simply mechanisms by which the system can be made to call into application provided code or data. Others examples are file associations, context menu handlers, the startup group and screen savers, etc. There are hundreds, if not thousands, of system extensibility points exposed in Windows. There is a significant measure of fragility in the way that extensibility points have been traditionally exposed. The registry is a good example of this: There is no common schema for extensibility points. Applications and installers have to write procedural code to register any given extension. They can get this wrong, or conflict amongst themselves over which application owns the registration (eg two apps silently battling over ownership of .mp3). Uninstalls frequently wipe or even leak the registration, and there is not even good system support for getting back to a previous handler or default even for apps that want to do the right thing on uninstall.

  Given the web-like model for ClickOnce apps we decided to be careful about supporting extensibility mechanisms, given this fragility and opted for supporting simple shortcuts only for the first release. We are looking at supporting more kinds of extensibility points in future releases, and support for file associations and some type of auto-run functionality are at the top of the request list. We intend to continue to be careful about the number and kinds of extensibility points supported - clicking on a deployment url and having 50 different things change behavior subtly and not so subtly on the users system is not really part of the current ClickOnce model.

  That being said, the extensibility points we elect to support in the future will be driven by customer request, be fully manifest declarative and require zero application code to register or unregister, have a mechanism to allow the user to resolve conflicts between apps and also have the ability to restore to previous or default settings on uninstall. As part of this design it should also be possible for ClickOnce applications themselves to advertise their own extensibility mechanisms that other ClickOnce applications can plug-in to as handlers (ie a ClickOnce spellchecker plug-in app that can be leveraged by other applications) with ClickOnce managing registration details and lifetime logic under the covers so apps don't have to deal with the complexities of this. There are a lot of things we can do with a declarative manifest based model and we intend to pursue improvements, but also want to ensure that we get it right the first time.

  
  

• ManishDotnet

  TRZ,
  
  To take the update confirmation dialog away from the user, just set the minimum required version (Project Properties->Publish Tab->Update Button->Specify a minimum required version for this application) equal to the Publish Version each time you publish your application. The user doesn't get asked, it just updates. That's how we deploy all our clickonce apps.
  
  Dan
  
  

• Game Programmer

  Yes, I have talked with novice users, and in fact was the primary trainer at a former company. My opinion (and we may just have to agree to disagree) is that they will be able to adapt.

  If not, as I pointed out, you can add code to your application that places the shortcut. You are not really blocked, especially since ClickOnce launches the application on first run.

  With respect to updates, the default behavior is to ask the user. There are some very good reasons for that, but I'm pretty sure you can work around it as well. If you use the System.Deployment (or My.Application.Deployment in Visual Basic) objects, you can programmatically check for updates, download updates, and then do whatever you want once the update is downloaded, like shutdown, give a message to the user to restart the app, or nothing and wait until the user restarts on their own and gets the new version.

  I hope this helps to solve your needs.

  
  
  

• Keyvan Nayyeri

  In the main method of the application I insert a check to see if it is the first time that the application has run (System.Deployment.Application.ApplicationDeployment.CurrentDeployment.IsFirstRun) and then create the shortcut. I only check on the first run of the app because if the user has chosen to delete it I don't want to add it again.

  To try not to 'Spam' the desktop as Microsoft put it I launch a form which offers to install the icon on the desktop if the user clicks Yes. I also put a link in a help menu offering to create the shortcut if the user requests (in case they delete it or change their mind).

  The most annoying thing for me at the moment is that due to the unavailability of uninstall actions I have to publish a 'known issue' with my companies software that informs the user that the shortcut will not be removed on uninstall :(

  
  
  

• Crazy8

  I wondered if you had any input in relation to dedicated machines and configuring ClickOnce to make an application auto-start on boot time.

  Its a similar idea to the desktop / start menu icon issue, since in the crudest case I could create a icon in the good old Startup folder.

  The scenario is a public kiosk. I would like to use ClickOnce to deploy and update, but a key component of that is being able to have the Kiosk application auto-start in the event of a reboot.

  
  
• Is it possible to create a desktop icon using ClickOnce