1

我的解决方案中有以下可执行文件的输出结构：

%程序文件%
    |
    +-[我的应用程序名称]
          |
          +-[客户]
          | |
          | +-(EXE & 几个 DLL 程序集)
          |
          +-[常用]
          | |
          | +-[架构程序集]
          | | |
          | | +-（几个 DLL 程序集）
          | |
          | +-（几个 DLL 程序集）
          |
          +-[服务器]
                |
                +-(EXE & 几个 DLL 程序集)

解决方案中的每个项目都引用了不同的 DLL 程序集，其中一些是解决方案中其他项目的输出，而另一些则是普通的第 3 方程序集。例如，[Client] EXE 可能会引用 [Common] 中的程序集，该程序集位于不同的目录分支中。

所有引用都将“复制本地”设置为 false，以反映最终安装的应用程序中文件的布局。

现在，如果我查看 Visual Studio IDE 中的引用属性，我会发现每个引用的“路径”都是绝对的，并且它对应于程序集的实际输出位置。这是可以理解和正确的。正如预期的那样，解决方案编译并运行得很好。

我不明白的是，为什么即使我关闭 IDE，重命名 [MyAppName] 目录并手动运行 [Client] EXE，一切似乎都正常？如果引用路径与链接时的路径不同，运行时如何找到程序集？

需要明确的是 - 这实际上正是我所追求的：一组半分散的应用程序文件，无论 [MyAppName] 目录位于何处，甚至它的名称如何，都能正常运行。我只想知道，在我没有任何特定路径解决方案的情况下，它是如何以及为什么起作用的。

我已经阅读了这个类似问题的答案，但我仍然不明白。

非常感谢帮助！

4

4 回答 4

1

AFAIK 唯一的解决方案是在 MyAppBase 中至少有“存根”exe，然后在每个应用程序的 app.config 中将子目录定义为 DLL 的源。

NTFS 确实支持将其他目录（即硬链接）“挂载”为子目录，但它们是非常不自动的，因为除了理论化之外我没有尝试过这种方式，我不知道这是否可以作为一个黑客。

于 2009-04-25T10:13:13.950 回答
0

以下是 .Net 查找所需程序集的方式：http: //msdn.microsoft.com/en-us/library/yx7xezcf (VS.71).aspx

第 4 步可能会让您感兴趣：http: //msdn.microsoft.com/en-us/library/15hyw9x3 (VS.71).aspx

于 2009-01-20T12:51:33.743 回答
0

您是否考虑过使用GACutil将共享程序集添加到全局程序集缓存

于 2009-01-20T12:53:44.097 回答
0

也许Common文件夹在编译时被指定为binpath参数？

（请参阅探测私有 binpath）

http://msdn.microsoft.com/en-us/library/15hyw9x3%28VS.71%29.aspx

-马特

于 2010-05-05T02:00:11.067 回答