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.

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

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

Jonathan Wood wrote:

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/is...a/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.

--
Göran Andersson
_____
http://www.guffa.com

[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

"Jonathan Wood" <jw***@softcirc uits.comwrote in message
news:%2******** ********@TK2MSF TNGP05.phx.gbl. ..

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.

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

[Carl Daniel [VC++ MVP]]

Jonathan Wood wrote:

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,

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

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

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

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
"pedrito" <pixbypedrito at yahoo.comwrote in message
news:Io******** *************** *******@giganew s.com...

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

"Jonathan Wood" <jw***@softcirc uits.comwrote in message
news:%2******** ********@TK2MSF TNGP05.phx.gbl. ..

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

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

[Jon Skeet [C# MVP]]

Jonathan Wood <jw***@softcirc uits.comwrote:

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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[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.
"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:MP******** *************@m snews.microsoft .com...

Jonathan Wood <jw***@softcirc uits.comwrote:

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

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[pedrito]

"Jonathan Wood" <jw***@softcirc uits.comwrote in message
news:uu******** ******@TK2MSFTN GP03.phx.gbl...

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.

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,

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

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
SoftCircuits Programming
http://www.softcircuits.com