编译/嵌入 ASCX 模板化 UserControls 以在多个 Web 应用程序中重用
我在这里遇到了一个真正令人头疼的问题……它似乎是 ASP.NET 中最令人沮丧的主题之一。
我有一个程序集，它实现了很多自定义 Linq 内容，其核心是零 Web 功能。 我有一个附加程序集，可以使用特定于网络的行为扩展此程序集。
Web 特定行为附带在 ASCX 模板化用户控件内标记的几个用户控件。
我无法对该程序集进行良好的处理，以便可以轻松地重新部署以在其他应用程序中使用。 让我回顾一下到目前为止我所尝试过的操作：
- 使用构建事件将 ASCX 文件复制到使用的 Web 应用程序； 远非理想，部署噩梦。
- 实现了自定义 VirtualPathProvider 并将 ASCX 模板作为嵌入式资源嵌入到程序集中。 不幸的是，当在消费应用程序中使用 Register 指令时，它会将设计器声明创建为 UserControl，其中我需要实际控件类型的声明； （通常）不可预见且不可取的。
- 创建了一个 Web 部署项目来编译 UserControl，但编译后的用户控件随后成为另一个程序集的一部分，并且不再从我的 Web 程序集中的类定义派生 -程序集需要实例化它们，依赖于请求上下文。
因此，第 1 点只是废话，第 2 点没有给我我想要的类型支持，而第 3 点我想我将产生一个合理的解决方案：
- 将所有非控制类集中到 App_Code 中> 文件夹，准备一个工厂类，它将使用反射构造所需控制类型的对象，并期望所反射的类型将出现在部署输出中（希望通过
ClassName的存在来保证）Control指令中的属性）。
还有另一种选择，将 ASCX 控件重写为自定义控件，但目前没有资源来考虑它，而且我们没有这方面的专业知识，而且它们作为用户控件工作得很好。
我是否遗漏了一些明显的东西，一些可能更简单的东西，或者这只是故意困难的？ 在我浏览该主题的过程中，我读到过有关 ASP.NET 编译过程的设计非常不幸的故事。
I'm onto a real head scratcher here ... and it appears to be one of the more frustrating topics of ASP.NET.
I've got an assembly that implements a-lot of custom Linq stuff, which at it's core has zero web functionality. I have an additional assembly that extends this assembly with web specific behaviour.
The web specific behaviour comes with a couple of user controls marked up inside ASCX templated UserControls.
I'm having trouble putting a nice finish on this assembly so that it is simple to redeploy for use in other applications. Let me run through what I've tried so far:
- Copied the ASCX files to the consuming web application using build events; far from ideal and quite a deployment nightmare.
- Implemented a custom VirtualPathProvider and embedded the ASCX templates within the assembly as embedded resources. Unfortunately when using the Register directive in the consuming application it creates the designer declaration as a UserControl, where I would require a declaration of the actual control type; unforeseen (typically) and undesirable.
- Created a Web Deployment Project to compile the UserControls, but the compiled user controls then become part of another assembly, and no longer descend from the class definitions in my web assembly--the assembly needs to instantiate them dependent on the request context.
So number 1 is just crap, number 2 doesn't give me the type support I desire and number 3 I think I'm about to produce a reasonable solution with:
- Lump all non-control classes into the
App_Codefolder, prepare a factory class that will construct an object of the desired control type using reflection and the expectation that the type being reflected will be present in the deployment output (hopefully guaranteed by the presence of theClassNameattribute in theControldirective).
Theres also always the other option of rewriting the ASCX controls into custom controls, but just don't have the resources to consider it at the moment, and we've got no expertise in doing that, and they work fine as UserControls.
Am I missing something obvious, something maybe much simpler, or is this just purposefully difficult? I've read stories of the ASP.NET compilation process being very unfortunate in it's design on my travels across this topic.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好吧，我想我已经做到了......通过注意我最后一种方法中的一些恼人的陷阱，在使用 Web 部署项目在 Web 应用程序项目中编译 ASCX 用户控件时，我建议执行以下操作：
App_Code中，除非它们是独立类或辅助类，否则 ASP.NET 会将其视为 speshul 文件夹，我不明白其含义，随之而来的是混乱、混乱和混乱。 不过，此文件夹中的代码确实会在 Web 部署项目中获得输出。aspnet_merge访问被拒绝错误> 过程。..Web.DLL ..Web.UI.DLL bin和obj路径是否已清除以前在您可能尚未最终确定命名空间或程序集命名时构建的垃圾内容方案——Web 部署项目将非常热衷于包含这些方案，从而造成混乱。Import指令，并且它还会考虑web.config中存在的导入命名空间的要有耐心，这很棘手！ 但最后你确实得到了一些不错的可重新分发的用户控件！
唷！
Well I think I've done it ... by being mindful of a few of a few annoying pitfalls with my last approach, I recommend the following when compiling ASCX user controls in a Web Application Project using a Web Deployment Project:
App_Codeunless they're standalone or helper classes, ASP.NET treats this as a speshul folder, the meaning of which is lost on me, mayhem, confusion and chaos follows. Code in this folder does get output in the Web Deployment Project, though.access is deniederrors if you have any naming conflicts during theaspnet_mergeprocess.<Organisation>.<TechnologyName>.Web.DLL- Compiled Web Application Assembly (containing the ASCX templates)<Organisation>.<TechnologyName>.Web.UI.DLL- ASP.NET Compiled UserControl assembly, created by Web Deployment Projectbinandobjpaths are cleared of any previous junk built when you perhaps hadn't finalised your namespace or assembly naming scheme--the Web Deployment Project will be quite keen to include these, causing a fine mess.Importdirective in the ASCX template, and it also considers imported namespaces present inweb.config's<configuration><system.web><pages><namespaces>element, tweak if you get unknown definitions appearing during the deployment process.Have some patience spare, it's quite tricky! But you do get some nice re distributable UserControls at the end of it!
Phew!