您如何拆分Visual Studio解决方案? [英] How do you split a Visual Studio Solution?

查看:434
本文介绍了您如何拆分Visual Studio解决方案?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个Visual Studio 2008解决方案,其中包含40个以上相互依赖的C#和C ++/CLI项目.使用该解决方案的速度非常慢,通常我一次只需要几个项目.因此,我决定将解决方案分为包含3-5个项目的多个解决方案. 我还想在所有项目中保留完整"的解决方案(对于自动构建或影响所有项目的大型重构操作非常方便).(这是这里的主要条件.否则,请拆分解决方案中的项目当然是微不足道的.)

I have a Visual Studio 2008 solution with >40 C# and C++/CLI projects that depend on each other. Working with that solution is quite slow, and usually I only need a few projects at a time. So I decided to split the solution into multiple solutions that contain 3-5 projects. I would also like to keep the "full" solution with all projects (it's handy for for automated builds or for big refactoring actions that affect all projects). (This is the main condition here. Otherwise, splitting projects into solutions is trivial, of course.)

有什么办法吗?

我的第一个想法是创建新的空解决方案,并将一些现有的项目文件添加到每个解决方案中.但是,如果这样做,VS将无法再找到项目引用(因为它们不在同一解决方案中).我可以将引用添加为普通"文件引用.但是,如果这样做,我的完整"解决方案将不再起作用,因为依赖项会丢失.

My first idea was to create new empty solutions and add some of the existing project files into each of these solutions. But if I do that, VS can't find the project references any more (because they're not in the same solution). I can add the references as "normal" file references. But if I do that, my "full" solution doesn't work any more, because the dependencies are lost.

谢谢大家的回答.我想澄清一下我的问题:我的解决方案包含44个项目,不包括测试.因此,将其分为两部分并不是我真正想到的,我更多地考虑了5-8部分.这就是为什么我要保留完整"解决方案的原因,在该解决方案中,VS可以找出完整构建的正确构建顺序.手动维护8个独立解决方案的构建顺序(例如在批处理文件中)对我来说容易出错.

Thank you all for your answers. I'd like to clarify my question a bit: My solution contains 44 projects, not including tests. So splitting it into 2 parts isn't really what I had in mind, I was more thinking about 5-8 parts. That's why I would like to keep the "full" solution where VS can figure out the correct build order for a full build. Maintaining the build order for 8 separate solutions by hand (e.g. in a batch file) seems error-prone to me.

我还想将项目逻辑上"分组(即,我希望将通常在一个解决方案中一起修改过的项目).但是,该分组并不总是与依赖项匹配.例如,假设我有依赖链

Also I would like to group the projects "logically" (i.e. I would like to have the projects that are usually modified together in one solution). But that grouping does not always match the dependencies. For example, imagine I have the dependency chain

A is referenced by B is referenced by C is referenced by D

并想象A和D经常一起修改,而B和C很少改变. (显然,为此B使用的A的接口必须保持不变.)然后,我想在一个解决方案中使用A和D,在另一个解决方案中使用B和C.但是,如果我想从头开始构建所有项目,则只有在我可以拥有包含A,B,C和D的完整完整"解决方案的情况下,这才起作用.构建完成后,我可以打开A/D解决方案并仅编辑/构建这2个项目.

and imagine that A and D are often modified together but B and C rarely change. (Obviously, the interface of A that is used by B must remain unchanged for that.) Then I would like to have A and D in one solution, B and C in another. But that would only work if I could have an intact "complete" solution containing A,B,C and D if I want to build all projects from scratch. Once that build is complete, I could open my A/D-solution and edit/build only those 2 projects.

但是我担心我的问题没有完美的解决方案. (双关语无意)

But I fear there is no elegant solution for my problem. (pun not intended)

推荐答案

没有好的方法.这些工具并不是在考虑这一点的情况下构建的.相反,您应该将项目尽可能地组合在一起.即使代码量相同,构建也会运行许多倍.

There's no good way to do this. The tools aren't built with that in mind. Instead, you should combine your projects together as much as you can. Even though it's the same amount of code, builds will run many times faster.

您将不得不克服这样的想法,即拥有良好的抽象需要单独的项目.似乎是强制分离的一种非常干净的方法.但是,使用此工具链不值得付出代价.改用语言功能;类,名称空间等.

You'll have to get over the idea that separate projects are required for having good abstractions. It seems like a very clean way to enforce separation. But it's not worth the price with this toolchain. Use the language features instead; classes, namespaces, and so on.

这篇关于您如何拆分Visual Studio解决方案?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆