This project has moved and is read-only. For the latest updates, please go here.

refrences to dlls and source control?

Jan 24, 2011 at 9:18 AM

Dear experts,

At first thanks for your excelent guidance, it helps me alot. Also there is something that is not clear to me at the bottom of page 24 where you talked about References to other parts of the system not in the current solution.

Your guidance says to seprate project layers to different solutions and then add a post-build step to copy dlls to a shared location. But the problem is when we are under the source control(like TFS). should I add this shared location to source control or not? if the answere is not, we may encounter many problems when team members work simultaneously on layers. any build causes changes on shared location and then other members may encounter problems because of differenct version they work on.

would you please clarify what should we exactly do?

Thanks in advance,<!--EndFragment-->

Apr 3, 2011 at 7:31 PM

First of all sorry for the late reply, I didn’t have a subscription to the discussion list, so just found today that this question is here since end of January.

To Get back to your question, you are totally right! The guidance assumes you set up a build environment that also puts the daily build results into the version control system. This would provide all team members with the simple steps of setting up their dev environment to:

  • Get the workspace mapping from the team (e.g. a workspace template placed in the team members option of the power tools)
  • Do a full get on the workspace
  • Have all the references to shared items to the shared location in the workspace.

As some guidance in this area, we normally set up a location in version control we call "99-bin" and we hev some subfolders in there as well. e.g. an folder with the name extref for external references to e.g. 3th party products we use. Then we have a folder called "deliverables" with subfolders for each solution that produces output and is part of our product.

We also make the "99-bin" folder a local drive using the subst command. we do a "subst s: <drive>:\<workingfolder>\product\99-bin"

When we set references in our projects we use the s: drive for the reference so visual studio keeps a full path reference instead of an relative path that breaks when someone uses a different folder structure on their local dev machine.

Hope this helps,