在解决方案中共享Visual Studio项目(程序集)的最佳实践是什么?

Kyl*_*est 11 svn projects-and-solutions visual-studio

假设我有一个项目"MyFramework",它有一些代码,用于很多解决方案.每个解决方案都有自己的源控制管理(SVN).

MyFramework是一个内部产品,没有正式的发布时间表,解决方案也是如此.

我不希望不必将DLL构建并复制到所有12个项目,即新开发人员应该能够只执行svn-checkout并开始工作.

在所有这些解决方案中分享MyFramework的最佳方式是什么?

M4N*_*M4N 7

由于您提到了SVN,因此您可以使用外部元素将框架项目"导入"到使用它的每个解决方案的工作副本中.这将导致这样的布局:

C:\Projects
  MyFramework
    MyFramework.csproj
    <MyFramework files>

  SolutionA
    SolutionA.sln
    ProjectA1
      <ProjectA1 files>
    MyFramework   <-- this is a svn:externals definition to "import" MyFramework
      MyFramework.csproj
      <MyFramework files>
Run Code Online (Sandbox Code Playgroud)

使用此解决方案,您可以在使用它的每个解决方案中获得MyFramework的源代码.优点是,您可以从每个解决方案中更改MyFramework的源代码(无需切换到其他项目).

但是:同时这也是一个巨大的劣势,因为它可以很容易地为某些解决方案打破MyFramwork时将其修改为另一个解决方案.

出于这个原因,我最近放弃了这种方法,现在将我们的框架项目视为一个完全独立的解决方案/产品(具有自己的发布时间表).然后,所有其他解决方案都包含框架项目的特定版本的二进制文件.

这可确保对框架库所做的更改不会破坏任何重用库的解决方案.对于每个解决方案,我现在可以决定何时更新到更新版本的框架库.