2013-02-13 55 views
3

我有许多项目的应用程序。 我有时会发现我必须删除dll,并在整体清理编译之前重新编译每个项目。 我还发现,当我做一个构建时,我必须记得检查每个项目的存储在bin文件夹中的dll,编译每个项目,检查dll,然后运行构建以获得干净的编译。 这很麻烦。 我只想为我做的任何更改重建一次,以及何时发布。 那我该如何解决呢?MVC:需要用多个项目构建我的应用程序

+1

+1这个真棒问题... – 2013-02-13 15:46:31

+0

我不知道我明白。我有很多包含混合第三方和本土DLL的项目的解决方案,从来没有遇到过问题。除非您正在对这些DLL进行更改,否则您不应“检出”静态DLL以进行编译。如果您正在对DLL进行更改,那么为什么要直接引用这些DLL而不是项目引用? – jmrnet 2013-02-13 16:00:10

+0

第三方DLL在lib文件夹中,这不是问题。我发现为了编译我的应用程序,我必须将每个项目的dll复制到我的主项目的bin目录中。也许有另一种更好的方式来做到这一点?我怀疑有。 – arame3333 2013-02-13 16:04:32

回答

1

我们在我工作的公司中遇到过这个问题,我们仍在努力清理所有问题。

我要做的第一个建议是没有项目引用到您的解决方案中的通用库。你说你的项目的bin文件夹中有一些inhouse dll。你要问自己:

  • 特定于该解决方案
  • 或者这些DLL,是他们共同的库,你将再次使用

如果是前者,那么我建议你有一个动态链接库作为解决方案中的项目来源。在Visual Studio中正确设置构建顺序,重建解决方案将确保一切都得到一个干净的构建。

但是,如果它是后者,并且您将在其他解决方案中重用这些dll,那么它们应该在他们自己的解决方案中。理想情况下,使用诸如Cruise Control之类的构建服务器或类似的东西。这将允许您对通用库进行更改,并且只要您正确设置,它就会自动使用新版本号重新编译它。然后,一旦您的公共图书馆通过了测试,并且您很高兴将其发布,请将其放入正在处理的项目中的“bin”或“Dependencies”文件夹中。如上例所示,引用该dll而不是Project。当你建立你的项目时,它将在编译时使用bin/Dependencies文件夹中的dll。

这样做的好处是,如果您在一个解决方案中使用通用库并将其发布到客户端或作为项目,然后更改通用库并发布新的客户端解决方案/产品,您将确切知道哪个版本共用库正在使用中。然后,你可以去你的源代码管理并提取确切的代码。

我们正在使用一些产品,并使用我们实施的每个客户端解决方案进行有效增长。在十几个项目之后,我们不知道每个客户端正在运行的代码版本。自从我们转移到与Mercurial联合的Cruise Control for SSC以来,我们现在清楚地知道我们的所有产品和客户端解决方案正在使用的代码版本。

+0

我发现Nuget下载的每个项目的每个版本都没有被拾取。所以我在每个项目中创建了一个lib文件夹并将它们复制到那里。这确实留下了Nuget更新的问题,不知道将来如何解决这个问题。你对构建顺序的建议也有帮助,所以我给你打勾。 – arame3333 2013-02-15 08:25:01

1

很难确切地知道你需要什么来解决你的具体问题,没有更多的细节,但这些技巧应该有很大的帮助。

当我做了构建我要记得签每个 项目,该项目被存储在bin文件夹

首先所有的dll文件,不要将您的bin文件夹内容存储在源代码控制。相反,只有在需要与某人共享时才发布构建,并将其放在源控制系统的不同位置。这是一个可以这样工作的文件夹结构的例子。

-MyProduct - 主 ---- SRC ----斌< <在 没有检查----等等 - 配送 --MyProject ----版本号 ------明确公布的dll

我已经删除了的DLL并重新编译每一个项目之前,我得到一个整体的全新的编译。

有时发生这种情况。在Visual Studio中使用重建解决方案命令。

如果您使用文件引用而不是项目引用,则会导致此问题更频繁发生的问题。使用项目参考。看到这个问题的上的详细信息:

Project Reference Vs File Reference?

如果您不能使用项目引用出于某种原因,你可以手动更改解决方案的构建顺序,并建立依赖关系项目之间更好的更新。

+0

当我从bin目录中的源代码控制中删除项目dll时,发布版本将无法找到它们。我知道我应该给你更多的信息继续下去,但我想不出什么。 – arame3333 2013-02-13 16:32:50

+0

所以,你需要解决这个问题。您的发布版本不应该依赖于正在签入您的版本的dll。很可能你们不得不在这个问题上“剥洋葱”几次。 – tallseth 2013-02-13 17:54:24

1

我有时会发现我已经删除了的DLL并重新编译每个项目 之前,我得到一个整体的全新的编译。

右键单击解决方案> Clean Solution。然后重新构建。这通常会清除奇怪的构建错误。

我也发现当我做了构建我记得要签出的DLL中存储的bin文件夹中的每个项目的 ,编译每个 项目,在DLL检查,然后运行构建得到编译一个干净的 。

这很可能是真正的问题。不要将外部DLL直接添加到垃圾箱。相反,在解决方案的根添加任何第三方的DLL到一个文件夹,还是真的,其他任何地方,你可以访问,但我找了根的好去处:

- Solution Folder 
    - ExtLib (place all your 3rd party assemblies here; use sub-folders if needed) 
    - Project A 
    - Project B 
    - MySolution.sln 

然后,参照每个项目增加从您的ExtLib需要:添加引用>浏览:根据需要添加dll。

一旦添加了dll,确保它们被标记为“复制本地”:References>右键单击程序集:复制Local = True。

如果需要引用的程序集位于相关项目中,则只需添加项目引用;无需复制本地VS作为您的照顾。

通过上述操作,您可以将第三方程序集保存在ExtLib文件夹中,并根据需要添加到源代码管理中。然后,每当有人从源代码管理中拉下项目,他们就会拿起ExtLib文件夹和任何更新的程序集。无论何时构建,程序集都会从ExtLib中引用并复制到bin。正如其他人所提到的,千万不要永远把你的bin文件夹添加到源代码控制:YMMV。

+0

谢谢你。我需要一些澄清。当我想到第三方dll时,我正在考虑以Elmah或EntityFramework为例。我已经把它们放在一个独立的库中,并且工作正常。但是项目A,项目B等的dll呢?我已经把它们放在bin目录中,但正如我之前提到的,如果我检查它们,我只能成功发布版本。 – arame3333 2013-02-14 09:43:53

+0

我从来没有使用过干净的解决方案选项,因此对于+1来说,它非常有用 – arame3333 2013-02-14 09:45:29

+0

项目A,B等...被添加为项目参考。右键单击参考>添加参考>添加项目。这假定项目是现有解决方案的一部分。否则,将它们视为任何其他第三方DLL。 – 2013-02-14 14:20:57

相关问题