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

Re: Sharing Code

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]

Re: Sharing Code

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" <jwood@softcirc uits.comwrote in message
news:%23fOHu2e4 HHA.3940@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]]

Re: Sharing Code

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]

Re: Sharing Code

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]

Re: Sharing Code

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:Ioednc0mnr _1G1rbnZ2dnUVZ_ uygnZ2d@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" <jwood@softcirc uits.comwrote in message
news:%23fOHu2e4 HHA.3940@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]]

Re: Sharing Code

Jonathan Wood <jwood@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 - <skeet@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]

Re: Sharing Code

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]" <skeet@pobox.co mwrote in message
news:MPG.2131f5 02814acf443c3@m snews.microsoft .com...

Jonathan Wood <jwood@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 - <skeet@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]

Re: Sharing Code

"Jonathan Wood" <jwood@softcirc uits.comwrote in message
news:uuoQ7Ri4HH A.3716@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]

Re: Sharing Code

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

[Jonathan Wood]

Re: Sharing Code

Please see my reply to Jon Skeet.

--
Jonathan Wood
SoftCircuits Programming

http://www.softcircuits.com

"pedrito" <pixbypedrito at yahoo.comwrote in message
news:QoOdndcFde 4N9lXbnZ2dnUVZ_ jKdnZ2d@giganew s.com...

"Jonathan Wood" <jwood@softcirc uits.comwrote in message
news:uuoQ7Ri4HH A.3716@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.
>

[Jon Skeet [C# MVP]]

Re: Sharing Code

Jonathan Wood <jwood@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?

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

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.

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.

2) You can replace that version very easily

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

3) You don't need any extra setup steps

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

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.

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

--
Jon Skeet - <skeet@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

[Jonathan Wood]

Re: Sharing Code

Jon,

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

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

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

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

http://www.softcircuits.com

[Jonathan Wood]

Re: Sharing Code

Smithers,

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

What I've been describing is referencing the *same* DLL from several
applications, which are running only on my desktop BTW.

What distribution are you referring to?

--
Jonathan Wood
SoftCircuits Programming

http://www.softcircuits.com

[J.B. Moreno]

Re: Sharing Code

In article <OsCsNVo4HHA.44 76@TK2MSFTNGP06 .phx.gbl>,
Jonathan Wood <jwood@softcirc uits.comwrote:

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.

When deciding to how to use/distribute a library, you need to look at
your situation and determine what your needs are.

Decide the things you want to happen, and how important they are...what
trade off as are you willing to make, what aren't you willing to do
without....

And there will be your answer as to what to do....

--
J.B. Moreno