将路由与网络表单一起使用 - CreateInstanceFromVirtualPath 有时非常慢

发布于 2024-09-18 18:34:22 字数 1520 浏览 3 评论 0 原文

我正在我的 ASP.NET WebForms 应用程序中使用路由,使用 Phil Haack 描述的技术:

这在大多数情况下效果很好,但是有时首次调用 System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath 需要数十秒才能返回。

这种情况发生在以下方法中:

public IHttpHandler GetHttpHandler(RequestContext requestContext)
{
    LapTimer lapTimer = new LapTimer();

    string virtualPath = this.GetSubstitutedVirtualPath(requestContext, lapTimer);
    if (this.CheckPhysicalUrlAccess && !UrlAuthorizationModule.CheckUrlAccessForPrincipal(virtualPath, requestContext.HttpContext.User, requestContext.HttpContext.Request.HttpMethod))
        throw new SecurityException();

    IHttpHandler page = BuildManager.CreateInstanceFromVirtualPath(virtualPath, typeof(Page)) as IHttpHandler;
    if (page != null)
    {
        //Pages that don't implement IRoutablePage won't have the RequestContext
        //available to them. Can't generate outgoing routing URLs without that context.
        var routablePage = page as IRoutablePage;
        if (routablePage != null)
            routablePage.RequestContext = requestContext;
    }

    return page;
}

与此同时,我注意到(使用任务管理器)有一个名为 csc.exe,C# 编译器,占用了我的 CPU 的 10%-50%。

谁能建议为什么会发生这种情况?

I am using routing with my ASP.NET WebForms application, using the technique described by Phil Haack:

This works well most of the time, however on on occasion the first call to System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath is takes tens of seconds to return.

This happens in the following method:

public IHttpHandler GetHttpHandler(RequestContext requestContext)
{
    LapTimer lapTimer = new LapTimer();

    string virtualPath = this.GetSubstitutedVirtualPath(requestContext, lapTimer);
    if (this.CheckPhysicalUrlAccess && !UrlAuthorizationModule.CheckUrlAccessForPrincipal(virtualPath, requestContext.HttpContext.User, requestContext.HttpContext.Request.HttpMethod))
        throw new SecurityException();

    IHttpHandler page = BuildManager.CreateInstanceFromVirtualPath(virtualPath, typeof(Page)) as IHttpHandler;
    if (page != null)
    {
        //Pages that don't implement IRoutablePage won't have the RequestContext
        //available to them. Can't generate outgoing routing URLs without that context.
        var routablePage = page as IRoutablePage;
        if (routablePage != null)
            routablePage.RequestContext = requestContext;
    }

    return page;
}

At the same time as this I notice (using Task Manager) that a process called csc.exe, the C# compiler, is taking up 10%-50% of my CPU.

Can anyone suggest why this would be happening?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

明媚殇 2024-09-25 18:34:22

您的应用程序正在使用视图的运行时编译。虽然您的业务逻辑、代码隐藏等(基本上是任何 .cs 文件)由 Visual Studio 编译,但您的视图(*.aspx、*.ascx、*.Master)在首次请求给定视图时由 asp.net 运行时编译(即,BuildManager 被要求提供与给定虚拟路径相对应的对象)。这可能需要一些时间,因为视图可能会批量编译(例如,单个文件夹中的所有视图)。

如果您更改视图,它将重新编译。此外,如果应用程序域回收,所有视图编译都将失效(如果您对 web.config、global.asax 等进行更改,则可能会发生这种情况)。

所有这些都是 ASP.NET 中的正常行为。如果您发现这在您的场景中是不可接受的,您可以使用预编译应用程序。这将为您提供应用程序启动性能优势,但代价是能够轻松调整站点的标记,而无需重新编译所有内容。

Your application is using runtime compilation of views. While your business logic, codebehind etc (basically any .cs file) gets compiled by Visual Studio, your views (*.aspx, *.ascx, *.Master) are compiled by the asp.net runtime when a given view is first requested (i.e. the BuildManager is asked for an object that corresponds to a given virtual path). It might take some time because views might be compiled in batches (e.g. all views in a single folder).

A view will be recompiled if you change it. Also all view compilations will be invalidated if the App Domain recycles (which can happen if you make changes to web.config, global.asax, etc).

All this is normal behavior in ASP.NET. If you find that this is unacceptable in your scenarios you can use precompiled applications. This will provide you with app startup perf benefits at the cost of being able to easily tweak the markup of your site withouth having to recompile everything.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文