需要澄清:.NET运行时如何解析父文件夹中的程序集引用?

时间:2022-08-23 08:06:14

I have the following output structure of executables in my solution:

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

%ProgramFiles%
    |
    +-[MyAppName]
          |
          +-[Client]
          |     |
          |     +-(EXE & several DLL assemblies)
          |
          +-[Common]
          |     |
          |     +-[Schema Assemblies]
          |     |     |
          |     |     +-(several DLL assemblies)
          |     |
          |     +-(several DLL assemblies)
          |
          +-[Server]
                |
                +-(EXE & several DLL assemblies)

Each project in solution references different DLL assemblies, some of which are outputs from other projects in solution, and others are plain 3rd-party assemblies. For example, [Client] EXE might reference an assembly in [Common], which is in a different directory branch.

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

All references have "Copy Local" set to false, to mirror the layout of the files in the final installed application.

所有引用都将“Copy Local”设置为false,以镜像最终安装的应用程序中的文件布局。

Now, if I take a look at reference properties in the Visual Studio IDE, I see that "Path" of every reference is absolute and that it corresponds to the actual output location of the assembly. That's understandable and correct. As expected, solution compiles and runs just fine.

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

What I don't understand is, why everything seems to work even when I close the IDE, rename the [MyAppName] directory and run the [Client] EXE manually? How does the runtime find the assemblies if the reference paths aren't the same as they were at the time of linking?

我不明白的是,为什么一切似乎都工作,即使我关闭IDE,重命名[MyAppName]目录并手动运行[客户端] EXE?如果引用路径与链接时的引用路径不同,运行时如何查找程序集?

To be clear - this is actually exactly what I'm after: a semi-dispersed set of application files that run fine regardless of where the [MyAppName] directory is located or even what it's named. I'd just like to know, how and why this works without any specific path resolution on my part.

要清楚 - 这实际上就是我所追求的:一个半分散的应用程序文件集,无论[MyAppName]目录位于何处,甚至它的名称,它都能正常运行。我想知道,如果没有任何具体的路径解决方案,这是如何以及为什么这样做。

I've read the answers to this similar question, but I still don't get it.

我已经阅读了这个类似问题的答案,但我仍然没有得到它。

Help much appreciated!

非常感谢!

4 个解决方案

#1


AFAIK the only solution is to have at least "stub" exes in MyAppBase and then define subdirectories as sources for DLL's in app.config for each application.

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

NTFS does support "mounting" other directories (ie. hard links) as subdirectories, but they're very unautomatic and since I've not tried going that way except theoretizing, I can't tell if that would work as a hack.

NTFS确实支持“挂载”其他目录(即硬链接)作为子目录,但它们非常不自动,因为除了理论之外我没有尝试过这种方式,我无法判断它是否可以作为一个黑客。

#2


Here's how .Net finds the assemblies that are needed: http://msdn.microsoft.com/en-us/library/yx7xezcf(VS.71).aspx

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

Step 4 is what might be interesting for you to read: http://msdn.microsoft.com/en-us/library/15hyw9x3(VS.71).aspx

第4步是您可能感兴趣的内容:http://msdn.microsoft.com/en-us/library/15hyw9x3(VS.71).aspx

#3


Have you considered using GACutil to add your shared assemblies to the Global Assembly Cache

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

#4


Maybe the Common folder was specified as a binpath parameter when it was compiled?

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

(See Probing the Private binpath)

(请参阅探测专用binpath)

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

-Matt

#1


AFAIK the only solution is to have at least "stub" exes in MyAppBase and then define subdirectories as sources for DLL's in app.config for each application.

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

NTFS does support "mounting" other directories (ie. hard links) as subdirectories, but they're very unautomatic and since I've not tried going that way except theoretizing, I can't tell if that would work as a hack.

NTFS确实支持“挂载”其他目录(即硬链接)作为子目录,但它们非常不自动,因为除了理论之外我没有尝试过这种方式,我无法判断它是否可以作为一个黑客。

#2


Here's how .Net finds the assemblies that are needed: http://msdn.microsoft.com/en-us/library/yx7xezcf(VS.71).aspx

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

Step 4 is what might be interesting for you to read: http://msdn.microsoft.com/en-us/library/15hyw9x3(VS.71).aspx

第4步是您可能感兴趣的内容:http://msdn.microsoft.com/en-us/library/15hyw9x3(VS.71).aspx

#3


Have you considered using GACutil to add your shared assemblies to the Global Assembly Cache

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

#4


Maybe the Common folder was specified as a binpath parameter when it was compiled?

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

(See Probing the Private binpath)

(请参阅探测专用binpath)

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

-Matt