Click Once vs Server Deployment

[SetonSoftware]

I inherited a VB/C# 2005 application that has a 6.1 MB EXE and a few
support DLLs. There are about 60 users in one office who use it plus
a
few who access it via Remote Desktop. We currently deploy changes to
the application via Click Once. I'd like to do the following.

1. Break up the EXE into one 200K menu application that launches
objects in about 2 dozen DLLs of 500K each

2. Eliminate Click Once entirely and deploy changes by droppping new
DLLs onto the server.

Re Click Once: I can see the advantage for deployment when there are
many more users who spread over a larger region. In addition, you can
at least deploy a new verion with requiring all the users to exit the
program. What other benefits would I gain/lose by dropping Click Once
and going to server deployment?


Thanks


Carl

 

[Rich P]

Hi Carl,

I believe Click Once is technically a server deployment, and I have used
it for deploying updates to .dll's. I am guessing that you want to be
able to overwrite files on the server.

To launch an app from Click Once you would do something like:

Dim p1 As Process = System.Diagnostics.Process.Start("C:\Documents and
settings\yourPersonalfolder\start
menu\programs\yourCommonFolder\yourApp.appref-ms")

where the Click Once shortcut extension is ".appref-ms"

As for breaking up your app into smaller pieces - I have done something
similar - but the pieces ended up being individual standalone apps that
I could call from the master app (your Menu app) where I would call the
shortcuts as above (using the appref-ms thing). This ended up being
kind of redundant because since each app was standalone - it would have
its own shortcut.

I can't think of any gains by not using Click Once for deployment.



Rich

 

[Carl Ganz]

Hi Carl,

I believe Click Once is technically a server deployment, and I have used
it for deploying updates to .dll's.  I am guessing that you want to be
able to overwrite files on the server.

To launch an app from Click Once you would do something like:

Dim p1 As Process = System.Diagnostics.Process.Start("C:\Documents and
settings\yourPersonalfolder\start
menu\programs\yourCommonFolder\yourApp.appref-ms")

where the Click Once shortcut extension is ".appref-ms"

As for breaking up your app into smaller pieces - I have done something
similar - but the pieces ended up being individual standalone apps that
I could call from the master app (your Menu app) where I would call the
shortcuts as above (using the appref-ms thing).  This ended up being
kind of redundant because since each app was standalone - it would have
its own shortcut.

I can't think of any gains by not using Click Once for deployment.

Rich

*** Sent via Developersdexhttp://www.developersdex.com***

Rich

Thanks for your feedback. By "server deployment" I mean dropping files
on a shared network directory rather than us ClickOnce so the users
can pull the binaries local. This would make rushing changes into
production very easy on our end. Once a change was made, we drop the
DLL on the sharedd drive and we're done.

What do you think?

Thanks

Carl

 

[Rich P]

It sounds like you want users to use the same program off the server?
With Click Once the people sort of get an individual copy of the app
which they use locally. You deploy the app/updates to the server and
the Click Once shortcut will automatically download whatever updates you
deploy. If you are trying to get users to all use the same app off the
server - I don't really have enough experience with multi sharing to
offer good advice. I just have somewhat of an understanding how Click
once works. I am an individual app user kind of programmer guy. I
think with a multi user system you have to add multi threading. This
would be getting a little out of my league at this time.

Rich

 

[J.B. Moreno]

1. Break up the EXE into one 200K menu application that launches
objects in about 2 dozen DLLs of 500K each

Why?

You're just complicating your deployment -- not by a lot of course, but
why do so at all?

Bandwidth is the major advantage of piece-meal deployment, and if your
users are going to be running it off of share that would only matter if
there was a significant portion of the application that wasn't used by
each user (and even then, given today's corporate internal networks,
the size of your exe is unlikely to be large enough to worry about).