编译/嵌入ASCX模板用户控件，以便在多个Web应用程序中重用

Question

我在这里发现了一个真正的头脑......它似乎是ASP.NET中令人沮丧的主题之一。

我有一个程序集可以实现很多自定义Linq的东西，它的核心是零网络功能。我有一个额外的程序集，扩展此程序集具有Web特定的行为。

特定于Web的行为伴随着ASCX模板化UserControls中标记的几个用户控件。

我无法在此程序集上完成一个很好的结束，因此重新部署以便在其他应用程序中使用很简单。让我来看看到目前为止我尝试过的事情：

1. 使用构建事件将ASCX文件复制到使用中的Web应用程序; 远非理想和相当部署的噩梦。
   • 实现了自定义VirtualPathProvider，并将ASCX模板作为嵌入资源嵌入到程序集中。不幸的是，当在使用应用程序中使用Register指令时，它将设计器声明创建为UserControl，我需要声明实际的控件类型; 无法预料（通常）和不受欢迎的。
   • 创建了一个Web部署项目来编译UserControls，但编译后的用户控件随后成为另一个程序集的一部分，而不再是我的Web程序集中的类定义 - 程序集需要依赖于它们来实例化它们请求上下文。

所以数字1只是废话，数字2不给我我想要的类型支持和数字3我认为我将要产生一个合理的解决方案：

• 将所有非控件类集成到App_Code文件夹中，准备一个工厂类，该工厂类将使用反射构造所需控件类型的对象，并期望反映的类型将出现在部署输出中（希望通过ClassName指令中Control属性的存在来保证。

Theres也总是将ASCX控件重写为自定义控件的另一种选择，但目前没有资源可以考虑它，而且我们没有这方面的专业知识，并且它们可以正常工作，如UserControls

我是否遗漏了一些明显的东西，可能更简单的东西，或者这只是有目的的困难？我已经阅读过关于ASP.NET编译过程的故事，这个故事在我的旅行中的设计非常不幸。

Answer 1

嗯，我认为我已经完成了......通过注意我最后一种方法中的一些烦人的陷阱，我建议在使用Web部署项目在Web应用程序项目中编译ASCX用户控件时进行以下操作：

1. 避免将类放在App_Code中，除非它们是独立类或辅助类，ASP.NET将其视为 speshul 文件夹，其含义在我身上丢失，混乱，混乱然后是混乱。但是，此文件夹中的代码确实会在Web部署项目中输出。
   • 密切关注程序集名称，根命名空间和部署输出程序集名称 - 如果access is denied进程中存在任何命名冲突，则会出现aspnet_merge错误。
   • 最终，您最有可能最终部署2个程序集，我尝试只创建一个，但部署输出仍指向源程序集中的类型定义。如果您的Web应用程序项目中没有任何其他类型，这不是问题 - 我这样做对我来说是一个问题。在我的情况下，我的最终输出是：
   • <Organisation>.<TechnologyName>.Web.DLL - 编译的Web应用程序程序集（包含ASCX模板）
   • <Organisation>.<TechnologyName>.Web.UI.DLL - 由Web部署项目
   创建的ASP.NET编译的UserControl程序集
   • 经常清理，并检查Web应用程序项目的bin和obj路径是否已清除在您可能尚未完成命名空间或程序集命名方案时构建的任何先前的垃圾 - Web部署项目将非常热衷于包括这些，导致一个混乱。
   • 检查导入的命名空间，ASP.NET编译器喜欢引用ASCX模板中的Import指令，它还会考虑web.config的{​​{1}}元素中存在的导入的命名空间，如果在部署过程中出现未知定义，请进行调整。

有一些耐心，这很棘手！但是你最终会得到一些很好的可重新分发的UserControls！

呼！