dll reference best practice

I've 22 projects in my solution.And I've added references to few project开发者_Python百科s by building those projects and selecting the dll created. Is this the best practise or should i use project reference instead of pointing to the dll ?

Regards, Vix.

I would suggest that you use project references. If I am not mistaken, in this case, you will always have actual (not outdated) assemblies referenced.

Well I don't know about best practices but some points to consider at least.

Advantages of project references:

• Easier to read code
• Easier to debug
• Easier to make changes

Advantages of dll references:

• Faster builds
• Less risk of accidental changes to shared components

NOTE: You should probably not keep the projects that you have dll references to in the same solution as it will lead to some confusion of what happens when you build.

In addittion to @platon post I would say not just always, but in most cases.

Examples:

1. If your project use a lot of libraries written years ago by X develppers of your company and something changed there one time in a couple of years and if you have 150 projects in your solution, adding DLL references of those libraries and NOT project references could be very good solution, if not on every Compile you will go to play a soccer on PS and come back after 10 minutes.

2. Your project use C++ libraries and you want to be able also to build your solution in VS Express edition (you work at home too, you should pass your code to someone that don't have still VS, cause it costs a lot... and so on ). Add DLL and not project reference

and so on... .... .

I mean what says @platon is absolutely correct, but not always true.

Regards.

I would have to agree with platon to use project references. Most likely you solution is taking a long time to compile. Some things we have done on our project:

• Reduce the number of projects in the solution
• Get better developer PCs especially PCs with SSD drives
• Build the dependent projects to an External Assemblies folder that is part of the solution and checked into source control.

Using project references will enable you to easily read code, step-in and debug / edit those projects should the need arise. In my opinion, this is invaluable, and not one worth circumventing.

However, if you've found your build time suffering because of a large number of projects you could take a few different approaches. Here's a few:

1. Go to the solution configuration manager and turn off "Build" setting for some of the projects while in the Debug configuration. Note that this will have the side-effect of requiring you to manually build those projects when you make changes and that when the solution is downloaded fresh from source control, you'll have to manually build those projects. This approach is good for "stable but in development" projects.

2. Pre-compile the projects (in Release configuration) and build them into a all into a specified folder at the solution root (something like "ExternalAssemblies" or "References"). Then you should remove those projects, and re-add all references to them by browsing to the compilation folder and adding the references from there. This approach is good for "stable" projects that you're really unlikely to edit.

3. Leave the projects as they are, and get better PC's. Faster disks and more RAM never goes astray on a developer machine... The merits of the approach should be obvious enough.