We have a .NET project consisting of multiple subprojects (around 20). There are several solutions, each containing only those subprojects which are relevant to the particular solution.
To allow for arbitrary solutions, our subprojects never reference each other by means of project references, but rather by direct dll references. There is little tweaking of the csproj file, to make HintPath include $(Configuration), so Debug builds reference Debug dlls and Release builds reference Release dlls.
All works great, but there are two major problems - one is annoying and another is really acute:
I am seeking for an advice of those folks out there who use dll references like us and have somehow overcome these two issues. Thanks.
EDIT:
Note, that besides the "Browse to Definition" issue, having Dll references instead of project references incurs only one time cost on the project manager - which is to update the project dependencies of each affected solution when a new project is added or a new dependency must be introduced. These project dependencies are persisted in the .sln file and do not require any maintenance until a new project arrives or a new dependency is created, which happens not that too often.
We are using msbuild for building our projects on the CI server, which uses the same .sln files as VS does. There is one main .sln file, which includes all the subprojects.
I wish to emphasize the more acute problem - the inability to browse to a defintion in another project, although both projects are in the same solution just because the references are dll references. This is annoying and it is a nuisance, there is no reason why VS insists on project references to enable the feature. Other tools, like Resharper or Visual Assist do not have this limitation. Alas, we do not have these tools and unlikely to have in the observable future.
The problem with your build configuration is the following: say you have 3 projects and 2 solutions.
Solution1
- Project1
- Project2
Solution2
- Project1
- Project3
All of a sudden, building Solution2 builds part of the code for Solution1, leaving it in an invalid state (the latest binaries are either incompatible or did not need to be built).
Every project should be included in a single solution. Other solutions can rely on, but should not actively change the code of those projects. In this way, they can reference a built DLL because there's no reason to rebuild the external dependencies.
To summarize, you should take some time and restructure your solutions to meet the following conditions:
In addition to the above, I recommend creating an "Externals" directory for placing builds in when they are referenced by other solutions. Say you restructure to the following:
Solution1
- Project1
- Project2 -> reference project Project1
Solution2
- Project3 -> reference Project1.dll
In this case, you'd place copies of Project1.dll and Project1.pdb in Externals\Project1\Debug
and Externals\Project1\Release
, and reference External\Project1\$(Configuration)\Project1.dll
in Project3. Only update the builds in the Externals directory when you are ready to push the build to all your other solutions.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With