A simple class library question

[richard d]

Well - at least I hope it is

Having spent some time developing my c# application, using Visual
Studio 2005, I would now like to start re-factoring some of my code
into a class library so that I can use it in other applications I will
want to write and distribute (by which, BTW, I mean sell to a wide
audience).

Either I'm looking in the wrong book / help topic / whatever, or this
doesn't seem to be as easy as I would have liked.

I understand that I want to build a DLL, and that Visual Studio lets
me do that easily enough. I'm not sure how easy it will be to keep
both library and current application open at the same time so that I
can migrate code across - so I guess that's my first question.

Ideally, then, I should have some sort of distribution system for my
applications set up so that an app only uses the latest version of the
dll. In other words, if I distribute the DLL with app1 and app2, and
app2 has a more recent version of the DLL than app1, but app1 is
installed after app2, then the more recent DLL will not be over-
written. Is that when I need to stick the DLL in the GAC and start
looking at versioning?

Then there's the business of public/private key encoding, which
appears to me to be performed by a utility which presumably is getting
access to my company name from my PC? I mean, how does this tool (sn)
guarantee uniqeness? And should I bother with it.

Cheers

Richard

 

[Jon Skeet [C# MVP]]

I understand that I want to build a DLL, and that Visual Studio lets
me do that easily enough. I'm not sure how easy it will be to keep
both library and current application open at the same time so that I
can migrate code across - so I guess that's my first question.

The easiest way is to have the class library project in the same
solution as the application.

Ideally, then, I should have some sort of distribution system for my
applications set up so that an app only uses the latest version of the
dll. In other words, if I distribute the DLL with app1 and app2, and
app2 has a more recent version of the DLL than app1, but app1 is
installed after app2, then the more recent DLL will not be over-
written. Is that when I need to stick the DLL in the GAC and start
looking at versioning?

Personally I'd avoid using the GAC for this as it complicates things.
So long as app1 and app2 are installed in different directories, there
shouldn't be any issues.

Then there's the business of public/private key encoding, which
appears to me to be performed by a utility which presumably is getting
access to my company name from my PC? I mean, how does this tool (sn)
guarantee uniqeness? And should I bother with it.

Strong naming isn't about getting access to your company name - but
unless you actually *need* strong naming, I'd avoid it personally.
Life is *easier* in an unsigned world, although obviously there are
downsides too.

Jon

 

[richard d]

The easiest way is to have the class library project in the same
solution as the application.


Personally I'd avoid using the GAC for this as it complicates things.
So long as app1 and app2 are installed in different directories, there
shouldn't be any issues.


Strong naming isn't about getting access to your company name - but
unless you actually *need* strong naming, I'd avoid it personally.
Life is *easier* in an unsigned world, although obviously there are
downsides too.

Jon

Thank you for your answer, once again

Just on the business of the shared library between app1 and app2 - if
I install app2 after app1, how can I get app1 then to pick up the
updated library (now in app2's directory)?

Cheers

Richard

 

[Jon Skeet [C# MVP]]

Thank you for your answer, once again

Just on the business of the shared library between app1 and app2 - if
I install app2 after app1, how can I get app1 then to pick up the
updated library (now in app2's directory)?

You shouldn't - you may have some breaking changes, whether
deliberately or not. It's a much better idea to keep the library
effectively separate, IMO.

 

[richard d]

You shouldn't - you may have some breaking changes, whether
deliberately or not. It's a much better idea to keep the library
effectively separate, IMO.

Thank you once again.

One last question (for now )

Would you build both applications under the same solution? Or would
you have them as separate solutions but sharing the library project?

Cheers

Richard

 

[Jon Skeet [C# MVP]]

Thank you once again.

One last question (for now )

Would you build both applications under the same solution? Or would
you have them as separate solutions but sharing the library project?

That depends on how big they are and how independent they are. A single
solution often makes life easier - but I wouldn't share the library
project, I'd refer to the DLL if you have the two applications in
separate solutions. Sharing a project between solutions has
occasionally been a pain in my experience.

 

[Lasse Vågsæther Karlsen]

Thank you once again.

One last question (for now )

Would you build both applications under the same solution? Or would
you have them as separate solutions but sharing the library project?

Cheers

Richard

I can describe what I do personally.

I have my class library, a rather big one now, containing about 27
sub-projects with different categories of classes. These are in their
own right added to one big honking solution and added to Subversion.

In a project, where I need to use some of the class library projects,
but not all, I use Subversions externals support to make a solution
directory that have sub-directories containing "shared copies" of the
projects from the class library. This way I can easily modify both the
application project, as well as the individual class library projects.

Inside Subversion, only the solution folder + the application folder is
actually committed in one place, but the solution folder "knows" it
needs some sub-folders coming from a different place in source control,
and I can then easily grab a copy that can be compiled in total by itself.

With VisualSVN, addin for Visual Studio for Subversion support, this
works *almost* seamless. Only downside is that the class library
projects and the application project is not considered to be the same
"local working copy", so I can't do one commit and commit changes to
both my application project and the class library project in one go, but
that's it.

If, on the other hand, you're not using source control that allows for
such easy sharing of code, then I would probably keep the source control
solution in one place, open in one Visual Studio instance, and the
application project in another place, with references to the dlls, but I
would most likely make sure the application project has all it needs if
I just makes a copy of it to a new machine, so I would probably add a
directory where I would store binary copies of the class libraries, and
reference those, instead of having a relative reference from the
application project that reaches out outside the application project
folder and relies on explicit locations of the class library.

Not sure I made much sense here, but if not, and you want me to explain
something better, let me know.