news:1139351681.921737.118790@f14g2000cwb.googlegroups.com...
> 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.
>

news:1139371451.747841.272100@z14g2000cwz.googlegroups.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.
>

news:1139373787.050324.180300@g43g2000cwa.googlegroups.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.
>

"Julie Lerman" <jler***@thedatafarm.com> wrote in message
news:Oqx415KLGHA.2912@tk2msftngp13.phx.gbl...
> 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
>
> <Michael.Sua***@gmail.com> wrote in message
> news:1139373787.050324.180300@g43g2000cwa.googlegroups.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.
>>
>
>

news:1139425829.279983.282850@g14g2000cwa.googlegroups.com...
> 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
>

"Michael.Sua***@gmail.com" wrote:

> 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
>
>

"Michael.Sua***@gmail.com" wrote:

> "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?
>
>

"Michael.Sua***@gmail.com" wrote:

> 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.
>
>