Suggest a folder structure

Question

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.

Posted 18-Feb-15 8:30am

JamesHadleyChase

Add a Solution

Comments

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

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

Sergey Alexandrovich Kryukov · Answer 1 · 2015-02-18T12:27:00

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.

—SA