了解 Web.config 文件中的 ASP.NET 程序集引用管理
我有一个简单的疑问：我有一个想要引用的外部程序集。我有一个 Asp.Net 应用程序。我想在我的 Asp.Net 应用程序中使用该程序集。
我添加了一个引用，VS 所做的只是将我的 dll 放在我网站的 Bin 子目录中。
我认为 VS 会修改我的 web.config 文件添加外部引用...... 那么只有在引用 GAC 中的程序集时才会发生这种情况吗？ （考虑到需要公共令牌和版本，这是有道理的）。
谢谢
I have a simple doubt: I have an external assembly that I want to reference. I have an Asp.Net application. I want to use that assembly in my Asp.Net application.
I add a reference and what VS does is just placing my dll in the Bin subdirectory of my web site.
I thought that VS would have modified my web.config file adding external references...
So does it happen only when referencing assemblies in GAC??? (which makes sense given that public tokens and versions are required).
Thankyou
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当 CLR 加载程序集以供执行时，它会检查程序集的清单以确定其运行需要哪些依赖项。它通过一系列步骤来执行此操作：
检查重定向 - 如果程序集是强命名的，CLR 将首先检查适当的配置（
app.config、web.config等）以查看是否指定了任何绑定重定向。绑定重定向允许 CLR 说，我应该在哪里加载 v1.0.0.0，而不是加载 v2.0.0.0。如果没有找到强名称程序集的绑定重定向，它将检查 GAC 中的策略文件，如果没有找到策略文件，它将检查machine.config。如果未指定绑定重定向，则 CLR 将使用调用程序集清单中指定的程序集名称来加载程序集。检查程序集是否已加载 - CLR 确定该程序集之前是否已加载，如果已加载，则使用相同的加载程序集，否则继续...< /p>
CodeBase - 如果 CLR 仍然找不到该程序集，它将使用
codeBase路径尝试查找该程序集。探测 - 如果 CLR 仍然找不到程序集，它将检查程序集的探测路径。默认探测路径是当前正在加载程序集的
AppDomain的应用程序基本路径。（这一切都改编自一篇名为 的精彩文章了解 .Net 程序集和引用）。
对于您的 Web 应用程序，CLR 仍然执行上述所有操作，但
AppDomain应用程序基本路径是 IIS 应用程序中的/bin文件夹。When the CLR loads your assembly for execution, it checks the assembly's manifest to determine what dependencies are required for it to run. It goes through a series of steps to do this:
Check for redirects - if the assembly is strongly-named, the CLR will first check the appropriate config (
app.config,web.config, etc.) to see if there are any binding redirects specified. A binding redirect allows the CLR to say, where I am supposed to load v1.0.0.0, instead load v2.0.0.0. If no binding redirect is found for a strongly-named assembly, it will check a policy file in the GAC, and if no policy file is found, it checks themachine.config. If no binding redirect is specified, the CLR will use the assembly name specified in the calling assembly's manifest to load the assembly.Check to see if the assembly has already been loaded - the CLR determines if the assembly has previously been loaded, if it has, it uses that same loaded assembly, otherwise it continues...
Load the assembly from the GAC - If the assembly could not previously be loaded and is strongly-named, the CLR will attempt to load the assembly from the Global Assembly Cache.
CodeBase - If the CLR still can't find the assembly, it will use the
codeBasepath to try and locate the assembly.Probing - If the CLR still can't find the assembly, it will check the probing path for the assembly. The default probing path is the application base path of the
AppDomaininto which assemblies are currently being loaded.(That's all adapted from a great article called Understanding .Net Assemblies and References ).
In the case of your web application, the CLR still does all of the above, but the
AppDomainapplication base path is the/binfolder within your IIS application.