Click here to Skip to main content
14,733,033 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
I have a library prj in a separate solution, lets call it myLib. My application is in another solution file, call it myApp. These two reside in different paths and folders.

myApp references myLib.dll. However, I would like to debug myLib library project for investigations from now on. Is it possible to debug myLib, without adding its source to the myApp solution ?

What kind of a folder structure should I have in the TFS for this arrangement and yet keep these two separate ? so that, other solutions (to be added later) access myLib the same way.

Also, I would need a mechanism wherein, the developer would toggle on or off the library debugging.

Any thoughts on the above is highly appreciated.
PIEBALDconsult 18-Feb-15 15:07pm
That has nothing to do with TFS.
I'll assume you're using Visual Studio -- in which case, you can add the existing library project to your application solution and set the reference appropriately.

1 solution

It looks like you are missing something important about project development technology, hard to say what exactly.

First of all, as soon as you debug two or more executable modules you develop working in collaboration (no matter, EXE, DLL or modules of different .NET assemblies), the only non-nonsense approach is having them in the same solution. Everything else would be creating obstacles for the sake of having something to bravely overcome. Note I formatted "you develop" in bold, to indicate that I don't mean modules without source code which might be in your dependencies.

That said, if your whole solution is quite big, it could be quite reasonable to create smaller sub-solutions for the purpose of isolated development and debugging. (And here is the point where a Revision Control system can help to avoid making a mess.) I even used to create a master project using MSBuild schema with custom project type, composing different solutions in it (not even project); and I had not have one all-in-one solution, the master project played this role. But whatever you do, you have to have one single big artifact you could use for one click build of all the product. Naturally, in every sub-solution, all dependencies should be resolved at any given moment of time (more exactly, all the product should compile before any commit to the Revision Control code base).

You mistake is the tight bound between filesystem directory structure and project and solution structure. They are similar, but not the same. Even bigger mistake would be the strong binding between project/solution structure and TFS. Your Revision Control system should be considered as a tool tracking any changes in the top product directory and below, no matter how these changes are mapped to the projects and solutions, and hence the compiled modules. I personally even avoid any Revision Control integration into Visual Studio, but it can be considered as a matter or personal taste and working habits.


This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900