1
votes

All,

I have several top level projects (console apps, websites, etc) that have internally built dependency projects. Some of these sub-projects are referenced in the top level projects by including the DLL from the sub-project's bin folder, and some are referenced by including the project in the solution. I have no idea which way is the "right" way, but I do know I can't get any of my top level projects to build using TFS Continuous build. They build locally, but not in TFS Continuous build. They usually fail with a series of "can't find reference" errors.

My though is that I will need to take each of the sub-projects (models, repositories, etc) and have them build to a central location, then reference that central location in the top level projects. The only thing I don't like is that I don't see a way to only let DEV branch builds copy to the central location unless I just use a post-build event script on the DEV branch project.

If anyone out there can help me find some Zen with this process, I would appreciate it. I am a software engineer, not a build engineer...

1
I don't know why you don't know what the 'right way' is and can only assume you have never read anything on project dependencies in Visual Studio. You should only ever use project references and never add a reference to a DLL in a bin folder...ever! - MrHinsh - Martin Hinshelwood
MrHinsh - you assume a lot. I inherited this TFS configuration. Had I set it up myself, I would have done things differently. Thanks for the advice despite the tone. - jaxmeier
The tone was a reflection of this not being a TFS issue and a fundamental attribute of Visual Studio for more than 13 years. - MrHinsh - Martin Hinshelwood

1 Answers

2
votes

If you're versioning dependencies separately from applications that use them, then use NuGet for managing the dependencies. As part of the build process, the packages will be restored.

Binaries should basically never be in source control.