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\MyC ompany.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\Framewor k\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" <da********@jazzthecat.co.ukwrote in message
news:Xn**********************************@216.196. 109.145...
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
