建议一个文件夹结构 [英] Suggest a folder structure

问题描述

我在一个单独的解决方案中有一个库prj，我们称之为myLib。我的应用程序在另一个解决方案文件中，称之为myApp。这两个位于不同的路径和文件夹中。



myApp引用myLib.dll。但是，我想从现在开始调试myLib库项目进行调查。是否可以调试myLib，而无需将其源代码添加到myApp解决方案中？



我应该在TFS中使用什么样的文件夹结构进行此安排并保持这两个分开？所以，其他解决方案（稍后再添加）以同样的方式访问myLib。



另外，我需要一种机制，开发人员可以打开或关闭库调试。



对上述内容的任何想法都非常感谢。

解决方案

看起来你是缺少关于项目开发技术的重要内容，很难说究竟是什么。



首先，只要调试两个或更多可执行模块就开发协同工作（无论是EXE，DLL还是不同.NET程序集的模块），唯一的非废话方法就是将它们放在同一个解决方案中。为了有勇气克服的东西，其他一切都会制造障碍。注意我用粗体格式化了你开发，表示我不是指没有源代码的模块，这些模块可能在你的依赖项中。



那说，如果你的整个解决方案相当大，为了隔离开发和调试而创建更小的子解决方案可能是非常合理的。 （这里有一个版本控制系统可以帮助避免混乱。）我甚至习惯使用自定义项目类型的MSBuild模式创建一个主项目，在其中组成不同的解决方案（甚至不是项目）;我没有一个一体化解决方案，主项目发挥了这个作用。但无论你做什么，你都必须拥有一个可以用于所有产品的单击构建的大型工件。当然，在每个子解决方案中，所有依赖关系都应该在任何给定的时刻解决（更确切地说，所有产品应该在任何提交到版本控制代码库之前编译）。



您错误的是文件系统目录结构与项目和解决方案结构之间的紧密联系。它们相似，但不一样。更大的错误是项目/解决方案结构与TFS之间的紧密联系。您的版本控制系统应被视为跟踪顶级产品目录及其下方的任何更改的工具，无论这些更改如何映射到项目和解决方案，从而映射到已编译的模块。我个人甚至避免将任何版本控制集成到Visual Studio中，但它可以被视为一个问题或个人品味和工作习惯。

-SA

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.

解决方案

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

这篇关于建议一个文件夹结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！