代码之家  ›  专栏  ›  技术社区  ›  Rabid

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

virtualpathprovider ascx web-deployment-project asp.net
  •  4
  • Rabid  · 技术社区  · 17 年前

    我真的很头疼。。。这似乎是ASP.NET中更令人沮丧的话题之一。

    特定于web的行为附带了几个在ASCX模板化UserControls中标记的用户控件。

    我很难对这个程序集进行良好的修饰,这样就很容易重新部署以用于其他应用程序。让我回顾一下我迄今为止所做的尝试:

    1. 使用构建事件将ASCX文件复制到消费web应用程序; 这远非理想,而且是一场部署噩梦 .
      • 实现了一个自定义VirtualPathProvider,并将ASCX模板作为嵌入式资源嵌入到程序集中。不幸的是,当在消费应用程序中使用Register指令时,它会将设计器声明创建为UserControl,在这里我需要实际控件类型的声明; 不可预见(通常)和不受欢迎的
      • 程序集需要根据请求上下文实例化它们 .

    • 将所有非控制类合并到 App_Code 文件夹中,准备一个工厂类,该类将使用反射构造所需控件类型的对象,并期望所反射的类型将出现在部署输出中(希望通过 ClassName Control 指令)。

    我是否遗漏了一些明显的、可能更简单的东西,或者这只是故意的困难?关于ASP.NET编译过程的设计,我在本主题的旅行中读到过一些非常不幸的故事。

    1 回复  |  直到 17 年前
        1
  •  2
  •   Rabid    17 年前

    我想我已经做到了。。。在使用Web部署项目在Web应用程序项目中编译ASCX用户控件时,请注意上一种方法中的一些恼人的陷阱,我建议如下:

    1. 避免在课堂上上课 App_Code 除非它们是独立类或帮助类,否则ASP.NET会将其视为 斯佩舒尔 文件夹,其意义在我身上消失了,混乱、混乱和混乱随之而来。不过,此文件夹中的代码确实会在Web部署项目中获得输出。
      • access is denied 如果在测试过程中出现任何命名冲突,则会出现错误 aspnet_merge 过程
      • 最终您很可能会部署2个程序集,我尝试只创建一个,但部署输出仍然指向源程序集中的类型定义。如果您的Web应用程序项目中没有任何其他类型,那么这不是问题——我有,所以这对我来说是个问题。就我而言,我的最终输出是:
      • <Organisation>.<TechnologyName>.Web.DLL -已编译的Web应用程序集(包含ASCX模板)
      • <Organisation>.<TechnologyName>.Web.UI.DLL
      • 经常清理,并检查Web应用程序项目 bin 和 obj
      • 检查导入的名称空间,ASP.NET编译器喜欢引用 Import 指令,它还考虑中存在的导入命名空间 web.config 的 <configuration><system.web><pages><namespaces> 元素,如果在部署过程中出现未知定义,则进行调整。

    有点耐心,这很棘手!但最后你会得到一些不错的可重新分发的用户控件!

    呸!

    推荐文章
    关于   移动版
    代码之家 - 一站式码农服务社区
    沪ICP备11025650号