部署项目中缺少项目依赖项
我有一个 VS2008 部署项目，它为几个 Windows 服务构建安装程序。
每个服务引用几个不同的项目：
CustomerName.MailSendingService -> CustomerName.Network -> CustomerName.Data -> CustomerName.Security CustomerName.ProductIntegrationService -> CustomerName.Core -> CustomerName.Security
Windows 服务项目、它们引用的项目以及部署项目都在同一个 VS2008 解决方案中。
我已在部署项目的文件系统编辑器中添加了 Windows 服务项目的主要输出。
我的期望是 Windows 服务项目的主要输出将包括引用项目中的 DLL。 但是，构建部署项目时，引用项目之一的 DLL 丢失。 （CustomerName.ProductIntegrationService 缺少 CustomerName.Security）
令人抓狂的是，Windows 服务引用的其他项目的 DLL 仍然存在； 仅缺少一个项目的输出。
（编辑）我已验证参考属性窗口中的参考设置为“复制本地”。 引用项目的 DLL 放置在 Windows 服务项目的 bin\Release 文件夹中，但未打包在为部署项目构建的 MSI 文件中。
（编辑 2）按照 Joseph Daigle 的建议，我检查了依赖项是否位于主要输出的依赖项列表中，并且它没有标记为“已排除”，因此这似乎不是此问题的原因。
为什么只有一个项目的输出会丢失？
I've got a VS2008 deployment project that builds an installer for a couple of Windows services.
Each service references several different projects:
CustomerName.MailSendingService -> CustomerName.Network -> CustomerName.Data -> CustomerName.Security CustomerName.ProductIntegrationService -> CustomerName.Core -> CustomerName.Security
The Windows service projects, the projects they reference, and the deployment project are all in the same VS2008 solution.
I've added the primary output from the Windows service projects in the deployment project's file system editor.
My expectation is that the primary output for the Windows service projects would include the DLLs from the referenced projects. However, when the deployment project is built, the DLL from one of the referenced projects is missing. (CustomerName.ProductIntegrationService is missing CustomerName.Security)
Maddeningly, the DLLs for the other projects referenced by the Windows service are present; just one project's output is missing.
(Edit) I've verified that the reference is set to Copy Local in the reference properties window. The DLL for the referenced project is placed in the windows service project's bin\Release folder, but isn't packaged in the MSI file built for the deployment project.
(Edit 2) Following Joseph Daigle's suggestion, I checked that the dependency is in the dependencies list for the primary output, and it's not marked "excluded," so that doesn't appear to be the cause of this issue.
Why would just one project's output be missing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
看看这个 - 也许这不能解释为什么会这样，但至少它提供了一些解决方法:)
http://lo-sharpdevs.blogspot.com/2009/07/vs-2008-disappearing-dependency.html
check this out - maybe this not explains why is that, but at least it provides some workaround :)
http://lo-sharpdevs.blogspot.com/2009/07/vs-2008-disappearing-dependencies.html
我在使用 Microsoft SMO 对象时遇到了类似的问题。 我有一个二进制组件 (X.dll)，它使用我自己制作的这些 Microsoft SMO 对象。 编译 X.dll 后，我使用 X.dll （而不是代码）在另一个 EXE 项目中引用它。 附加的安装程序项目检测到它需要 Microsoft SMO 对象，并检测到它们位于计算机上的 SQL Server 安装的本地。
使用 SMO 对象的组件 X.dll 通过我保留在共享驱动器上的本地“Externals”文件夹引用 Microsoft SMO 对象。 所有模块都是参考这些模块进行编译的，但是我的安装项目和 EXE 项目会检测到我的 SQL Server 安装中的模块。
因此，我们有另一台机器，它具有包含 SMO 对象的“Externals”文件夹，但安装项目将不再从“检测到的依赖项”中找到 SMO 对象，因为它没有意识到 SMO 对象位于外部模块中！ 我不确定它在哪里搜索检测到的依赖文件，但它并没有查看 X.dll 最初从哪里获取它们，甚至可能不是 EXE 文件夹......
I have had a similar issue with Microsoft SMO objects usage. I have a binary component (X.dll) that uses these Microsoft SMO objects that i've made myself. After compiling X.dll, I reference it in another EXE project using X.dll (and not the code). The installer project attached to that detects that it needs the Microsoft SMO Objects and detects that they are local to my SQL Server installation on the machine.
The component X.dll that uses the SMO Objects references the Microsoft SMO Objects via a local "Externals" folder i keep on a shared drive. All modules are compiled with reference to those, however my install project with my EXE project detects the ones from my SQL Server installation.
Because of this, we have another machine that has the "Externals" folder with SMO Objects, but the install project won't find the SMO objects from 'Detected Dependancies' anymore as it's not realising the SMO Objects are in the externals module! I'm not sure where it searches for the Detected Dependancy files, but it's not looking at where X.dll originally picked them up from, or even the EXE folder perhaps...
您是否在最初创建部署项目后添加了此程序集依赖项？ 如果是这样，您可能需要右键单击“检测到的依赖项”文件夹并选择“刷新依赖项”。 它将拾取自上次执行此操作以来添加的任何新内容。
Did you add this assembly dependency after initially creating the deployment project? If so, you may need to right-click the Detected Dependencies folder and select Refresh Dependencies. It will pick up anything new that has been added since the last time you did this.
您是否尝试过在反射器中查看您的 dll，看看它是否确实依赖于其他 dll？ VS 足够聪明，如果它发现您实际上没有使用引用的程序集，它不会包含它。
除此之外，即使你“认为”你正在使用它，VS 也可以优化你的使用 - 这是一个极限情况，但我已经看到了：
例如，如果你有一个“常量”程序集，其中包含：
VS会将字符串直接粘贴到您的引用代码中。
除此之外，我建议删除并重建您的安装解决方案。
Have you tried looking at your dll in reflector to see if it really does depend on the other dll? VS is smart enough to not include a referenced assembly if it can see that you are not actually using it.
Added to that, even if you 'think' you're using it, VS can optimise away your use - this is a limit case but I have seen it:
For example, if you have a 'constants' assembly with this in:
VS will stick the string directly in your referencing code.
Beyond that, I'd suggest deleting and rebuilding your install solution.
我还没有使用过 Visual Studio 2008，但是在 2005 年，您必须验证项目上缺少的引用是否将“复制本地”属性设置为 true。
这会将丢失的文件复制到输出目录。
I have not used Visual Studio 2008 yet, however in 2005 you have to verify that the missing reference on the project has the Copy Local property set to true.
This will copy the missing file to the output directory.
除了 hectorsq 的响应之外，还要验证依赖关系是否位于部署项目依赖关系列表中，并且相关 DLL 是否已标记为包含在内。
In addition to hectorsq's response, verify that the depedency is in the deployment project dependencies list, and that the DLL in question is marked to be included.
我可以证实这对我们来说也是一个问题。 我怀疑这是部署项目中的一个错误 - 它只在一个位置添加依赖项目输出（也许它认为它是一个 COM dll？）
手动添加缺少的 dll 的主输出似乎是一种可行的解决方法。
I can verify this is an issue for us as well. I suspect it's a bug in the deployment project - it only adds dependent project output in one location (maybe it thinks it's a COM dll?)
Manually adding Primary Output for the missing dll seems to be a viable workaround.
在重现相同的可疑 msi 缺陷后，我还有一些需要补充的内容。
1）当我将共享相同检测到的依赖项的第二个项目输出添加到安装程序时，它不会自动添加依赖项。 我删除了两个项目输出并以相反的顺序将它们添加回来。 添加的第二个项目输出从未添加检测到的依赖项。 这排除了项目的任何配置或代码问题以及如何添加引用。 失败的总是第二个。
2）我的团队在使用“手动添加检测到的程序集”解决方法后实际上遇到了第二个问题。 最初，我们从“\Program Files\xxx”中的位置添加了依赖项，但在 64 位计算机上遇到了构建问题，其中相同的依赖项位于“\Program Files (x86)\xxx”文件夹中，尽管 VS 足够智能，可以在获取参考文献时处理这个问题。
I have a couple more things to add after reproducing the same suspected msi defect.
1) When I added the second project output sharing the same detected dependency to the installer it did not automatically add the dependency. I removed both project output's and added them back in reverse order. The second project output added never added the detected dependency. This excludes any configuration or code issue with the projects and how the references were added. It's always the second one that fails.
2) My team actually hit a second problem after using the 'Manually add detected assembly' workaround. Initially we added the dependency from the location in '\Program Files\xxx' but ran into build problems on 64 bit machines where that same dependency was in the '\Program Files (x86)\xxx' folder even though VS is smart enough to handle this problem when picking up references.