正在开发一个基于Web的应用程序，允许管理员上载插件。所有插件均存储在应用程序根目录之外的特殊文件夹中(例如C：\ Plugins)，并通过Assembly.LoadFrom()动态加载。这在大多数情况下都可以正常工作：实例化并加载插件中的WebControl，自定义类按预期运行，等等。

使用自定义VirtualPathProvider从这些插件中获取资源。因此，要获取嵌入式ASPX文件，只需/MySite/embeddedResource/?Assembly=MyPlugin&Resource=MyPage.aspx。而且效果也很好：嵌入式ASPX文件可以编译并像正常页面一样被提供。

但是，当嵌入式.aspx文件(在动态加载的插件内部)引用同一插件程序集中的类时，就会出现问题。我们收到类似编译错误的信息，找不到类型或者程序集MyPlugin。这很奇怪，因为很明显它会将.aspx文件从MyPlugin中拉出。那么怎么找不到呢？

因此，我希望我们能对此提供帮助。该插件如下所示：

MyPlugin.dll：

• InternalHelperClass.cs
• MyPage.aspx(无.cs文件的资源)

当MyPage.aspx包含<％= InternalHelperClass.WriteHelloWorld()％>之类的内容时，编译将失败。

我们如何才能使它正常工作？

更新：

我们尝试使用完全限定的名称。没有不同。
当我们转到aspx页面时，不可能逐步解决它是编译错误。
在这种情况下，命名空间将不是问题(因为它来自外部插件dll)

UPDATE2：

乔尔，我想你正在做某事。不幸的是，编辑web.config以包括这些程序集不是设计的一部分。基本上，我们希望插件是完全动态的，将其放置在文件夹中，重新启动应用程序，并准备就绪。

解决方案

我们是否尝试过完全限定helper类的名称空间？公开吗？是否在同一装配中？也许是在另一个程序集中，也必须加载它。

尝试进入代码并检查InternalHelperClass的类型。较新的"网站"编译方法通常会添加我们不期望的名称空间。例如。网页的类具有名称空间ASP.MyWebPage。有时，根据命名空间所在的文件夹添加命名空间。

我从未尝试过这样做，但是我怀疑ASPX页(尽管是从插件程序集加载的)正在ASP.NET环境中编译，而ASP.NET环境没有引用插件程序集，这将解释为什么完全合格名称不起作用。

我们是否尝试过将对MyPlugin.dll的引用添加到web.config文件中的compiling / assemblies标记中？

Assembly.LoadFrom是动态的(后期绑定)，这意味着在编译期间不包括该类型，因此对其包含的类的引用无效。我们需要专门引用该程序集，以便将该程序集作为* .aspx类的编译的一部分包括在内。

我们可能会在这里找到一些有用的源代码，我建议我们尝试一下Managed Extensibility Framework，因为它可能已经解决了此问题。

更新：我发现我认为是我们问题的答案。虽然这在ASP.NET 1.1项目中不起作用，但在2.0+中将适用。他们已经重组了构建管道，以使用可以在配置文件(web.config)中指定的BuildProvider。尽管我们必须编写自己的生成提供程序，但是可以在编译之前使它自动引用Plugins文件夹中的所有程序集。这里是有关配置的信息，这是我们需要对其进行子类化的内容。

这是Mono的PageBuildProvider的源代码的过期副本，我们需要从MS的共享源中检查ASP.NET的最新实现，将其复制，并使用自定义程序集引用对其进行扩展，因为该类不幸地是密封的(但看起来并不复杂)。