I’m having a fair amount of trouble with ClickOnce, now I’m actually using it. I’m researching how updates can be user initiated. Some problems are simply solved be restarting Visual Studio 2005. One problem however is a bit less obvious.
UpdateLocation
It’s real easy to reproduce the error. Create a new project, preferably a Windows Application. Now add a new reference to System.Deployment and add the following using statement to your form.
using System.Deployment.Application;
Add a button to the new form, double click it and add the following code.
if (ApplicationDeployment.IsNetworkDeployed)
{
ApplicationDeployment appDeploy = ApplicationDeployment.CurrentDeployment;
if (appDeploy.CheckForUpdate())
{
MessageBox.Show("Updating app, when done, I'll restart.");
appDeploy.Update();
Application.Restart();
}
}
Now go to your project properties, to the Publish tab and choose the Updates button. Then disable the “The application should check for updates” checkbox. This way, we can specify when the application should update ourselves.
Now publish the application, install it from the webpage and it’ll run automatically. Press the button and you’ll be presented with a great dialog box, but not our own!
Application cannot be updated programmatically unless the deployment manifest includes the <deploymentProvider> element.
That’s the error you’ll be presented with. To fix it, go to the publish tab in your project configuration again, press the Updates button and specify an update location. This location should only be specified if the publish location is different, but specify the exact same location, publish, install via web page, run the app and press the button again. You’ll see your problem is fixed.
In another post I’ll talk a bit more about security issues in ClickOnce, as this puzzled me a bit as well. Although there’s extensive documentation, most just lightly touched the subject I wanted more info about.
A while ago I gave a presentation, called “An introduction into the TDD Mantra”. The occasion was a technical meeting with some colleagues, to whom I wanted to introduce at least the principles behind Test-Driven Development.
A lot of people think TDD is the same as writing unit tests,
but it is not. That’s why I wanted to explain it to people. Dan Bunea also has an article about it
right here, and it seems he’ll continue this with more stories about how to do it.
My presentation slides are a more high level introduction with some statements that should trigger people to start thinking about Test-Driven Development. The part I liked most was the part where I wrote an application live, using TDD of course. You might recognize it as Robert ‘Uncle Bob’ C. Martin’s
Bowling Kata. I ‘translated’ it into C# with
an accompanying document to check if you’re doing it right. It seems Uncle Bob has done it hundreds of times over the years, I’ve done it 7 times or so now. Not once completely without errors. But that’s not bad, it’s fun to solve these in front of a live audience. And they’re just minor errors.
I also try to explain what Dependency Injection is, with some examples in code. Then a nice bridge to legacy software, in which I ask what legacy software is. It concludes with a great statement from (a colleague from) Michael Feathers, and that you should start writing unit tests immediatly, doing it the right way with Test-Driven Development.
Update: Fixed the broken links