Questions about .NET Deployment Models (i.e. ClickOnce)

  • Thread starter Thread starter Michael.Suarez
  • Start date Start date
M

Michael.Suarez

We are currently in the process of making the switch from VB6 to .NET
at my company. Currently, all of our VB6 executables reside on a
network drive and everyone has a shortcut on their desktop to the each
of the programs on the network. There are a few DLL's that are common
to most of the apps. The most recent copy of each DLL is copied to and
registered on each computer at startup via a login script.

Deployment of new program versions and new DLL's is easy for us, as it
is simply a matter of dropping the files into their appropriate folders
on the network. If someone requires a version of a dll newer than the
one they have, they simply restart their computer.

As we move into C# and .Net i want to get a feel for what all of our
options are.

For example, we can probably start keeping the .NET versions of our
DLL's on the network drive and do away with the login script.

The problem is with doing this is, you can't overwrite a file that is
in use. If I drop a file on the network (whether it is an exe or a dll)
and someone is utilizing that file on their own machine, then windows
won't allow me to overwrite a file in use.

Currently if I am putting out a new version of a program, I either have
to wait til later at night when noone is using the program, or if only
people whose desks are around me are logged on, ask them all to log off
for a sec while I put out a new version. But it can be a real pain in
cases where someone on the other side of the floor is logged on and
away from their desk (or worse, has left the office for the day).

So basically what I am asking is, with all of the new technologies
available to .net, does anyone have any suggestions for a more robust
and simple to maintain deployment model?

I read about clickonce deployment, but that promotes a completely
different model than what we currently implement, whereby everyone has
their own local copy of the program, and it checks the deployment
server for a new version behind the scenes, downloads it, and starts
using it...

If i tried to implement clickonce, but still kept the copy of the exe
on the network, would I still run into the same issue of windows not
allowing an overwrite, or does it know how to avoid this?

Any help or advice would be greatly appreciated.
 
Michael

I am a someone who has used VB4/5/6 for many years, still maintains some big
(for me) VB6 apps and has been working with .NET for 4 years , currently
deploying .NET 2.0 apps. I also know a LOT of developers. I just want to
make sure you know that I am not talking out of my *** here, but from a
background of almost 20 years as a professional developer.

I need that preface due to my next sentence...

Though I'm sure this is not a unique scenario, I have never actually heard
of a VB exe being used in this way. And I not only don't recommend it, I
would strongly discourage it. (Even if you said to me "but it's working just
great! Why fix it if it ain't broke?" :-) )

Anyway, it does sound like you are moving away from that and hoping to
install at least the exe's on the client machines. If you want to leave the
dll's on the network, you are talking about using remoting or (my personal
favorite) web services. Remoting is a bear to learn and Microsoft is moving
away from that model as they move towards Indigo (WCF). THey will still
support remoting and indigo will work with it, but the recommendation is not
to start new remoting projects. Web Services means exposing the goo in the
assemblies through asmx/http. Not really worth doing on an intranet, unless
you plan to deploy client apps outside of the intranet. This is the model
that I use.

I would highly recommend that you embrace the model that ClickOnce will make
very simple for you to deploy applications over the intranet. You can very
easily drop your updates on to the server and the client apps, as you
already described, will discover and install them. ClickOnce supports
versioning. Each time you want to update an assembly, you create a new
version folder and that's what you put on the server. You don't have to
overwrite the other folder.

If you are in a scenario where you have few enough users that your vb6 exe
on the network share is working, I'm sure you can probably use the default
wizardry of click once very nicely.

I have been working with .NET 2.0 since Nov 2003 but only now am I beating
on ClickOnce. My personal frustrations with it are due to the fact that I
want to use it outside of windows authentication. But within a network, it
is great.

Julie Lerman
www.thedatafarm.com
 
Thanks Julie. I appreciate the feedback.

I understand that our method of deployment is a little unorthodox, but
can you offer any reasons as to why you'd reccomend changing it? We
must have about 50 executables out there on our network drive, but some
are important to some people and others aren't. Some aren't even meant
to be standalone apps, but rather are called from a button click of
another program. Requiring people to have to have all of their exe's
local would be tricky, and seems like it would require all of the
executables to implement clickonce. We plan on having all of the apps
rewritten in c# and .net, but it's surely going to be a slow transition
and taking this approach would mean that until all of the apps are
rewritten we will have some that implement clickonce and some that
don't which might also be confusing.

So moving to a model where everyone has all of their executables local
isn't the most attractive option right now. But i am not entirely
against it either. I would just need some really good reasons to go
through with it. I obviously need to do some more research to come up
with a lot of reasons for (or against) moving from what we do to
clickonce, but i'd love to hear any additional reasons you'd be willing
to offer.

When i say dll's on the network, i am not talking about remoting or web
services. I simply mean dropping a dll on the network drive.
Referencing it in my project, and not having to deal with using the
login script to push new dlls to the users. You couldnt just do that in
VB6 because all the dlls also had to be in the registry of every
individual user (which occurs in the login script).

I agree that web services are cool. But for our environment (60 people,
all in the same building on the same floor) it would probably be
overkill.

I like the idea of clickonce deployment, but i think i need more
convincing as to why our current way is so bad. The one downside, which
i mentioned in the OP is the fact that I have to kick everyone off to
make an update. I guess what I have to determine is, if that is a big
enough downside to convert everything to clickonce. Which is why any
further insight would be greatly appreciated.

btw... has 2.0 been out since nov. 2003? i was under the impression
that 2.0 was brand new to VS 2005, which just came out a couple months
ago.
 
She's probably recommending against that because she missed the part which
states it's only the deployment method (and that the user is actually not
using the DLL in the shared folder, only the deployment/login script does!)

Anyway using click once should work just well in your case!

--
Regards,
Lloyd Dupont

NovaMind development team
NovaMind Software
Mind Mapping Software
<www.nova-mind.com>
 
"she missed the part which states it's only the deployment method (and
that the user is actually not using the DLL in the shared folder, only
the deployment/login script does!) "

oh man, maybe i'm not explaining myself correctly.
the login script does not use the dll. It distributes it. Everytime
someone restarts their computer, a batch program (which i am refering
to as the login script) takes all of the newest versions of all of our
in-house dlls, and puts them onto the users hard drive and registers
them.

In .Net, what i would like to do is put our new dll's (.net rewrites of
our old dll's) on the network drive, create references to them in my
projects, and then put the a[[s utilizing these dlls on the network
drive as well.
 
"she missed the part which states it's only the deployment method (and
that the user is actually not using the DLL in the shared folder, only
the deployment/login script does!) "

oh man, maybe i'm not explaining myself correctly.
the login script does not use the dll. It distributes it. Everytime
Click to expand...
now scores at even, it's what I meant too ;-)
In .Net, what i would like to do is put our new dll's (.net rewrites of
our old dll's) on the network drive, create references to them in my
projects, and then put the a[[s utilizing these dlls on the network
drive as well.
Click to expand...
look at that:
http://channel9.msdn.com/ShowPost.aspx?PostID=15303
http://channel9.msdn.com/wiki/default.aspx/Channel9.ClickOnce

http://msdn.microsoft.com/smartclient/understanding/windowsforms/2.0/features/clickonce.aspx
http://msdn.microsoft.com/vbasic/learning/clickonce/
http://msdn.microsoft.com/msdnmag/issues/04/05/ClickOnce/
 
Oh man, ME! Not your explanation!!!

I even read it twice because I just couldn't believe it. And still missed
it. I'm really sorry. I shouldn't do that so late at night.

So, just for a good laugh for you (I owe you that much, right?).. that's how
I do my vb6 updates.

FYI - there is a way to customize ClickOnce to do things like "only deploy
THESE bits to this permission group" etc. It's more work - and I don't know
how to do it (yet), but I know it can be done.

julie
 
"so late at night" ummm 6pm? Okay, I guess I shouldn't do this in the
morning before I drink my coffee either.

More on specifiying who gets what assemblies - I saw a reference to this in
a ClickOnce session at TechEd 2005 done by Patrick Daragh. He talked about
the concept - you actually define users/roles and which assemblies they get
in a database table and then dynamically build a manifest - but did not demo
it. It sounds daunting, but I have an email into him asking if there are any
resources that demonstrate how to do this.

ClickOnce out of the box is great for HelloWorld apps but we have to work a
little harder to solve our real needs.

julie

Julie Lerman said:
Oh man, ME! Not your explanation!!!

I even read it twice because I just couldn't believe it. And still missed
it. I'm really sorry. I shouldn't do that so late at night.

So, just for a good laugh for you (I owe you that much, right?).. that's
how I do my vb6 updates.

FYI - there is a way to customize ClickOnce to do things like "only deploy
THESE bits to this permission group" etc. It's more work - and I don't
know how to do it (yet), but I know it can be done.

julie

"she missed the part which states it's only the deployment method (and
that the user is actually not using the DLL in the shared folder, only
the deployment/login script does!) "

oh man, maybe i'm not explaining myself correctly.
the login script does not use the dll. It distributes it. Everytime
someone restarts their computer, a batch program (which i am refering
to as the login script) takes all of the newest versions of all of our
in-house dlls, and puts them onto the users hard drive and registers
them.

In .Net, what i would like to do is put our new dll's (.net rewrites of
our old dll's) on the network drive, create references to them in my
projects, and then put the a[[s utilizing these dlls on the network
drive as well.
Click to expand...
Click to expand...
 
Thanks again for the responses.

Lloyd, that video from the first link you sent is great... really. He
shows how easy it is to implement ClickOnce. And after watching the
video, it really allowed me to go ahead and play around with ClickOnce
myself. The one thing that turned me off about ClickOnce was the idea
of forcing everyone to install the program locally. I liked the idea of
having all of the executables on 1 spot on the network. But after
playing around with it, I realized how I can maintain the idea of
keeping it all on the network and use clickonce, basically answering my
own question.

So as it stands now, with all of our exe's on the network drive, if
someone has an exe open and I try to overwrite it, windows doesnt allow
it, forcing me to kick everyone off if i want to make an update. Now,
with clickonce, if i answer the question "will this application be
available offline?" and I select No, it will put the
program.application file on the network. Now I just have a shortcut to
the .application file on everyones desktop (instead of a shortcut to
the .exe on the network). When a user clicks the shortcut, the
..application finds the latest version and launches it! So when I
publish a new version, it doesn't matter if people are using the
program or not. It still writes the new executable to the network, in a
different folder, and the next time someone clicks the .application
file, they will be routed to the latest version of the program.

Problem solved! I get the best of both worlds.

The other advantage of keeping it all on the network is this: We have a
lot of mini apps that are launched from bigger apps. To the user, they
dont know they are running a seperate executable... to the user it
looks like they just opened up another form in the same program. The
cool thing about doing this is that different people can be working on
different parts of the same program at the same time. All they need to
do is a shell launch of the executable on the menu click event of the
bigger program. My concern with clickonce was, what if you create a new
mini-app and put a shell execute for it in the bigger app, the user
will have to first install the mini app in order for that shell command
to work. But now, knowing I can still keep it all on the network, I can
just put a shell execute command on the .application file on the
network, and I know it is going to be there. Awesome!

The only other thing I have to figure out now is where all of the DLL's
go. If i can keep them on the network, or if those have to go on
everyones individual machine and whatnot.

Julie, the thing you mentioned sounds interesting. I'd be interested to
see what kind of response you get.

Thanks,

Mike
 
great news. This is why they have been working on making deployment easier.

re: the dll's. In a simple clickonce model, they get deployed with the app
and you don't have to think about it. Otherwise, as far as I know, you would
have to use .NET Remoting to leave the dlls on a server. In my first email,
I talked a little about that. I've never used .NET remoting and have no
plans to, so I won't go any further in explaining it.

I'll post back when I hear back from Patrick.

julie
 
Michael,

If all of the client machines are at Windows 2000 or better then you do not
have to kick everyone off. Just rename the the exe file on the server and
copy the new version to it, that way the next time the client starts the
application they get the latest version (Win98 is another problem).

With dotnet you can still leave the exe on the server with a shortcut to it
 
"Just rename the the exe file on the server and
copy the new version to it, that way the next time the client starts
the
application they get the latest version"

WOW.
I can't believe I never thought of this. But your right... I just tried
it and it works fine. If only I knew that all along.

But I still think I am going to use ClickOnce the way I described. The
only difference is that a shortcut to a file automatically uses that
file's icon. The exe has the correct icon. The .application file does
not. Anyone know of a way to get the .application file to, as a
default, have the exe's icon?
 
Go to the Project properties and click on the Applcation tab and you find
that you can choose what icon (.ico file) to use.
 
Yeah.. I've already done that... that assigns the icon to the
executable, but not the .application file.
It would be great if there were a way to assign an icon to the
..application file so that i could have all shortcuts to the
..application file automatically assume that icon.
 
If you do the ClickOnce the setup routine will install a shortcut on the
Program menu with your Icon on it. Then you can copy and paste from the
Program menu to your desktop and the icon will showup there.

Otherwise don't do the ClickOnce deployment, instead just copy everything in
your BIN folder to a folder on the server and then make a shortcut to that
location.
 
yeah, i see what you are saying.

but clickonce has 2 options. When you are asked "will this application
be available offline?" you can answer yes or no. answering yes is
forcing the user to dl the app locally. When chosing that option, then
the shortcut does get added for you. But i select no, keeping
everything on the network and not requiring a local install. And then I
will have a shortcut on everyone's desktop to the .application file on
the network. If i could somehow get this .applaction file to assume the
icon of the exe, I'd be thrilled... otherwise I could just change it
manually.

I understand that what i am doing is very similar to just dropping
everything into a shared folder on the network and creating a shortcut
to the exe... however, using clickonce instead has some nice
advantages.. ie: you get to keep all versions out on the network in
case you need to backtrack, and you dont have to do that thing that you
suggested where you rename the exe before dropping the new one in.
Using clickonce literally requires one click.. so that's what makes the
most sense to me. If not having the .application file's icon assume the
..exe's icon is the 1 drawback, then so be it, i'll change the icon for
the shortcut manually. But it would sure be nice if there were a way to
get that to happen autmatically.
 
Back
Top