http://blogs.msdn.com/mwade/archive/2008/08/29/what-s-new-in-visuall-studio-2008-sp1-clickonce-tooling.aspxHere is a post I've been meaning to do for a while, but avoided because there is some MSDN info on it. But a recent question to the forums made me think that maybe it was time to talk about things that were not addressed in the document: what's reallyenCommunityServer 2.1 SP1 (Build: 61025.2)http://blogs.msdn.com/mwade/archive/2008/08/29/what-s-new-in-visuall-studio-2008-sp1-clickonce-tooling.aspx#8947488Fri, 12 Sep 2008 20:09:22 GMT91d46819-8472-40ad-a661-2c78acb4018c:8947488Matthew<p>Could you elaborate on the practical use of optional hashing?</p> <p>Thanks,</p> <p>Matthew </p> http://blogs.msdn.com/mwade/archive/2008/08/29/what-s-new-in-visuall-studio-2008-sp1-clickonce-tooling.aspx#8953079Mon, 15 Sep 2008 23:52:57 GMT91d46819-8472-40ad-a661-2c78acb4018c:8953079mwade<P>Matthew,</P> <P>Note: this is mostly conjecture on my part; as part of the tooling team, we aren't always told WHY a feature is done, we are just told that customers have requested a ClickOnce specific feature, and we need to allow for it to be done within Visual Studio.</P> <P>I think the main goal of optional hashing is to allow an enterprise to set application-specific properties during deployment that are not known at development time. The primary group that was getting targeted here was an independent software vendor who is creating a ClickOnce solution that it wants to sell to enterprises. The canonical example is the database connection string that gets written into an application.config file. There are certainly more, but I think that's the biggie. </P> <P>The ISV gives the manifests and application files to an enterprise, tells them to update the config file, stick the files on a share, and they should be up and running. </P> <P>Without optional hashing, the enterprise (or more likely, the ISV)) would be required to:</P> <P>- Update the config file</P> <P>- Calculate the hash of the config file</P> <P>- Update the application manifest to have the new config file hash (changing the app manifest)</P> <P>- Update the deploy manifest to account for the new app manifest hash</P> <P>- Sign the deploy and application manifests.</P> <P>There is an article on MSDN for the ClickOnce and ISV scenario ("<A class="" href="http://msdn.microsoft.com/en-us/library/bb384248.aspx" target=_blank>Creating ClickOnce Applications for Others to Deploy"</A>) that could be updated to account for optional hashing. But there's probably tons of content on MSDN that needs to be updated post 3.5 SP1.</P> <P>Also, I updated the post a little bit in the optional signing part. If a file is not getting hashed, the manifests should not be signed. In this case, an initial publish from Visual Studio will not turn on signing. Therefore there is no need to publish twice to get signing turned off, which is one way to interpret what was originally written. Hopefully I get that across a little better now.</P>