During our dev phase of a large client app, we were very successfully using ClickOnce to deploy test instances etc etc internally.
We are now supplying our clients with a signed package (which would be quite normal), but there is a major pitfall that appears to have no workaround. The config file needs to be edited by them to set connection strings etc etc. This breaks the signing, they then have to send the manifest to us to resign, and then they sign the application package with their self generated cert (which is actually done via a script so it is easy for them).
Most of the environments we deploy to will require the package to be signed. And most of our clients are fussy and unhelpful, so minimal intervention by them is key, not suprsingly.
We would have to do this signing "fiasco" for every instance (usually production and UAT) in every client (several hundred currently) for every upgrade (every 1-2 months). I am sure anybody can see that this is quite an overhead!
- Is there a way to allow the config file to be edited without breaking the signing? - this would be logical and ideal, even if it had to be sign the file by their self gereated cert.
- Include a "config file" that is excluded from the checksum, but still part of thae package?
- Would it be possible for the client app to know/find out where the update location is (and therefore get a config file from the same dir)? I can physically read the update location from the shortcut that is created in Program Files, but that doesn't mean my client app can read that, of course. This still might not work due to local policy restricting access, but may be a workable option...
If (1) isn't possible then that would seem a major failing for ClickOnce in the real world of commerce, spoiling what is otherwise a "perfect" deployment mechansim, especially as a server DB Upgrade nearly always requires an updated client app to be delivered at the same time!
Any help or ideas would be cool...and I cannot believe this has been brought up before regarding external deployment, but I found no real evidence of this in any docs or previous posts...!
Welcome to the MSDN Forum.
I think to sign the clickonce, a trusted publisher is must. Have a look at the follows article on MSDN and I think it will help you to resolve the issue. There are some solutions in it[Especially the paragraph: Trusted Publishers and ClickOnce Application Signing 101]:
Configuring ClickOnce Trusted Publishers:
If you have any questions, please feel free to tell us.
Neddy Ren [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Thanks Neddy, sorry for taking so long to reply.
I feel I have exhausted all avenues, spending many hours on MSDN and the web, and still not come up with anything workable, either for us or our customers, I still must be missing something!
Our client app exe.config must be edited by the customer prior to deployment, mainly for connection strings, and as such the manifest currently needs re signing by us, every client, for every upgrade (relatively frequent). This is an absolute horror for both the customer and us as a small company. Also, we cannot expect our customers to have excessive downtime while this resigning process takes place (which will happen as every upgrade to the server app, will involve a new clickonce client app to be published).
If the customer signs the manifest themselves, will they not need a trusted publisher certificate, and will the app then loose it's identity (ie our company as the publisher)? Our cert was purchased purely for deployment purposes and obviously puts our company name in the pop-up on initial install (which is a desired state) - otherwise why would even bother to have a trusted publisher cert ourselves? Also, if our customers have to pay for a trusted publisher cert, that will put our smaller clients out of reach. And without a trusted publisher cert, all seems not right on install without additional administrative headache.
Ideally, in a future incarnation of clickonce I would want to, as a developer, mark several files as "modifiable", which would still have to signed by a customer self generated cert to be valid (part of the self signing part), but still preserve our "stamp".
This config modification requirement must be a very common issue with external customers and clickonce deployments?
I have considered wrinting a secure webservice to do this signing, but that seems like a massive pain in itself to make secure and I'm not sure we would even want our publisher cert anywhere near a public webserver.
The only other thing I can think of would be to somehow get a "config file" from the server that the package was installed from, containing the settings that would need changing, but is there a way I can get the original install location (ie the webserver the app is installed from) from the client app once it has started up ? If this can be done, I think this is a solution to the problem - have all customer modifiable settings outside of clickonce completely...!