Good way to "bundle" shared class code

[BobRoyAce]

I have an application that has a bunch of classes defined in it. There
are also a bunch of forms, user controls, etc.

Now, I am starting development of another application that will use
several, but not all, of the classes from the first application. I
don't want to maintain two copies of the classes...want to "share"
them between the two, and possibly future, applications.

What is a good way to facilitate something like this? Is there a way
that I can create a DLL, or something, of just the classes, and then
reference the DLL from the applications? Or, do I just put the
class .vb files in a common folder (already did this), and then add
the same files to both applications, with both pointing to the same
files?

I would appreciate direction on this, together with how-to for
whatever the proposed solution is.

 

[Herfried K. Wagner [MVP]]

I have an application that has a bunch of classes defined in it. There
are also a bunch of forms, user controls, etc.

Now, I am starting development of another application that will use
several, but not all, of the classes from the first application. I
don't want to maintain two copies of the classes...want to "share"
them between the two, and possibly future, applications.

What is a good way to facilitate something like this? Is there a way
that I can create a DLL, or something, of just the classes, and then
reference the DLL from the applications?

That's what I recommend. Just take a look at the class library project
template.

Or, do I just put the class .vb files in a common folder (already did
this), and then add
the same files to both applications, with both pointing to the same
files?

This would be possible too, but I would not recommend it. You can do that
by selecting the option to reference the file only instead of copying in the
dialog used to add a file to the project.

 

[Tom Shelton]

Both methods have value. The first, creating a DLL is really useful if your
code is well debugged and isn't likely to change. The drawback is that
you'll have more files to copy during installation. The latter, sharing the
code via references, is useful if you expect to be making changes to your
code or it's not well debugged. The drawback is that changes have to be
very carefully thought out while the advantage is that you only have a
single file to distribute.

Mike.

Packaging shared code as dll is really the better solution. And changes are
not a problem as long as you follow simple rules...

1) don't delete classes or remove methods ad hoc. If you need to remove
something, then do it in a controled fashion by marking the class/method as
obsolete. This will then show up as compiler warning in any project that uses
the method

2) if you need to add methods to an interface, don't alter the existing
inteface - create a new interface that inherits from the old:

Public Interface ISomeInterface
Public Sub FirstSub()
End Interface

Public Interface ISomeInterface2
Inherits ISomeInterface
Public Sub SecondSub()
End Interface

This way, you won't break older clients, and new clients can use the extend
functionality - by the way, the addition of the number is the MS recommended
naming convention...

Avoid using optional parameters with default values (at least for public
methods that are exposed to the outside world). These become part of the
interface, and if you then change the default value - you will break older
clients (unless the recompile). If you need optional arguments, favor method
overloading instead - besides, it will make any C# users who happen to might
wnat to use your library happy becase C# doesn't support optional arugments
and it results in messy code to use methods that have them

Adding methods to a base clas or a class or adding additional classes etc is
almost never a problem