General DLL Questions - Best Practices? Suggestions? Comments?

[Michael.Suarez]

So we develop and maintain several applications used by several people
in the same company, on the same intranet.

There are several applications written in VB6, but going forward all of
the new development will be done in .NET 2.0, including eventual
rewrites of all the VB6 apps.

The VB6 executables are all stored in a network folder, and everyone
accesses these exe's using shortcuts to them on their desktop. Going
forward, we will use clickonce, chosing "online only" and instead of
having shortcuts to the programname.exe file in the network folder, we
will have a shortcut to the programname.app lication file in the network
folder. Basically, I get the same effect of keeping everything on the
network, but the advantage is, i never have to worry about kicking
anyone off the program to update it (due to inability to overwrite
files in use). The .application file will redirect the user to the new
version and i can send an update with one menu click without having any
care whether people are using the program or not.

Currently all of our VB6 DLL's are deployed using a login script that
runs every time a user logs into windows, which basically takes a copy
of each dll from the network puts it in the users system32 folder and
runs regsvr32.exe for each dll. And my plan here is to find a new
..NETish way of doing this.

So there are 5 different types of dll's that will need to be taken into
consideration.
1) the old vb6 dll's that will continue to be relevant up until every
single vb6 app is rewritten.
2) the new .NET Dll's that will be utilized by the new .NET versions of
the applications.
these can be broken down into:
a) dll's that will be essential to all or most of our applications.
They contain objects and functions, but no visuals.
b) dll's that can be used by any number of applications that contains
custom controls... visuals, such as maybe a form that already includes
a menu with all of our standard menu options.
c) dll's that contain different portions of a single application and
will only be used by that application. The idea being that even though
you can create one big executable, if you instead broke it down to one
small executable and four small dlls, then launching the exe takes up
less memory and depending on what you are using the program for, the
user may only need to access just one or two of the four librarys,
keeping the cpu usage at a minimum.
3) dll's that were not created by anyone at our company, but are
essential in order for the program to run. Crystal report dll's.
Perhaps we buy a 3rd party datagrid or datawindow.

So finally, here is what I am looking for... just a simple solution to
adding/updating all of these 5 types of dll's. Ideally, I could just
drop all of the dll's in the some folder on the network and have all of
my future projects reference them directly, accessing them as they
stand on the network, and every time a dll of any of these 5 types of
dlls changes, I can simply overwrite them where they stand on the
network.

Unfortunately, it's not going to be that simple. I can't just overwrite
an old dll with a new dll if it is being shared on the network very
easily, because more than likely that dll is currently in use by
someone on some machine, and therefore can not be overwritten. Is there
a way of instead of making a reference to a dll directly, I make a
reference to something that points to the latest version of the dll
(sort of like how making a shortcut to the .application file opens up
the latest version of the executable)?

also, some other questions about things I've mentioned in this post.

1)the dll's described in type 1. I couldnt just put them on the network
the way I am describing regardless of the whole "overwritin g files in
use" dilemma. vb6 files need to be registered. So should I just
continue to let the login script update these until they are completely
fazed out? Or if there is some way of doing what I described in my last
paragraph, would it not care what type of dll it is?

2)The dll's I describe in type 2)b).. custom controls like forms or
components that belong on forms that are saved in a dll. Lets say I
make a reference to one of these dlls from one of my applications so i
can include a control that consists of 3 buttons and 3 text boxes all
on the same panel. Now I compile the program and update it. Now I
change my custom control so that instead of having 3 buttons and 3 text
boxes, it has 4 of each, and i made all the buttons blue. I re-build
the dll. Now I want my application to reflect the change in the
control. Does the application need to be recomplied? Or will
overwriting the old dll with the new one, and re-running the program be
good enough?

3) the dll's I describe in 2)c).. mini dlls specific to 1 app, that
exist solely for the purpose of keeping the exe small, hence having the
exe use less cpu. Is this even a good idea? or is it overkill?

4) I am also investigating the idea of using remoting or web services
instead of custom dll's, since i know they can easily be stored on a
server and do not need to be on each individual machine. I have some
good sites explaining the 2 of them, and the differences between the 2
of them. But it seems like a lot of work, and may be overkill for what
I am trying to accomplish. Is this a path worth exploring, or is the
answer much simpler?

5) As I said, ideally all of the dlls can be stored on the network, and
updating them will be as easy as putting new ones out there, whenever i
want, without minding whether the old ones are in use. However I am not
opposed, if it is simpler, to having the dll's get installed on each
machine... if it can be done with ease, automatically. I assume if this
is the correct solution, that I should be storing them all in the GAC.
However, I doubt i would bother strong-naming as I would keep all
versions of dll's backwards compatible. Any insight on this idea would
be great.

Any comments, suggestions, answers to any of the questions, no matter
how brief, or even if they are simply links to web sites with better
explanations of things will be greatly appreciated.

Converting to .NET is a big project, and I want to get it right from
the start.

Thanks in advance for any feedback.

Mike