Is it possible to create a desktop icon using ClickOnce

Question

I found only one article about creating desktop icons, but that article (MSDN) ruled out creating desktop icons. Is this possible with ClickOnce or not? I know windows installer will, but we have a Smart Client and want to provide a way to create a shortcut to the app on the desktop so people could get to it quickly. Any suggestions?

Thanks

 

Answer 1

 

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

 

 

Answer 2

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.

 

 

Answer 3

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

Answer 4

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.

 

Answer 5

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

Answer 6

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.

 

Answer 7

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.

 

Answer 8

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.

 

 

Answer 9

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.

 

 

 

 

 

 

Answer 10

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;
            }
        }

Answer 11

How do you run this code at ClickOnce program startup?

Answer 12

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 :(

Answer 13

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

Answer 14

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,

Answer 15

Can someone explain what is the meaning of the following

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

 

Thanks, just wanted to be sure I am understanding this correct.

Answer 16

Hello,

I had the same requirements for an app (desktop icon, and option to launch on Windows startup), both configurable with checkboxes on my Options dialog. What I did was this:

First, I installed my app on my machine so it would create its icon in the Start menu. I found it in Windows Explorer and copied it to my app directory (a file with .appref-ms extension).

Then I use this routine to create or delete the icon on any of the locations according to the user options:

private const string shortcutName = "Sistema Integral Curves.appref-ms";

public enum ShortcutLocation
{
    Desktop = 1,
    Startup = 2
}

public static void CreateOrDeleteShortcut(ShortcutLocation location,
    bool create)
{
    string destination = null;

    switch(location)
    {
        case ShortcutLocation.Desktop:
             destination = Environment.GetFolderPath(
                Environment.SpecialFolder.DesktopDirectory);
            break;

        case ShortcutLocation.Startup:
             destination = Environment.GetFolderPath(
                Environment.SpecialFolder.Startup);
            break;
    }

    destination = Path.Combine(destination, shortcutName);

    if(create)
    {
        if(!File.Exists(destination))
        {
            try
            {
                string source = Path.Combine(Application.StartupPath,
                    shortcutName);

                File.Copy(source, destination, true);
            }
            catch(Exception ex)
            {
                Debug.Assert(ex != null);  // To avoid compiler warning
            }
        }
    }
    else
    {
        if(File.Exists(destination))
        {
            try
            {
                File.Delete(destination);
            }
            catch(Exception ex)
            {
                Debug.Assert(ex != null);  // To avoid compiler warning
            }
        }
    }
}

I hope this helps!

Luis Alonso Ramos

 

Answer 17

The creating of desktop shortcut would work the first time an application is installed. What happens when an update is made to the application? Couldn't the update install the application in a new cache folder? If that happens then there is 2 problems:

1. You have to get rid of the old shortcut from the desktop?

2. Of course install the new icon?

Thanks

 

Answer 18

Thanks, Neil.  That was really helpful!

 

Bryan

 

Answer 19

yes, this is my problem too.

any solutions for it?

Answer 20

Best solution i have seen so far...i understand the logic behind not having a desktop link with click once...but i still think it should be left to the programer in the end...maybe not have one by default, but if one is needed, it is such a common feature that it should be made available.

Answer 21

How about creating a procedure that will check the icon of each desktop shortcuts and deletes it when it matches the application icon before creating a new shortcut? This will ensure that the latest shortcut is on the desktop after the program is updated. Other possible work around is to save the creation time of the icon then after update, check each desktop shortcut for a match then delete the old shortcut when found.

Answer 22

Just found this while searching for 'create desktop icon'.  Works great.  I just wanted to say thanks...

Answer 23

David,

So if I get this straight, Microsoft "deemed" a desktop icon as a security risk?  What specific "impact" does having the ability to create a desktop icon cause?  So you've come to a conclusion that ALL users should operate without desktop icons?  Only Microsoft could come up with such an ridiculous "conclusion".

Here is another thought - not everyone who writes and uses ClickOnce applications is a corporate puppet.

Another thought - end users like Desktop icons, that's why they create them, who are YOU to say they shouldn't be allowed to have them?

This SHOULD at least be an option for ClickOnce deployment (work around not required).  If Microsoft's OS isn't secure or hasn't been correctly designed to be able to handle a desktop icon under a secure context, then that really is MICROSOFT'S problem, not an end user problem, not a developer problem.

I'm not sure what is more laughable, Microsoft's attempt to control how people "should" work with their computers or the fact that in there attempt to cover up the swiss cheese and poorly designed security of the OS, they come up with terms like "non-impactful" -- you do realize the web Microsoft are weaving is one they will regret and will eventually bring Microsoft down as the dominant market share.  So go ahead and keep screwing end user's in the name "security and non-impactful".

I know Microsoft's "user surveys" and "market research" -- it's all done IN HOUSE!  Now that's what I call building in a box.

As a senior developer, designer, architect, and enterprise solution provider I can assure you, the path Microsoft have choosen leads to a dead end.  If you/Microsoft continue to NOT step up to the plate you WILL continue to lose market share.

Rob

Answer 24

Rob Ainscough,

This IS an option in Visual Studio 2008 if you are targeting the .Net 3.5 Framework. I think they really just overlooked it the first time around.

If you're targeting .Net 2.0 and need a shortcut on your desktop, you can easily create one yourself programmatically. Here's a blog posting telling how to do that:

http://robindotnet.wordpress.com/2009/04/07/creating-a-desktop-shortcut-for-a-click-once-application/

RobinDotNet

---

Click here to visit my ClickOnce blog!

Answer 25

Rob Ainscough,

This IS an option in Visual Studio 2008 if you are targeting the .Net 3.5 Framework. I think they really just overlooked it the first time around.

If you're targeting .Net 2.0 and need a shortcut on your desktop, you can easily create one yourself programmatically. Here's a blog posting telling how to do that:

http://robindotnet.wordpress.com/2009/04/07/creating-a-desktop-shortcut-for-a-click-once-application/

RobinDotNet

---

Click here to visit my ClickOnce blog!

Interestingly enough, Microsoft now interferes with variations of that latter workaround in VS2008 SP1 (at least, that seems to be the culprit).  I've been using the workaround for quite some time now, except that I created the desktop shortcut only once.  After a recent upgrade to VS 2008 SP1, I've just had my jaw drop as I watched a desktop shortcut get *deleted* after a newly published update... despite the fact that I'm targeting .NET 2.0 by necessity and thus can't use the built-in feature.  Your specific implementation where you recreate the shortcut after each update works fine, and I've adjusted my workaround accordingly.

What I find fascinating is that this behavior is *specifically* targeted to desktop shortcuts with the name "description .appref-ms" -- shortcuts of the form "Shortcut to description .appref-ms" and "Copy of description .appref-ms" go unmolested.  I've been making some arguments to myself about how this might be a feature to facilitate upgrading from the workaround to the built-in functionaility... but I'm not sure I'm convinced this is good behavior yet.

Answer 26

Yes, they did change it (or we're all barking mad, and I'm not putting my money there), and I'm sure they didn't even think about people creating the shortcuts programmatically out there because they don't support it. (Not that I'm bitter.)

Converting to .Net 3.5 is not a huge deal except for the 80MB download. However, did you know they have started pushing .Net 3.5 SP-1 via Windows Update as a critical update? Yes, indeedy, bob. Here's some info on my blog about how to upgrade your app if you feel so inclined:

http://robindotnet.wordpress.com/2009/05/18/microsoft-automatic-updates-and-net-3-5/

Good luck!

RobinDotNet

---

Click here to visit my ClickOnce blog!

Answer 27

What happens when 'The application is available online only'

Can I create a desktop icon with the image icon of the application how?

it not work with the 'publish/options/Manifests/Create desktop shorcut'

Answer 28

When the application is online-only, ClickOnce creates a desktop shortcut for you. Have you filled in the product name and the publisher name in the Options for the deployment?

RobinDotNet

---

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

Answer 29

I have a ClickOnce app that targets the 3.5 framework, is set to create a desktop shortcut, has the publisher and product name filled in, and is online-only, but I'm not getting a desktop shortcut. Any thoughts?

Answer 30

Online-only applications only create a desktop shortcut, so that's weird. IF you uncheck the box in the options dialog that says "create a desktop shortcut", does it work? (I doubt it.) Do you have any kind of security that would keep it from installing the shortcut?

Did the application really get installed? Can you see it run after you install it?

RobinDotNet

---

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

Answer 31

Online-only applications only create a desktop shortcut, so that's weird. IF you uncheck the box in the options dialog that says "create a desktop shortcut", does it work? (I doubt it.) Do you have any kind of security that would keep it from installing the shortcut?

Did the application really get installed? Can you see it run after you install it?

RobinDotNet

---

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

I've tried it with the "create desktop shortcut" checked and unchecked. I've installed it using the .exe and .application files. I don't know of any security settings blocking the shortcut from being added. I don't have any problem running the application. Is there any way to do it in code if I can't get this figured out?

Answer 32

Online-only applications only create a desktop shortcut, so that's weird. IF you uncheck the box in the options dialog that says "create a desktop shortcut", does it work? (I doubt it.) Do you have any kind of security that would keep it from installing the shortcut?

Did the application really get installed? Can you see it run after you install it?

RobinDotNet

---

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

Some more info to add to my last post. Here's the specific line in my deployment manifest:

 <deployment install="false" mapFileExtensions="true" trustURLParameters="true" co.v1:createDesktopShortcut="true" />

I created a separate test ClickOnce app and it does not create the desktop shortcut either. Could there be something else on the pc it's getting installed on? It does create a desktop shortcut in offline-online mode.

 

Thanks for your help.

 

Answer 33

Are you publishing the ClickOnce app to a webserver or file share?  If it's an online-only app, how are you running it without a desktop shortcut? Can you see the files in the clickonce cache?

RobinDotNet

---

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

Answer 34

Are you publishing the ClickOnce app to a webserver or file share?  If it's an online-only app, how are you running it without a desktop shortcut? Can you see the files in the clickonce cache?

RobinDotNet

---

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

It's published to a file share. I'm running it by typing in the complete URL path. I did see files in the ClickOnce application cache following this path: C:\Documents and Settings\"username"\Local Settings\Apps\2.0

Answer 35

Just an idea -- did you fill in the publisher name and product name in the Options dialog in the main Publish page? If not, can you try it and see if it fixes the problem?

RobinDotNet

---

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

Answer 36

Just an idea -- did you fill in the publisher name and product name in the Options dialog in the main Publish page? If not, can you try it and see if it fixes the problem?

RobinDotNet

---

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

I double checked and both those fields are filled in. I'm not seeing any obvious reason why ClickOnce isn't creating a shortcut. I'm actually publishing two ClickOnce apps and neither of them create a shortcut. Is there a way to do it programmatically if I need to?

 

Thanks for your help,

Answer 37

Just an idea -- did you fill in the publisher name and product name in the Options dialog in the main Publish page? If not, can you try it and see if it fixes the problem?

RobinDotNet

---

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

I ended up doing it in code. It would have been nice to let ClickOnce handle it. Thanks for your help. Maybe I'll run across the answer in the future.

Answer 38

Okay, I have an idea. Can you clear your ClickOnce cache, that's everything under \apps\2.0, and try it again? Maybe it's a caching problem.

Let's talk basics:
What OS is the client machine running?
What version of .NET are you targeting -- it is .NET 3.5 or .NET 3.5 SP-1 ?
Are you using VS2008 or VS2010?
Are you publishing to a webserver or file share?
Are you publishing directly to the webserver or file share from Visual Studio, or doing it manually?
Do you have the MIME type set up correctly on your server?
    http://robindotnet.wordpress.com/2010/06/12/mime-types-for-clickonce-deployment/

RobinDotNet

---

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

Answer 39

Okay, I have an idea. Can you clear your ClickOnce cache, that's everything under \apps\2.0, and try it again? Maybe it's a caching problem.

Let's talk basics:
What OS is the client machine running?
What version of .NET are you targeting -- it is .NET 3.5 or .NET 3.5 SP-1 ?
Are you using VS2008 or VS2010?
Are you publishing to a webserver or file share?
Are you publishing directly to the webserver or file share from Visual Studio, or doing it manually?
Do you have the MIME type set up correctly on your server?
    http://robindotnet.wordpress.com/2010/06/12/mime-types-for-clickonce-deployment/

RobinDotNet

---

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

We have ran it on XP and Windows 7.

Targeting .NET3.5 SP-1

VS2010

Publishing to a webserver ( publish folder and installation folder are different)

The MIME types are set up correctly.

Clearing the cache did not fix the problem.

Answer 40

Here is a quick side question that is related to creating the shortcuts. Is there a way to configure  setup.exe so it does not launch the app after installing prereqs? In other words, the app can only be launched from the .application file.

 

Thanks for your help,

Answer 41

No, there isn't. However, you should know that it launches the app by calling the .application file.

RobinDotNet

---

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