ansaurus

Question

Answer 1

+5 A:

Just build the library once, and reference the compiled binary from your project that needs to use it.

In visual studio, right click on the project and click "add reference", then choose the "browse" tab and locate your libraries binary.

(You will obviously need to distribute the library assembly along with your application)

Simon P Stevens 2010-02-28 12:20:40

Thanks. I can't believe I've missed something so fundamental, after years of working in Visual Studio.

Bryan 2010-02-28 12:24:45

Not sure this is the best answer. Adding a binary means that if the shared project changes then you'll need to recompile it and then recompile all dependant solutions that reference it which could lead to build dependency issues. I'd suggest adding it as a project reference instead

zebrabox 2010-02-28 12:33:17

@zebrabox: I don't follow, Is this not exactly what Simon's post stated?

Bryan 2010-02-28 12:37:36

@Bryan. No Simon's solution involves adding a reference to the binary - I'm suggesting using a project reference and adding a reference to the source csproj

zebrabox 2010-02-28 12:42:16

@zebrabox: the problem starts when you need to reference this project in several other solutions. You really don't want to copy the source around. View shared libraries as just another "third party" dll. Would you include the .Net Framework source with every project? No, you reference a stable, specific version of the shared dlls.

Peter Lillevold 2010-02-28 12:43:30

@zebrabox, ah okay, but there isn't an answer that describes the method you suggest.

Bryan 2010-02-28 12:46:07

@Peter - You don't have to copy the source around. Just add the source csproj to your solution then add that csproj as a project reference - no source files get copied anywhere it's just a link into your sln. Maybe I'm misunderstanding something

zebrabox 2010-02-28 13:03:39

+1 binary dll reference. A project reference assumes that you always want to include any source code changes to the library in the main project. Consider versioning the library in source control (along with the release dll) when you need to update the library, branch it and make sure you update the version number in assembly. This way a given project can utilise a given version of library dll. Downside of this of course is a critical bug is found in library v.1 and you have v.2 v.3 etc you might have to replicate the fix in multiple branches and update the apps that reference them.

Jason Roberts 2010-02-28 13:04:12

@zebrabox: What you are suggesting is a good alternative way of doing things. Like Jason says, it has the drawback of lack of versioning, but it all depends on what you are trying to achieve. In some circumstances, a project reference might be exactly what you need. We actually use both in our source tree, we reference binary libraries when versioning needs to be strict and stable, but we also have shared components that are built separately with each app for the bits that are more fluid.

Simon P Stevens 2010-02-28 13:16:36

@Simon P Stevens -Yes you are spot on. It all depends on what you are trying to achieve. For what I could see from the OPs question then project references seemed to be a good flexible solution. Project references are not a 'golden bullet' and we also use a mix-n-match approach as you describe, depends on what the requirements are

zebrabox 2010-02-28 13:59:53

Thanks all for the answers and comments. It's been an interesting read for me, and I now have a way forward.

Bryan 2010-02-28 14:21:32

Answer 2

+1 A:

I would suggest compiling your library into a dll which can be added as a reference to any other project you are working on. Then you don't need to copy the source files everywhere.

Ray 2010-02-28 12:21:23

Answer 3

+2 A:

Your feeling is absolutely right. There should be only one master of the library source.

In our shop we have several shared library projects used by several products. We view these libraries as products themselves and treat them accordingly. Specifically, when a project needs one of these libraries we put a compiled version of the library in a lib folder in the project. We remove the need to copy the source around, and our project only references a stable copy of the dll.

Here's a sample structure in the repository

/LibraryX            <- product root
   ../branches
   ../tags
   ../trunk          <- solution folder
       ../LibraryX   <- project folder
       ../lib        <- thirdparty libraries used by LibraryX

/ProductY            <- product root
   ../branches
   ../tags
   ../trunk          <- solution folder
       ../ProductY   <- project folder
       ../lib        <- thirdparty libraries 
                        used by ProductY, e.g. a copy of LibraryX.dll

So, in the ProductY project, rather than including a copy of the LibraryY project you add a reference to the LibraryX.dll located in the lib folder.

Peter Lillevold 2010-02-28 12:22:48

That's exactly the structure I'm aiming for. Many thanks.

Bryan 2010-02-28 12:32:02

Answer 4

+1 A:

You should just build a dll with your library and then just reference to it..

References > Add Reference in VS.

J. Vermeire 2010-02-28 12:23:05

Answer 5

A:

Demystifying the .NET Global Assembly Cache

Paul Creasey 2010-02-28 12:23:56

The GAC is not a solution to avoid chaos in source code repositories.

Peter Lillevold 2010-02-28 12:29:51

ansaurus

tags:

views:

answers:

Methods of managing source code

related questions