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

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

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

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

>使用构建事件将ASCX文件复制到使用中的Web应用程序;远非理想和相当部署的噩梦.

>实现自定义VirtualPathProvider并将ASCX模板作为嵌入资源嵌入到程序集中.不幸的是,当在使用应用程序中使用Register指令时,它将设计器声明创建为UserControl,我需要声明实际的控件类型;不可预见的(通常)和不受欢迎的.
>创建了一个Web部署项目来编译UserControls,但编译后的用户控件随后成为另一个程序集的一部分,而不再是我的Web程序集中的类定义 – 程序集需要根据请求上下文实例化它们.

所以1号只是垃圾,2号不给我我想要的类型支持和3号我认为我即将产生一个合理的解决方案：

>将所有非控制类集成到App_Code文件夹中,准备一个工厂类,该工厂类将使用反射构造所需控件类型的对象,并期望反映的类型将出现在部署输出中(希望由于存在而保证Control指令中的ClassName属性.

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

我错过了一些明显的东西,有些东西可能更简单,或者这只是有目的的困难？我读过关于ASP.NET编译过程的故事非常不幸在我的旅行中设计了这个主题.

最佳答案 好吧,我想我已经做到了……通过注意我最后一种方法中的一些烦人的陷阱,我推荐以下在使用Web部署项目在Web应用程序项目中编译ASCX用户控件时：

>避免将类放在App_Code中,除非它们是独立类或辅助类,ASP.NET将其视为一个speshul文件夹,其含义在我身上丢失,混乱,混乱和混乱.但是,此文件夹中的代码确实会在Web部署项目中输出.

>密切关注程序集名称,根名称空间和部署输出程序集名称 – 如果在aspnet_merge进程中有任何命名冲突,您将获得访问被拒绝错误.
>最终,您最有可能最终部署2个程序集,我尝试只创建一个,但部署输出仍然指向源程序集中的类型定义.如果您的Web应用程序项目中没有任何其他类型,这不是问题 – 我这样做对我来说是一个问题.在我的情况下,我的最终输出是：
>< Organization>.< TechnologyName> .Web.DLL – 编译的Web应用程序程序集(包含ASCX模板)
>< Organization>.< TechnologyName> .Web.UI.DLL – 由Web部署项目创建的ASP.NET编译的UserControl程序集
>经常清理,并检查Web应用程序项目的bin和obj路径是否清除了在您可能尚未完成命名空间或程序集命名方案时构建的任何先前的垃圾 – Web部署项目将非常热衷于包含这些,导致一团糟.
>检查导入的命名空间,ASP.NET编译器喜欢引用ASCX模板中的Import指令,它还会考虑web.config的< configuration>< system.web>< pages><>中存在的导入的命名空间.命名空间> element,如果在部署过程中出现未知定义,则进行调整.

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

唷！