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



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


<Michael.Suarez@xxxxxxxxx> wrote in message
news:1139351681.921737.118790@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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.



.



Relevant Pages

  • Re: ClickOnce application parameters
    ... The only way to pass parameters to a ClickOnce ... Note that the deployment ... Shameless Book Plug: Learning MSBuild and ClickOnce ... in a network share directory? ...
    (microsoft.public.dotnet.framework)
  • Re: J2ME or network programming or...what do you recommend?
    ... It was more 'J2EE' I was thinking of in my ... offers network connections to other places, ... OK - J2ME apps. ... thin client GUI - so there is ...
    (comp.lang.java.programmer)
  • Re: OS deployment feature pack
    ... When doing an in-place deployment, ... When the USMT runs locally is there a default ... >> State Capture and State Restore phase respectively. ... >> the network or require you to configure servers with appropriate security ...
    (microsoft.public.sms.tools)
  • Re: OS deployment feature pack
    ... When doing an in-place deployment, ... When the USMT runs locally is there a default ... >> State Capture and State Restore phase respectively. ... >> the network or require you to configure servers with appropriate security ...
    (microsoft.public.sms.admin)
  • Re: VFP open table corruption
    ... backup and audit trail, but I'm scared of it happening again. ... Just never seen any corruption that comprehensive before. ... everything went nuts - apps crashing everywhere. ... The network is having a few problems I admit, ...
    (microsoft.public.fox.programmer.exchange)

Quantcast