Advanced ClickOnce Question

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi

I have a rather advanced deployment scenario and wanted to know, if anyone
has an idea how to accomplish that with ClickOnce:

We are deploying a 3-tier application with a client connecting to web
services, which then connect to a database. The tiers are all on different
nodes and we have around 1000 client users. We currently deploy the web
services with Wise and adjust the database (cluster) manually. The clients
should be deployed with either No-touch or ClickOnce, as our customer is not
able to manually install the application on the client computers.

No-touch soon proved too rigid, as it apparently only loads assemblies that
are linked/referenced to each other, but our client uses CAB and is highly
decoupled. There are no direct references to some of the assemblies.

So ClickOnce seemed to do the job, but we then came across two difficulties
which we do not know how to solve properly:

1. Our solution is installed on several servers, most importantly for
internal and external users (DMZ), so the web services are found at different
urls by different users. The url to use is read from the app.config file.
Without ClickOnce, we could set that url at install time (when installing a
"template" version on the server that gets copied to the test clients
manually). Now that ClickOnce computes a hash over the app.config file, we
can't change it after compilation...

2. The ClickOnce manifest contains the url where the application is to be
downloaded from. Now, as I layed out above, we have different users that
should get the application from different urls. But as ClickOnce needs the
manifest to be signed, we can't change that value after compilation...

So the obvious solution is to provide different client applications, ready
for ClickOnce deployment and one per configuration (in our case, that would
currently result in 4 versions). But this approach means that everytime the
customer wants to deploy the solution on a different server, we need to
rebuild and ship something.

Can anyone think of a more elegant solution?

Alex
 
Can anyone think of a more elegant solution?

1) Maybe you can program these URLs into the program. Which means,
that you know the target Webservice URL e.g. from the clients
IP-Adress or Hostname. So no settings in App.Config is
necessary.

2) You don't have do build it 4 times, only make a short script,
that copies the app.config into 4 different folders and
automatically signs and zips/mails/ftps the applications.
The first setup is more work, but afterwards you don't have
to care about, if there are 4 or 5 distributed versions.

3) You make a drop-down field on the login-screen, where the
client choses its location. Not fool-proved, but make sure,
that the last settings are stored and after starting it the
first time, users will manage it.

4) You make one public webservice, that everybody can reach. This
tells the client at the first startup (depending on ip-address,
client settings or username) to which webservices he must
connect. This is also only necessary on the first startup and
will be remembered on the local computer for the next starts.

hope to give you some ideas you didn't think about yet.

Markus
 
I created a similar deployment to what you are describing. The company
where I work sells a very complex piece of software that has been
migrated over to dotnet. In order to use the ClickOnce method of
deployment but retain control over what gets downloaded for the
application, I created a deployment that is essentially a bootstrapper
for our application. After it's on the client and running we then do
the necessary downloads and launch the application in it's own
AppDomain. In doing this we've gotten around the gotchas you mentioned
below. With dotnet the additional work in putting together code to
download the necessary files is minimal.

Hope that helps.
 
Back
Top