如何为解决方案中的所有项目引用一次程序集

发布于 2024-07-30 14:16:09 字数 349 浏览 3 评论 0原文

我有几个解决方案,每个解决方案都包含多个项目,所有这些项目都需要引用单个程序集,例如 lib.dll。

其中包含需要在所有解决方案之间访问的通用类和功能; 我无法将所有项目纳入一个解决方案,因为我的经理希望能够在不同的解决方案之间使用不同版本的 lib.dll。 我目前还停留在 VSS 和 2005 上(同情票?)。

目前,我必须手动重做解决方案中所有项目的引用; 我真正想要做的是将所有内容集中到一个地方,但显然 GAC 不希望这样做。

对我来说,有什么办法可以拥有一个虚拟项目,该项目可以被特定解决方案中的所有其他项目引用,在引用时,该项目将提供 lib.dll ?

我是不是找错树了?

I have several solutions, each containing multiple projects, that all need to reference a single assembly, say, lib.dll.

This contains common classes and functionality which needs to be accessed between all the solutions; and I can't bring all the projects into one solution as my manager wants to be able to use different versions of lib.dll between different solutions. I am also stuck on VSS and 2005 for the moment (sympathy votes?).

Currently, I'm having to redo references in all the projects in the solution manually; what I really want to be able to do is to have everything in one place, but obviously the GAC is out for this.

Is there any way for me have, say, a dummy project which can be referenced by all the other projects in a particular solution which, when referenced, will provide lib.dll?

Am I barking up the wrong tree here?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

风流物 2024-08-06 14:16:10

首先,在源代码树中选择一个可以将 DLL 部署到的已知位置。 将自定义构建步骤添加到共享库,以将构建结果复制到该已知目录(使用相对路径)。 然后,当添加对共享库的引用时,在该已知位置引用它(验证引用的提示路径使用 vcproj 文件中的相对路径)。

我使用相对路径,因此共享位置位于进入源代码管理的源代码树中...如果有人从源代码控制中选取同一棵树,它会按预期工作。 作为替代方案,您可能每台计算机都有一个指向共享路径的环境变量。 这种替代方案意味着同一台计算机上的源树的多个副本可能会相互干扰,但解决方案不必以相对于彼此的固定方式定位。 该共享也可能位于网络路径上,但如果其他开发人员构建他们的更改,则会相互覆盖。

First, pick a known location the DLL can be deployed to within your source tree. Add a custom build step to the shared library to copy the build result to that known directory (using relative paths). Then, when add references to the shared library, reference it at that known location (verify the hintpath of the reference uses relative paths in the vcproj file).

I use relative paths so the share location is in the source tree that goes into source control... if someone picks up the same tree from source control it works as expected. As an alternative, you might have an environment variable per machine that points to the share path. This alternative means multiple copies of the source tree on the same machine could muck with each other, but the solutions then don't have to be located in a fixed way relative to each other. That share could also be on a network path, but then if other developers build their changes will overwrite each others.

梦晓ヶ微光ヅ倾城 2024-08-06 14:16:10

GAC 应该仍然可以工作。 您可以在 GAC 中拥有同一 DLL 的多个版本。

The GAC should still work. You can have multiple versions of the same DLL in the GAC.

把回忆走一遍 2024-08-06 14:16:10

即使您创建了一个引用 lib.dll 的虚拟项目(例如 project.dll),您仍然需要在解决方案中的所有其他项目中添加对 那个 dll 的引用,因此您' d 处于相同的情况,只是使用不同的程序集。

另请注意,如果将来 lib.dll 会有不同版本,并且不同的项目将引用该 dll 的不同版本,那么您甚至不会想要执行您所描述的操作,因为您只会引用该 dll 的一个版本,无论如何,这都是不正确的。

我通常用来整合框架或库的方法是将它们保存在一个公共文件夹中并从那里引用它们(例如引用文件夹或其他文件夹)。 我还让我的团队模仿相同的文件夹结构。 我们已经以这种方式检查到我们的存储库中,并且所有内容都很好地引用了。 如果我们需要更改 dll,那么我们只需检出该文件,覆盖它,重新检入,然后重建解决方案。

Even if you created a dummy project that referenced lib.dll (say project.dll), you'd still have to add a reference to that dll in all your other projects in the solution, so you'd be in the same situation, just with a different assembly.

Another note, if there are going to be different versions for lib.dll in the future and different projects would reference different versions for that dll, then you wouldn't even want to do what you're describing, because you would only be referencing one version of the dll, which would be incorrect, anyway.

What I usually do to consolidate frameworks or libraries is keep them in a common folder and reference them from there (like a References folder or something). I also have my team mimic the same folder structure. We have that checked into our repository that way and everything references well. If we change need to change the dll then we just check out the file, overwrite it, check it back in, and rebuild the solution.

星軌x 2024-08-06 14:16:09

项目文件只是 XML 文档,因此在脚本中进行解析(这里 IronPython 是一个不错的选择)、检查是否存在引用以及根据需要插入或更新应该是相对简单的事情。

The project files are just XML documents, so parsing in a script (IronPython is a good choice here), checking if there is a reference, and inserting or updating as required should be a comparatively trivial matter to achieve.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文