home links tools blog about

AngryPets Blog

home

Monday, October 03, 2005

And no matter what you do: Dont...

Don't: Click on the Fonts and Colors Option in any of the VS tools if you're in a VPC/VM.

You'll have enough time to make a pithy blog post like this one...

posted 4:29 PM | Feedback (0)

ClickOnce: Changing the Deployment Server

ClickOnce is pretty spiffy. Really. At this point it looks like it will be a no-brainer in corporate environments, and I actually think it may be robust enough for small 'web shops' to actually push out to their clients as an admin tool etc. (assuming they either have the winforms curve down, or are willing to take the hit for the rich UI functionality (as opposed to taking the AJAX-buzzword route)).

But there are some security concerns that can make using it a _bit_ of a pain. For example, if you build and deploy your ClickOnce app against ServerA, and then later want to host it on ServerB, clients simply won't be able to pull down the files (or if they do'll, they'll be getting them from ServerA).

That's because ClickOnce makes sure that the signature of the application, found in the manifest, covers not just the bits, but the source of the bits. Frankly, that's awesome.

If you DO move the ClickOnce files from ServerX to ServerY (and, assuming that ServerX is no longer available), you'll encounter an error when you try to download the application. A check of the log accompanying the failed operation will say something like:

+ Downloading http://ServerX//.application did not succeed.
+ The remote name could not be resolved: 'ServerX'

In other words, even if you navigate out to http://serverY/someDir/publish.htm, the underlying manifest still lists ServerX as the place to grab the binaries, and check for updates, etc. In other words, it looks hard-coded.

Now, if you start playing around ini the application manifests that accompany your ClickOnce app, you'll find the <app_name>.application file, or manifest. It, happily, has something both juicy and promising: the deploymentProvider config node/element:

<deploymentprovider codebase="http://ServerX//.application" />

Looks like a quick change right? just change that to http://serverY/... and you're good to go. Only, you've just invalidated the signature of the application. So, to get around that, you'll need to run a spiffy little tool from MS, called the Manifest Generation and Editing Tool (or MAGE for short) - actually, there are two tools, mage.exe, and mageUI.exe. Either works, but mageUI.exe is obviously easier - and lets you change the above deployementprovider info, and when you click 'Save' it says: "Hold on there pardner' - your key is now pooched, would you like to regenerate it?" To which you can say: "Why thank-you, I'd love to..." Upon which it prompts you for the location of your .pfx key, etc. and regenerates your manifest, etc. Sure, you COULD do it all by hand... but the tool makes it all quite a bit easier.

(And as a word of note, it appears that mage.exe/mageui.exe don't ship with C#/VB.NET Express versions - they appear to only accompany VS 2005.)

Relevant Links:
- ClickOnce deployment: Manual Insanity
- ClickOnce: Signing Application and Deployment Manifests

posted 12:27 PM | Feedback (0)