ClickOnce shortcut reference loss issues RRS feed

  • Question

  • Hello,

    I have a deployment issue that has been running for months with one application we have that is delivered via ClickOnce.

    Providing below some background about it that might be technically relevant though before providing the issue details:

    • The application referred below has been developed in .NET 4.0 and deployed with its respective ClickOnce version through a manual application and deployment manifest generation process
    • We allow users to have multiple versions of the application installed at the same time. The way we achieved this was by manually generating deployment manifests with different signatures for each package we generate when deploying a new version. The manifest signature pattern we established was <application_name>-v<version number>. 
    • The applications were set to; after downloaded via a ClickOnce deployment, be automatically opened.
    • At the time it first opens up, it copies the automatically appref-ms shortcut created under the also automatically generated Publisher's name folder to the Desktop and within a subfolder created within that same Publisher's folder. It then deletes the "original" (ClickOnce automatically created shortcut) from the Publisher's name folder. Basically an upgrade of what RobinDotNet described in one of his articles
    • During the process in the bulletpoint above we also change the shortcut name to be application relevant, something similar to <Application Name> <version number>. We basically take off the dashes from its name and replace it with spaces.
    • The application is deployed in our internal network and is stored in an application server. That way, a user can always install an earlier version if needed. We keep an archive up to 6-7 legacy versions.
    • This application carries a SQL CE private installation since its package carries SDF files.
    • It is also set to work offline. ClickOnce is only meant to distribute it. We have a requirement that this application must work even if a user is not connected to our internal network.
    • We have set an application icon for it.
    • We have also set up a custom installer by replacing the UninstallString at the respective ClickOnce uninstall entry for the version that is being installed. 

    Given all of the background above, our problem is that after sometime the ClickOnce packages are apparently "losing references". Symptoms are basically:

    • Installed application loses the icon and it shows up the regular Windows "blank" icon instead
    • If you double click on it, it will try to reinstall the application again.
    • Uninstaller references are not lost at all
    • Application remains installed normally at C:\Users\<User account>\AppData\Local\Apps\2.0\
    • If there are other applications in the machine installed via ClickOnce, their "references" are also "lost". But they remain installed normally, just like the most recently installed version.

    As far as reproducing the issue, I can now reproduce it everytime on my machine while my end users cannot. It used to happen only once in a while but for my luck (or my lack of luck, you can never tell), it always happen after my first installation of this application. While I am unsure how did I get to this state, I suspect that it might have to do with the ClickOnce cache somehow.

    In other words, it is a very similar (if not the same) issue that I have found in earlier posts at this forum (will post that afterwards for reference).

    Troubleshooting a bit, I found something that could be the underlying cause, but not really sure WHY it happens (and that may be a starting point to find out what the real issue is): By the time that the application shortcut "loses" its reference, ALL of the application ClickOnce cache references in the registry at HKCU\Software\Classes\Software\Microsoft\Windows\CurrentVersion\Deployment\2.0 are gone.

    As for a solution, I considered creating a regular application shortcut referencing the related version's local AppData folder instead of playing around with the appref-ms shortcuts to see if that resolves the issue, but I am afraid that if there is something else going on the engine in the background; despite the efforts of doing this, the problem will just happen again.

    After all of this lengthy post, here is the tricky question: any ideas on how to resolve this issue? =)

    Tuesday, June 25, 2013 3:24 AM

All replies

  • Hi Augusto,

    Thanks for your post.

    I've searched some threads for the issue. But it seems most of the applications are targeting to .NET Framework 3.5 or prior, and the problem occurs after an update. I think that may be not the same with your ClickOnce application.





    It is very strange to see the registry values are missing. Which kind of application are you developing? Is it a WinForms, WPF, XBAP, or VSTO application?

    Have you also tried to log for the ClickOnce deployment to see whether there are any problems?



    Sorry I didn't find which article of Robin to copy the shortcut. Is the original shortcut created by code, or by selecting "Create desktop shortcut" in the publish options?

    Best regards,

    Chester Hong
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help

    Thursday, June 27, 2013 8:56 PM
  • Hi Chester,

    Thanks for the quick reply. The referred application is WPF based. As for your question about the logs, I did exactly what you pointed out and shows me no errors whatsoever.

    As for other references to the same issues in the forum, once I get my account verified, I will be able to post them here in my next replies.

    As for way I followed to create the ClickOnce shortcuts, I coded it in the application as opposed to using the "Create desktop shortcut" in the Publish options. Basically, all it does is what RobinDotNet explains on his blog post, which is to copy the appref-ms shorcut to the desktop. We enhanced it a bit though and we perform the following steps:

    1) We copy the shortcut to the desktop
    2) We copy the shortcut as well to an application specific subfolder within the Publisher Start Menu folder. Say that the publisher is Microsoft, then we copy the shortcut under the Microsoft\<ApplicationName> subfolder.
    3) We rename the shortcuts as they carry the application original signature name when they get created.
    4) We then delete the original shortcut from the Publisher folder

    If you read my post above, you will notice that we do not deploy application updates at any circumstance - the other versions of the same app that we are pushing are considered newer builds and they are deployed via ClickOnce through different signatures so theoretically ClickOnce thinks that they are "different" applications.

    Friday, June 28, 2013 5:22 PM
  • Hi Augusto,

    Thanks for the information.

    It seems that there is nothing wrong in the steps to me. You can also try to post the guid of the other threads if possible. I'll be able to find the thread from the guid.

    Best regards,

    Chester Hong
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help

    Monday, July 1, 2013 8:29 PM
  • Man, what a lot of effort you're going to in order to enable multiple copies of the application to be installed. You do realize you can just change the assembly name and product name (in the publishing properties) and publish it, and it will run side-by-side with another installation with different assembly name and product name?

    Having said that, I'll say that none of this is supported usage of ClickOnce deployment, so it doesn't surprise me that you get odd results. You're messing around with settings that ClickOnce needs to operate correctly. If it doesn't work for you, why don't you try a different deployment methodology? (Or just try changing the assembly name and product name and publishing them and running them side-by-side that way?)

    If you are not changing the assembly name, then ClickOnce can easily confuse the deployments. You say you are manually generating the deployment and application manifests -- how are you doing that? Are you using mage or mageui, creating XML by hand, or what?

    When you put the files onyour application server, are they all in separate deployment folders? So you have "application v-1" and under it is setup.exe, the deployment manifest, the Application Files folder and the deployed files under that?

    What changes have you made to the uninstall string? I would wonder if this would impact the uninstall and cleanup of the ClickOnce cache.

    For your cache, i recommend uninstalling all of your ClickOnce applications and deleting the 2.0 folder. This will, essentially, clear your ClickOnce cache. It sounds like it's completely out of whack! This happens occasionally even with "well-formed" C/O apps.

    The appref-ms shortcuts invoke the deployment manifest online to check for changes. You can link directly to AppData, but you will never get another automatic ClickOnce incremental upgrade.

    My suggestion for resolving your issue is stated above in the first paragraph.

    Good luck. You're going to need it.  ;-)


    Click here to visit my ClickOnce blog!
    Microsoft MVP, Client App Dev

    Tuesday, July 30, 2013 4:58 AM