Referencing your other assemblies in projects

[Dave Anson]

What is the recommended practice for referencing assemblies in a project
from other solutions?

I am using Visual Studio 2005 Team System. I have several assemblies in
another solution which will be referenced in my project. How should i
reference them.

e.g.

1) Should I get both solutions from source safe then point to the assembly
in the release of that project directory (whereever I store the project
directories)

2) Install the assembly on the local development machine (Common
Files/GAC/otherwise) then browse to the assembly.

3) Add the projects to my solution then use the reference assemblies from
this solution tab.

4) Is there no real best-practice for this.

Thanks In Advance
Dave Anson

 

[sloan]

My company sets up a "Release" folder for commonly used assemblies.

C:\Inetpub\wwwroot\DotNet\v11\Assemblies\Framework\Release
C:\Inetpub\wwwroot\DotNet\v11\Assemblies\Framework\Beta


Then when I write an application (DietCodeManager for example)

C:\Inetpub\wwwroot\DotNet\v11\Source\Applications\DietCokeManager

the solution/project files go there
C:\Inetpub\wwwroot\DotNet\v11\Source\Applications\DietCokeManager\DietCokeManager.sln

C:\Inetpub\wwwroot\DotNet\v11\Source\Applications\DietCokeManager\Presentation.Winforms1\
C:\Inetpub\wwwroot\DotNet\v11\Source\Applications\DietCokeManager\BusinessLogic\
C:\Inetpub\wwwroot\DotNet\v11\Source\Applications\DietCokeManager\DAL\
C:\Inetpub\wwwroot\DotNet\v11\Source\Applications\DietCokeManager\SqlScripts\


Then,
lets say I have my own IO library (my company's code)
C:\Inetpub\wwwroot\DotNet\v11\Source\Framework\MyCompany.IO\
the above is where the source goes

The .dll , after tested and built, gets put into
C:\Inetpub\wwwroot\DotNet\v11\Assemblies\Framework\Release\MyCompany.IO.dll

Then, the dietcoke manager (whichever layer) can relatively reference the
file, usually like this
...\..\Framework\Release\MyCompany.IO.dll
(this would be in the .csproj file for example)


When we went to 2.0, new code was created in this base structure:
C:\Inetpub\wwwroot\DotNet\v20\
(everything else the same)

.........

Your #3. Good for developing, but not good for permenant. Remember, you
may have release versions of MyCompany.IO.dll, and
only after good testing, should MyCompany.IO.dll be moved to
(C:\Inetpub\wwwroot\DotNet\v11\Assemblies\Framework\Release)
You can't work with release versions if you have a reference "By Project".


Your #2. Overkill for alot of scenarios. GAC'ing should be done frugally.


In a group environment, its CRUCIAL to get everyone on the same page.

You don't necessarily have to use the C:\inetpub thing
C:\Inetpub\wwwroot\DotNet\v11\

but .... you have to PICK something

C:\development\DotNet\v11\
and as long as you can enforce everyone to use this, you'll be ok.

I like the C:\Inetpub\wwwroot\DotNet\v11\
(aka, under inetpub somewhere)
because you can create web applications that still can relatively reference
an assembly.

This has become less of an issue with 2.0, and its non-IIS web testing
ability.


The solution above is one that took my company a while to iron out.

It allows for relative references (crucial in a team environment).
It allows for 1.1 and 2.0 code development. (v11 and v20).
It allows for release/beta release scenarios of common assemblies.
It allows for multiple developers, along as everyone adopts the same mapping
from SourceSafe to "Set Working Folder".
(In fact, in the root diretory of our VSS database, I have 1 text file
that says... YOU MUST SET YOUR WORKING FOLDER TO THIS VALUE, on the vss root
folder that is)
(It looks like this:
The "$" inside of VSS (Framework11VSS database) should be set
(working directory) to:
C:\Inetpub\wwwroot\DotNet\v11\
)

We have 2 source databases as well.
Framework11VSS
Framework20VSS

Its easy to have 1 VSS database as well, just map the $ to
C:\Inetpub\wwwroot\DotNet\
and have 2 directories off of that
\v11\
\v20\



Good luck.

 

[Dave Anson]

Thank you for the response - very useful. I didn't state in my original
post, but the project are Windows Applications, but your solution is
relavant all the same.

The project I am working on is refering the Company's Framework. I have
created a setup project which will place the assemblies in the Program
Files directory. This will be for the developers to install on their local
machines. Providing they don't decide a drive other than C: will be there
system drive, it should be ok. In addition, I've removed the installation
screen from the setup project where they can specify their own directory.

Consequently, I came across issues with some source safe mappings and
project references within the Solution. I set the working folder
differently on the new machine. Gonna have to work out how to move the
files.

Thanks Again

Dave Anson

 

[sloan]

Yeah, I know it seems weird, but I still put winforms applications under the
C:\inetpub\wwwroot folder.
Again, so I can get that "across the board" relative path referencing.

As I stated earlier:

C:\Inetpub\wwwroot\DotNet\v11\Source\Applications\DietCokeManager\Presentation.Winforms1\

.............

Is it perfect? No. But you have to make some choices somewhere along the
line, and esp in a group environment.


The only "gotha" is sometimes the filename (full file name with the path
name) .. they get very long.
It used to be more of an issue with Win2000 and Asp.Net sites.

I think the bigger deal is consistency. And (again) the relative
referencing.