views:

68

answers:

3

For a long time looking for a way to manage references, I haven't found any ideal way.

The main problems are:

1-) Should I include all projects that I use in same Solution and reference the Project? Or reference just the dll file?

2-) If I should reference dll file, the best way is to create a ReferencedAssemblies inside each project or a main folder at svn root?

3-) Its ok paste and reference dll´s inside bin folder of my project?

4-) Its ok add and commit dll´s inside bin folder of my project? This way when a new devoloper checkout the project, it will compile perfect, but isn´t default behavior of visual studio, all source controls ignore bin and obj by default, just adding .refresh files(for web-site project)

Someone can help me?

A: 

1) I'd argue it depends upon your particular situation, especially since Visual Studio is pretty flexible on what projects are included in solutions. (It's not tied to a directory structure.)

We have a couple applications that have one solution with a number of projects contained within (for each 'piece').

2, 3, 4) For referencing and including files within a project, why not just use the functionality built into Visual Studio? Adding references in this way adds the items to your csproj (vbproj) files.

(Based on my research, if you're not referencing a project that's part of the solution, put the DLLs in a directory everyone on the team can access and use that when adding the reference. In the project file it ends up looking like this:

<Reference Include="Elmah">
    <HintPath>\\pathInformation\shared assemblies\ELMAH 1.1 32-bit\Elmah.dll</HintPath>
</Reference>

)

This also means that you don't have to commit DLLs; if anything changes the project file will be updated accordingly.

(I'll admit, I'm unsure about that last point. I've seen a lot of people check in external libraries, like ELMAH. I generally follow those who tell you to ignore the bin directory entirely.)

James Skemp
Nothing like a down vote with no reason why ...
James Skemp
+1  A: 

1) If you include projects in your solution that are already checked in somewhere else, you can change the SVN binding for that project at the solution level in Visual Studio. (File > Source Control > Change Source Control). You would change it to point to wherever it's located in your SVN repo.

2) If you have a lot of developers on different machines all wanting to use the same libraries, it's probably easier to have a common place for all your third-party libraries/assemblies. There's no point in having them copied all over the place in your SVN repository.

3) No, it's not usually ok to do this. I would avoid it (unless somebody has a valid reason for it).

4) Never commit your bin folders. The default behavior is such for a reason. The .refresh files are byproducts of the old Web Site projects and they are fine.

Cory Larson
Also agree with this answer.
Restuta
2-) This can cause a problem when one developer is testing a new dll version for one project. All projects will be updated
Fujiy
@Fujiy re 2: I believe that's why it's a good reason to version the libraries.
James Skemp
+2  A: 

1) In the typical scenario yes, you should reference all projects that you own. But you should make a decision according to frequency of changes made to referenced projects. For example if you have an open source library it is better to include it as an assembly, cos you probably will not change this code frequently.

2) Typical approach is to create separate single directory at SVN root and place assemblies there in different sub-folders according to assemblies type. Here is how my current folder looks like: alt text

3) No, it is better to reference assemblies from some other from bin folder. All referenced assemblies will be copied to the bin while building process. Also note that the purpose of *.refresh files in the bin folder is to prevent you from having to copy new versions yourself.

4) No, you should never commit your bin folder cos you can rely on *.refresh files for WebSites and just forget about this problem for other project types.

Restuta