Dave Burke : Freelance .NET Web Developer specializing in Online Communities

A few post-ClickOnce deployment observations

I released the first beta of my Smart Client app on the HQ network yesterday remoting in over VPN.  My system admin went to the ClickOnce deployment page, clicked on the INSTALL button to install the .NET Framework 2.0 on his machine.  This process was on the slow side, even with the framework available on the local app ClickOnce website, but we are talking over 90MBs of framework, so that's expected.  It prompted for a reboot, which he did, and on startup it automatically proceeded to install my Smart Client app.  Nice.

ClickOnce created a shortcut to the app and program folders in the Start Menu.  He fired-up the app, it hit the web service, grabbed some data to create the clientside dataset, and dang if it didn't display in all its glory, functioning exactly as it does here.  I'll have to say that this was a singularly satisfying moment for me as a developer.  Oh, I experience pleasure in my work every day, but moments of tangible satisfaction in having accomplished something, no, not very often.  Listening to my system admin at HQ describe the first version of my first Smart Client app as it ran on his machine was a real feeling of accomplishment.  Or maybe the feeling was the release of my anxieties wondering if it was really going to work or not.

So now that it does and the app is running on select users' desktops, the real work begins.  But first a few follow-up ClickOnce observations.

1) ClickOnce does not create a standard application folder under "Application Data" by company/app/version as an .MSI does.  Instead it creates a new /apps subdirectory and wierd-ass directories under it.  I was looking for the dataset and other files I knew the app created and stored clientside.  I found them here.

C:\Documents and Settings\dburke\Local Settings\
Apps\Data\91A59NVB.N3E\OC1PJMO5.GHJ\
wins..tion_401287f9b5ed6594_0001.0000_249b47c6ed474c15\Data

Hey, the app works, so I'll just pass along the info for now until I get a clue.

2) I don't think the ClickOnce Security Settings as part of the publish process do anything.  Believe me, I've published over 30 times in the span of a few hours, with various settings, and I'm pretty sure the Security tab in VS.NET have no effect on the installed application.  Of course, you have to sign all code via Trusted Publisher Certificate which I described previously, so its not like the app isn't secure, I just don't think these settings do anything.

3) Every time you publish the app, the version is automatically incremented. 1.0.0.XXX.  You can set this manually, as well.  The Published Version is independent of the Application Version set in AssemblyInfo.  I have an "ABOUT" form which appears and currently displays the Application Version.  I want to figure out how to display the Published Version while the app is in development, and will blog on it when I figure it out.

 

Comments (11) | Post RSS RSS comment feed

Posted on 7/21/2005 9:56:00 AM by Dave Burke
Categories: .NET
Tags:

Related posts

Comments (11) -

7/21/2005 5:58:32 PM Permalink

Hey Dave,

What does your code look like that saves the DataSet out to the ClickOnce "Data" folder?

Does it use Environment.SpecialFolder.ApplicationData to "locate" that folder? Or some other method?

My application has a bunch of files ('skin' templates) that I'm currently looking for in (and deploying to) a subfolder beneath the exe. It sounds like it would be more logical to flag those files as "Data" in the solution, and look for them there instead. I just need to know how to locate that folder in code.

Matt

mabster |

7/21/2005 6:02:42 PM Permalink

Mabsterman, I'm using Application.UserAppDataPath + "\\" + myfilename

daveburke |

7/21/2005 6:13:54 PM Permalink

That's interesting. That's the *roaming* Application Data folder - "C:\Documents and Settings\username\Application Data" as opposed to "C:\Documents and Settings\username\Local Settings\Application Data".

So applications deployed ClickOnce return the ClickOnce application cache's "Data" folder for that application when you use UserAppDataPath?

I'll have to play around with this. Hopefully any files I deploy that are flagged as data will end up in there.

I may yet end up deploying this app as a zip file Smile

mabster |

7/21/2005 6:21:58 PM Permalink

Ha!  Funny.  Installation is one thing, updates are another... Smile

daveburke |

7/21/2005 6:47:05 PM Permalink

Yeah, the auto-update mechanism is just too enticing to pass-up.

Deploying a freeware application that can open & save files and drag images down from user-specified URLs, though ... with the restrictions imposed by ClickOnce when being installed from the Internet ... this is tricky stuff for me.

mabster |

8/26/2005 4:24:01 PM Permalink

To get to the ClickOnce data directory you should use the ApplicationDeployment.DataDirectory property in System.Deployment.Application namespace. See msdn2.microsoft.com/.../ms136953(en-us,vs.80).aspx. Files marked as "Data" at publish time are put into this folder.

Use the ClickOnce data directory for all application data files that you plan on modifying at runtime post deployment. This typically would include app settings. This directory is deleted when app is uninstalled so for any user data files such as word docs that need to be preserved use "My Documents" or other similar location.

MSDN link on this topic - msdn2.microsoft.com/.../d8saf4wy(en-us,vs.80).aspx.

Sameer Bhangar |

8/26/2005 7:52:23 PM Permalink

Sameer,  That's excellent stuff!  I'll definitely use it.  Thank you.

daveburke |

1/18/2006 12:55:13 PM Permalink

ApplicationDeployment.CurrentDeployment.CurrentVersion is what you were looking for. I would still be happier if somehow AssemblyVersions and DeploymentVersions could be kept in sync. Anyways, I can remove the revision from the AssemblyVersion, user DeploymentVersion programmatically and increment major and minor versions manually in both places.

I am shocked at the directory stucture too ;)

RGab |

1/18/2006 1:01:51 PM Permalink

RGab, I'll remember that.  I have to dig deeper into ClickOnce before the app I'm working on gets real, so thanks for the info.  Did I use the word "shocked" when referring to the directory structure?  If not, I should've.  Funny!

daveburke |

2/15/2006 9:52:04 AM Permalink

Does anyone know why I can install a clickonce application running on my network but when I try and install it from a machine outside of my network it fails? The errors range from the application is improperly formatted to "The application download  did not succeed, check your connection". This is a major problem as I need to deploy this app for my university coursework. Any pointers would be great

Jon

Jon |

2/15/2006 10:08:09 AM Permalink

Jon,  I have NEVER had a deployment problem that was not adequately described in the error log which the clickonce process generates.  I haven't had an error in a while so I forget whether its one-click accessible with the error (which I THINK it is), or stored in the deployment folder.  Sounds like you're dealing with a classic permissions/domain/trust issue.  I'm confident that log file will give you the pointer you'll need to solve it.  Cheers!

daveburke |


Powered by BlogEngine.NET 2.0.0.36
Theme by Dave Burke