在 Visual Studio 中处理多个项目/解决方案的最佳方式？
目前我有 4 个独立项目的解决方案，但是在应用程序的某些领域存在大量重复代码。
目前它只是一些表单及其相关代码。
当我想要更改或改进某些内容时，我必须复制并粘贴到所有相关项目。
我考虑在 .dll/类库的解决方案之一中创建一个新项目，但我觉得这是不正确的。 （如果我错了请指出）。
由于它是所有应用程序的组件，我决定为 .dll/类库创建一个新的解决方案，并考虑将共享代码移至该解决方案 - 但是，以前从未走过这条路，我的选择是什么从这里？
如果我需要进行简单的更改并在所有项目中更新它，或者相反，我是否应该始终在 Visual Studio 之外的单独实例中处理共享组件，我是否可以将此解决方案包含在其他解决方案中？应用程序使用它吗？
Currently I have 4 solutions that are independent projects, however there is quite a bit of duplicated code when it comes to a few areas of the applications.
At the moment it is simply a few forms and their associated code.
When I want to change or improve something, I have to copy and paste to all relevant projects.
I looked at creating a new project within one of the solutions for the .dll/class library, but I felt that this was incorrect. (Please say if I am wrong).
As it is a component for all the applications, I decided to create a new solution for the .dll/class library and am looking at moving the shared code over to that - but, having never gone down this route before, what are my options from here?
Am I able to then include this solution within the others if I need to make a simple change and have it updated in all the projects or instead, should I always be working on the shared component in a separate instance of Visual Studio, outside of the applications using it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这正是处理这种情况的正确方法。
您可以通过右键单击解决方案并选择“添加现有项目...”将项目包含在多个解决方案中
。您随后所做的任何更改都将显示在所有解决方案中。这导致的唯一问题是可能会破坏一种解决方案与另一种解决方案。这就是基于源代码控制提交的自动化构建发挥作用的地方。
That's exactly the right way to handle this situation.
You can include projects in multiple solutions by right-clicking the solution and selecting Add Existing Project...
Any changes you then make will appear in all solutions. The only problem this leads to is that it's possible to break one solution from another. This is where automated builds on commit to source control come into their own.
通过每次构建消费者项目时执行此操作，它们将自动使用最新的 dll。
By doing this each time you build your consumer projects, they will use latest dll's automatically.
将公共代码移动到单独的共享程序集中是一个很好的选择。
需要考虑的一件事是将通用业务逻辑或业务对象类型代码与 UI 相关代码（如自定义控件）分开 - 如果您需要有两个通用程序集。最初这需要更多的工作，但是当您需要更改 UI 或更改您正在使用的控制套件时，会让事情变得更容易。
Moving the common code into a separate shared assembly is an excellent option.
One thing to think about is to keep your common business logic or business object type code separate from UI related code like custom controls - if you need to then have two common assemblies. This is more work initially, but makes things way easier further down the track when you need to make UI changes or change the control suite you are using.