Sharing Code

[Jonathan Wood]

Greetings,

I'd like to write any number of classes and then use those classes from any
number of .NET applications.

Since we've supposedly left "DLL Hell" and ActiveX objects behind, what has
taken it's place.

Can anyone point me in the right direction getting started learning the best
way to write a library of routines and then being able to access those
routines from several different .NET applications?

Thanks.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Greetings,

I'd like to write any number of classes and then use those classes from
any number of .NET applications.

Since we've supposedly left "DLL Hell" and ActiveX objects behind, what
has taken it's place.

We are still using dll files. We just left most of the hellish parts of
it behind us.

For example:

Avoiding DLL Hell: Introducing Application Metadata in the Microsoft
..NET Framework
http://msdn.microsoft.com/msdnmag/issues/1000/metadata/default.aspx

Can anyone point me in the right direction getting started learning the
best way to write a library of routines and then being able to access
those routines from several different .NET applications?

Create a Class Library project and put some classes in it. You can
either compile this and use the dll file produced, or add the project to
any solution.

 

[pedrito]

It's a piece of cake. You basically create a "Class Library" project. That
will create a DLL. All your classes will be in one or more namespaces that
you create inside that DLL.

In projects that use that library, you simply add a reference to the DLL in
your project.

Let's say you have the namespace MyLib and the class MyClass in it.

You then create an application. In your application project, you'll
reference MyLib.dll

In your code, you'll do something like this:

using MyLib;

void SomeMethod()
{
MyClass myClass = new MyClass();
}

And that's all there is to it, really. Couldn't be much simpler.

You simply deploy a copy of the DLL in the same directory as your
application.

Thing can get more complex. You can start getting into signed applications
and versioning issues, but for the most part, it's pretty easy.

Pete

 

[Carl Daniel [VC++ MVP]]

Greetings,

I'd like to write any number of classes and then use those classes
from any number of .NET applications.

Since we've supposedly left "DLL Hell" and ActiveX objects behind,
what has taken it's place.

Can anyone point me in the right direction getting started learning
the best way to write a library of routines and then being able to
access those routines from several different .NET applications?

You put them in DLLs. This doesn't result in "DLL Hell" because such DLLs
are then generally deployed "app local" - in the applications 'bin'
directory, rather than in some silly place like %systemroot%.

-cd

 

[Jonathan Wood]

Carl,

You put them in DLLs. This doesn't result in "DLL Hell" because such DLLs
are then generally deployed "app local" - in the applications 'bin'
directory, rather than in some silly place like %systemroot%.

That wouldn't work very well if I was using the lib from several different
applications. Either I'd need to put all the applications in the same
directory, or I'd need store multiple copies of the DLL.

 

[Jonathan Wood]

Yep, I tried that and it worked fine. That was easy. Although, the idea of
copying shared libraries to a subfolder of each application that uses the
libraries is definitely out.

Thanks.

 

[Jon Skeet [C# MVP]]

Yep, I tried that and it worked fine. That was easy. Although, the idea of
copying shared libraries to a subfolder of each application that uses the
libraries is definitely out.

Why? It has distinct advantages:

1) It's really obvious which version of the library you're using
2) You can replace that version very easily
3) You don't need any extra setup steps

You *can* use the GAC for all of this, but in my view that makes it
easier to fall into versioning problems again. It's all do-able in
theory, but it's easy to make mistakes.

 

[Smithers]

RE:
<< Either I'd need to put all the applications in the same directory, or I'd
need store multiple copies of the DLL >>

The 3rd option, as others have pointed out, is to install to the GAC (global
assembly cache) - which is intended for such purposes.

If you don't want to go to the GAC, then storing multiple copies of the DLL
would probably be the easiest way to have multiple apps using [copies of] a
particular DLL. If you find the idea of having multiple copies to be a
problem, then whatever those reasons are - they would likely be addressed by
going to the GAC.

So it breaks down like this:

1. "I'm too lazy to install to the GAC" ---> then go with multiple copies;
one per app
2. "I don't want multiple copies because I don't want multiple versions
floating around beyond my knowledge" ---> then go to the GAC
3. Multiple apps in same folder to "share" a DLL is just plain rediculous.
4. You could revert to COM, but then you get DLL hell again.
5. In your App.config file, use the codebase and/or probing elements to
specify one common assembly location (for your shared DLLs) - see
[http://msdn2.microsoft.com/en-us/library/4191fzwb(VS.71).aspx] for more.
This might end up being akin to creating your own GAC, with the additional
maintenance and documentation overhead of going outside of well-known GAC or
XCopy deployment options.

Those are pretty much your options.

-S

 

[pedrito]

Jon (as usual), is right about this. You're going to make your life harder
if you use the GAC.

In my personal and professional experience (I work on a very large scale
commercial .NET based app), it is much easier to simply ship the proper
version with the app and keep them together in the same folder. I've never
found a reason to use the GAC.

The whole idea of "DLL hell" was based on the problem of multiple apps
wanting to use different versions of the same DLLs in the Windows/System32
folder, and using the GAC is just relocating the problem. Granted, the GAC
allows multiple versions to co-exist, but it's still more problematic than
just keeping the DLLs with the app.

 

[pedrito]

Carl,


That wouldn't work very well if I was using the lib from several different
applications. Either I'd need to put all the applications in the same
directory, or I'd need store multiple copies of the DLL.

Can you explain to us why this wouldn't work? Just curious. You seem pretty
convinced this is a problem, but maybe you're seeing problems where problems
don't exist. If you can tell us why that won't work, maybe we can understand
a little better what the problem is.

 

[Jonathan Wood]

Jon,

Why?

At least for in-house libraries, think about what happens when you fix
something in the library. You now need to update all those copies. I guess
it's just a matter of a spending a little time copying the file as long as
you have an always-current list of every application that uses each library,
but I prefer not to have to track that kind of thing. It is definitely more
error prone and can raise issues when you find out one of the applications
isn't using the latest fixes.

1) It's really obvious which version of the library you're using

It's more obvious if every application on your computer is referencing the
same DLL.

2) You can replace that version very easily

It's easier to only replace it in one location.

3) You don't need any extra setup steps

Obviously, my take is a little different on this.

You *can* use the GAC for all of this, but in my view that makes it
easier to fall into versioning problems again. It's all do-able in
theory, but it's easy to make mistakes.

The types of versioning issues typical with so-called DLL Hell have not
really been an issue for me using my own libraries. It's definitely
something to at least consider with libraries you plan to distribute widely.

Thanks.

 

[Jonathan Wood]

Please see my reply to Jon Skeet.

 

[Jonathan Wood]

Thanks for the info.

Personally, I don't consider using COM for .NET applications or putting all
my applications that use a particular library in the same folder viable
options.

I'm not familiar with the "GAC" but will research it further.

As I indicated elsewhere, I can see wanting to stick the library in the same
folder as the application for libraries that receive wide distribution. But,
for in-house stuff, I don't like that approach.

I'll also check out that MS link you provided.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

RE:
<< Either I'd need to put all the applications in the same directory, or
I'd need store multiple copies of the DLL >>

The 3rd option, as others have pointed out, is to install to the GAC
(global assembly cache) - which is intended for such purposes.

If you don't want to go to the GAC, then storing multiple copies of the
DLL would probably be the easiest way to have multiple apps using [copies
of] a particular DLL. If you find the idea of having multiple copies to be
a problem, then whatever those reasons are - they would likely be
addressed by going to the GAC.

So it breaks down like this:

1. "I'm too lazy to install to the GAC" ---> then go with multiple
copies; one per app
2. "I don't want multiple copies because I don't want multiple versions
floating around beyond my knowledge" ---> then go to the GAC
3. Multiple apps in same folder to "share" a DLL is just plain
rediculous.
4. You could revert to COM, but then you get DLL hell again.
5. In your App.config file, use the codebase and/or probing elements to
specify one common assembly location (for your shared DLLs) - see
[http://msdn2.microsoft.com/en-us/library/4191fzwb(VS.71).aspx] for more.
This might end up being akin to creating your own GAC, with the additional
maintenance and documentation overhead of going outside of well-known GAC
or XCopy deployment options.

Those are pretty much your options.

-S

Carl,


That wouldn't work very well if I was using the lib from several
different applications. Either I'd need to put all the applications in
the same directory, or I'd need store multiple copies of the DLL.

 

[Smithers]

I have read your other posts in this thread. Based on your apparent concerns
and desires, I think the obvious answer for you is to install to the global
assembly cache (GAC). That's what it's for (sharing one .dll amongst
multiple apps).

The GAC gives you something very much like what you had in the COM world
where you'd copy a file to one central location (typically \System32) and
then register the dll (ala RegSvr32). The GAC gives you the logical
equivalent of \System32 , with the added benefit of [possibly] having
multiple versions of a given .dll in the cache at the same time - with
different applications targeting different versions of the .dll if
necessary. Arguably you that should be avoided - but if you need that
capability, at least you have the option - which you did not have in the COM
world.

You'll have to give your assemblies a strong name, etc. So it's more work
than simply copying a .dll to \System32 and running regsvr32.exe to register
it. This extra work is why many people avoid the GAC altogether. A simple
cost/benefit analysis frequently results in the conclusion that it's just
not worth the effort (to go to the GAC)... whereas in COM you really had no
choice as COM .dlls were NOT self-describing (whereas .NET assemblies are
self-describing) and had to be registered even for one application to make
use of them.

-S

Thanks for the info.

Personally, I don't consider using COM for .NET applications or putting
all my applications that use a particular library in the same folder
viable options.

I'm not familiar with the "GAC" but will research it further.

As I indicated elsewhere, I can see wanting to stick the library in the
same folder as the application for libraries that receive wide
distribution. But, for in-house stuff, I don't like that approach.

I'll also check out that MS link you provided.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

RE:
<< Either I'd need to put all the applications in the same directory, or
I'd need store multiple copies of the DLL >>

The 3rd option, as others have pointed out, is to install to the GAC
(global assembly cache) - which is intended for such purposes.

If you don't want to go to the GAC, then storing multiple copies of the
DLL would probably be the easiest way to have multiple apps using [copies
of] a particular DLL. If you find the idea of having multiple copies to
be a problem, then whatever those reasons are - they would likely be
addressed by going to the GAC.

So it breaks down like this:

1. "I'm too lazy to install to the GAC" ---> then go with multiple
copies; one per app
2. "I don't want multiple copies because I don't want multiple versions
floating around beyond my knowledge" ---> then go to the GAC
3. Multiple apps in same folder to "share" a DLL is just plain
rediculous.
4. You could revert to COM, but then you get DLL hell again.
5. In your App.config file, use the codebase and/or probing elements to
specify one common assembly location (for your shared DLLs) - see
[http://msdn2.microsoft.com/en-us/library/4191fzwb(VS.71).aspx] for more.
This might end up being akin to creating your own GAC, with the
additional maintenance and documentation overhead of going outside of
well-known GAC or XCopy deployment options.

Those are pretty much your options.

-S

Carl,

Can anyone point me in the right direction getting started learning
the best way to write a library of routines and then being able to
access those routines from several different .NET applications?

You put them in DLLs. This doesn't result in "DLL Hell" because such
DLLs are then generally deployed "app local" - in the applications
'bin' directory, rather than in some silly place like %systemroot%.

That wouldn't work very well if I was using the lib from several
different applications. Either I'd need to put all the applications in
the same directory, or I'd need store multiple copies of the DLL.

 

[Jon Skeet [C# MVP]]

At least for in-house libraries, think about what happens when you fix
something in the library. You now need to update all those copies.

Indeed. However, think about the alternative: you want to introduce a
change in one copy of the library and *only* have it affect a single
application; or you want to introduce it to different applications
gradually, as you become more confident in it. You can only do this by
either using different versions and the GAC, or using a separate copy
of the file for each application. The latter is easier.

I guess
it's just a matter of a spending a little time copying the file as long as
you have an always-current list of every application that uses each library,
but I prefer not to have to track that kind of thing. It is definitely more
error prone and can raise issues when you find out one of the applications
isn't using the latest fixes.

I prefer fine-grained control over what gets upgraded to blindly
applying a change to everything on the system.

It's more obvious if every application on your computer is referencing the
same DLL.

Nope - you still need to find it in the GAC. If it's sitting there in
the same directory as the application, I fail to see how any
alternative is easier.

It's easier to only replace it in one location.

Yes - which is often far more desirable than the risky business of
applying it to all applications arbitrarily.

Obviously, my take is a little different on this.

So you think that installing something in the GAC is easier than
copying a file? If you take an application that *solely* consists of a
few files, you can do xcopy deployment. You can't do that if you need
to install stuff in the GAC.

The types of versioning issues typical with so-called DLL Hell have not
really been an issue for me using my own libraries. It's definitely
something to at least consider with libraries you plan to distribute widely.

If you choose to ignore a problem which has been so common that it's
got a nickname, that's your call of course.

 

[Jonathan Wood]

Jon,

Indeed. However, think about the alternative: you want to introduce a
change in one copy of the library and *only* have it affect a single
application; or you want to introduce it to different applications
gradually, as you become more confident in it. You can only do this by
either using different versions and the GAC, or using a separate copy
of the file for each application. The latter is easier.

For those cases that you cite, yes. They would be very rare cases for me,
however,

Nope - you still need to find it in the GAC. If it's sitting there in
the same directory as the application, I fail to see how any
alternative is easier.

I haven't yet looked into this GAC. So far, I simply followed the steps that
someone suggest of referencing the DLL. If I do that with all applications,
then updating or fixing the DLL will require exactly zero steps to ensure
all applications are upgraded to the new version. That is easier than any
scenario you've described.

I think about in-house library files I've used in the past. The biggest
issue I run into is upgrading the library and then making sure every
application uses the newest version. On the other hand, in the 20 years I've
been programming, I've yet to have any backwards compatibility issues when
any library I've ever released. I understand the issues concerning DLL
conflicts. But for me, particularly for in-house stuff, only one of these
issues is a concern.

If you choose to ignore a problem which has been so common that it's
got a nickname, that's your call of course.

If you get defensive, you may choose to put down my position by suggesting
I'm simply ignoring the problem. I've acknowledged the position you've taken
but fail to see how that really matters with in-house applications in the
very rare (in my case, never) instances where they would arise. From my
perspective, what I'm doing is addressing the very problems that my
experience had taught me I'm likely to run into.

 

[Jonathan Wood]

Thanks for the additional info regarding the GAC. I'll look into that
further. However, for right now my main concern is simply a
credit-card-gateway library I just wrote that will be used by a couple of
applications running on my desktop. In the immediate future, I'll probably
just add references to the DLL.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

I have read your other posts in this thread. Based on your apparent
concerns and desires, I think the obvious answer for you is to install to
the global assembly cache (GAC). That's what it's for (sharing one .dll
amongst multiple apps).

The GAC gives you something very much like what you had in the COM world
where you'd copy a file to one central location (typically \System32) and
then register the dll (ala RegSvr32). The GAC gives you the logical
equivalent of \System32 , with the added benefit of [possibly] having
multiple versions of a given .dll in the cache at the same time - with
different applications targeting different versions of the .dll if
necessary. Arguably you that should be avoided - but if you need that
capability, at least you have the option - which you did not have in the
COM world.

You'll have to give your assemblies a strong name, etc. So it's more work
than simply copying a .dll to \System32 and running regsvr32.exe to
register it. This extra work is why many people avoid the GAC altogether.
A simple cost/benefit analysis frequently results in the conclusion that
it's just not worth the effort (to go to the GAC)... whereas in COM you
really had no choice as COM .dlls were NOT self-describing (whereas .NET
assemblies are self-describing) and had to be registered even for one
application to make use of them.

-S

Thanks for the info.

Personally, I don't consider using COM for .NET applications or putting
all my applications that use a particular library in the same folder
viable options.

I'm not familiar with the "GAC" but will research it further.

As I indicated elsewhere, I can see wanting to stick the library in the
same folder as the application for libraries that receive wide
distribution. But, for in-house stuff, I don't like that approach.

I'll also check out that MS link you provided.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

RE:
<< Either I'd need to put all the applications in the same directory, or
I'd need store multiple copies of the DLL >>

The 3rd option, as others have pointed out, is to install to the GAC
(global assembly cache) - which is intended for such purposes.

If you don't want to go to the GAC, then storing multiple copies of the
DLL would probably be the easiest way to have multiple apps using
[copies of] a particular DLL. If you find the idea of having multiple
copies to be a problem, then whatever those reasons are - they would
likely be addressed by going to the GAC.

So it breaks down like this:

1. "I'm too lazy to install to the GAC" ---> then go with multiple
copies; one per app
2. "I don't want multiple copies because I don't want multiple versions
floating around beyond my knowledge" ---> then go to the GAC
3. Multiple apps in same folder to "share" a DLL is just plain
rediculous.
4. You could revert to COM, but then you get DLL hell again.
5. In your App.config file, use the codebase and/or probing elements to
specify one common assembly location (for your shared DLLs) - see
[http://msdn2.microsoft.com/en-us/library/4191fzwb(VS.71).aspx] for
more. This might end up being akin to creating your own GAC, with the
additional maintenance and documentation overhead of going outside of
well-known GAC or XCopy deployment options.

Those are pretty much your options.

-S




Carl,

Can anyone point me in the right direction getting started learning
the best way to write a library of routines and then being able to
access those routines from several different .NET applications?

You put them in DLLs. This doesn't result in "DLL Hell" because such
DLLs are then generally deployed "app local" - in the applications
'bin' directory, rather than in some silly place like %systemroot%.

That wouldn't work very well if I was using the lib from several
different applications. Either I'd need to put all the applications in
the same directory, or I'd need store multiple copies of the DLL.

 

[GlennDoten]

You'll have to give your assemblies a strong name, etc. So it's more work
than simply copying a .dll to \System32 and running regsvr32.exe to register
it. This extra work is why many people avoid the GAC altogether. A simple
cost/benefit analysis frequently results in the conclusion that it's just
not worth the effort (to go to the GAC)... whereas in COM you really had no
choice as COM .dlls were NOT self-describing (whereas .NET assemblies are
self-describing) and had to be registered even for one application to make
use of them.

I would argue that running regsvr32.exe and all that stuff is much more
difficult than signing an assembly. It takes, what, 10 seconds to run
sn.exe to get a key file and then maybe 30 seconds to edit your
project's AssemblyInfo.cs file to add the reference to the key file to
it? (If you are using VS'05 it's even easier since the application
properties window has a GUI button to browse to your key file.) That's
it. I don't think that expending the time on a cost benefit analysis to
decide whether to sign an assembly or not makes any sense.

What I promote is sign every assembly you create. You run sn.exe once to
get a key file. Whenever you create a project you reference this key
file in it. What could be simpler? The reason I say sign everything is
that the real question to me is why not sign an assembly (especially
given that it takes no effort)? You never know when you will need to put
that assembly into the GAC, like what the OP may want to do to share the
one assembly across applications, or you may start using a tool like
BizTalk which requires all your assemblies to be signed. Further, it's
just good practice to sign your assemblies. It shows who created them
and you know that an assembly with your signature is the one you
distributed or otherwise made available for other people/applications to
use.

Since around 1999 or 2000 when I started to get heavily into .NET I've
signed every single assembly that I've created. I even sign the test
assemblies I used to use in NUnit and now use in VS 05's testing
capabilities. (You never know when you might want to send a test suite
to a client. And I've written applications where some or all of the test
assemblies are distributed with the application so that a sort of system
test can be performed on a client computer.)

Anyhow, just sign your assemblies. Another major reason for doing this
is that in order for a signed assembly to reference another assembly,
that other assembly must also be signed. So if you distribute (or
otherwise make available) an assembly that is not signed then you will
impact any users of that assembly that want to sign their assembly.
(Although a nice workaround for this is to simply disassembly such an
assembly to it's IL source, add the signing directive to the top, then
reassemble it. Works perfectly when necessary.)

I'd love to hear reasons why it would ever make sense not to sign an
assembly.

 

[Jon Skeet [C# MVP]]

Anyhow, just sign your assemblies. Another major reason for doing this
is that in order for a signed assembly to reference another assembly,
that other assembly must also be signed.

I'd love to hear reasons why it would ever make sense not to sign an
assembly.

You've just provided the reason yourself. *Everything* has to be
signed. Not just your own code, but anything else you use.

It doesn't take *no* effort to sign an assembly. Is it *fairly* quick?
Yes. That's not the same as *no* effort. One you've signed your
production assembly, you're *forced* to sign your unit test assembly if
you want to use InternalsVisibleToAttribute.

These are all significant costs in my view. I'll sign an assembly when
I really need to, but I try to avoid it otherwise.

 

[Smithers]

RE:
<< I'll probably just add references to the DLL >>

How does that satisfy any of your complaints about distributing multiple
copies of the .dll with each application? The [reference each dll thing] is
a Visual Studio deal, if I"m understanding you correctly. If so, then you
still have not *distributed* a single copy of the dll that all apps then
share. You will end up distributing one copy of the dll per app.

You still need the GAC as the installation destination.

-S

Thanks for the additional info regarding the GAC. I'll look into that
further. However, for right now my main concern is simply a
credit-card-gateway library I just wrote that will be used by a couple of
applications running on my desktop. In the immediate future, I'll probably
just add references to the DLL.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

I have read your other posts in this thread. Based on your apparent
concerns and desires, I think the obvious answer for you is to install to
the global assembly cache (GAC). That's what it's for (sharing one .dll
amongst multiple apps).

The GAC gives you something very much like what you had in the COM world
where you'd copy a file to one central location (typically \System32) and
then register the dll (ala RegSvr32). The GAC gives you the logical
equivalent of \System32 , with the added benefit of [possibly] having
multiple versions of a given .dll in the cache at the same time - with
different applications targeting different versions of the .dll if
necessary. Arguably you that should be avoided - but if you need that
capability, at least you have the option - which you did not have in the
COM world.

You'll have to give your assemblies a strong name, etc. So it's more work
than simply copying a .dll to \System32 and running regsvr32.exe to
register it. This extra work is why many people avoid the GAC altogether.
A simple cost/benefit analysis frequently results in the conclusion that
it's just not worth the effort (to go to the GAC)... whereas in COM you
really had no choice as COM .dlls were NOT self-describing (whereas .NET
assemblies are self-describing) and had to be registered even for one
application to make use of them.

-S

Thanks for the info.

Personally, I don't consider using COM for .NET applications or putting
all my applications that use a particular library in the same folder
viable options.

I'm not familiar with the "GAC" but will research it further.

As I indicated elsewhere, I can see wanting to stick the library in the
same folder as the application for libraries that receive wide
distribution. But, for in-house stuff, I don't like that approach.

I'll also check out that MS link you provided.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

RE:
<< Either I'd need to put all the applications in the same directory,
or I'd need store multiple copies of the DLL >>

The 3rd option, as others have pointed out, is to install to the GAC
(global assembly cache) - which is intended for such purposes.

If you don't want to go to the GAC, then storing multiple copies of the
DLL would probably be the easiest way to have multiple apps using
[copies of] a particular DLL. If you find the idea of having multiple
copies to be a problem, then whatever those reasons are - they would
likely be addressed by going to the GAC.

So it breaks down like this:

1. "I'm too lazy to install to the GAC" ---> then go with multiple
copies; one per app
2. "I don't want multiple copies because I don't want multiple
versions floating around beyond my knowledge" ---> then go to the GAC
3. Multiple apps in same folder to "share" a DLL is just plain
rediculous.
4. You could revert to COM, but then you get DLL hell again.
5. In your App.config file, use the codebase and/or probing elements
to specify one common assembly location (for your shared DLLs) - see
[http://msdn2.microsoft.com/en-us/library/4191fzwb(VS.71).aspx] for
more. This might end up being akin to creating your own GAC, with the
additional maintenance and documentation overhead of going outside of
well-known GAC or XCopy deployment options.

Those are pretty much your options.

-S




Carl,

Can anyone point me in the right direction getting started learning
the best way to write a library of routines and then being able to
access those routines from several different .NET applications?

You put them in DLLs. This doesn't result in "DLL Hell" because such
DLLs are then generally deployed "app local" - in the applications
'bin' directory, rather than in some silly place like %systemroot%.

That wouldn't work very well if I was using the lib from several
different applications. Either I'd need to put all the applications in
the same directory, or I'd need store multiple copies of the DLL.