2010-09-10 7 views
2

J'utilise le routage avec mon application ASP.NET WebForms, en utilisant la technique décrite par Phil Haack:de routage avec webforms Utilisation - CreateInstanceFromVirtualPath parfois très lent

Cela fonctionne bien la plupart des l'heure, mais à l'occasion le premier appel à System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath prend des dizaines de secondes pour revenir.

Cela se produit dans la méthode suivante:

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; 
} 

En même temps que cela, je l'avis (en utilisant le Gestionnaire des tâches) qu'un processus appelé csc.exe, le compilateur C#, prend en hausse de 10% à 50% de mon processeur.

Quelqu'un peut-il suggérer pourquoi cela se produirait?

Répondre

2

Votre application utilise la compilation de vues d'exécution. Alors que votre logique métier, codebehind etc. (en gros n'importe quel fichier .cs) est compilé par Visual Studio, vos vues (* .aspx, * .ascx, * .Master) sont compilées par le runtime asp.net lorsqu'une vue donnée est demandée (c'est-à-dire que le BuildManager est demandé pour un objet qui correspond à un chemin virtuel donné). Cela peut prendre un certain temps car les vues peuvent être compilées par lots (par exemple, toutes les vues dans un seul dossier).

Une vue sera recompilée si vous la modifiez. Toutes les compilations de vue seront également invalidées si le domaine de l'application recycle (ce qui peut arriver si vous apportez des modifications à web.config, global.asax, etc.).

Tout ce comportement est normal dans ASP.NET. Si vous trouvez que c'est inacceptable dans vos scénarios, vous pouvez utiliser precompiled applications. Cela vous fournira des avantages de perf de démarrage de l'application au coût d'être en mesure de modifier facilement le balisage de votre site sans avoir à tout recompiler.

+0

J'ai essayé ceci, et il appelle 'aspnet_compiler.exe', plutôt que' csc.exe' ... –

+0

Même la précompilation laissera des bouts .aspx sur le serveur pour qu'ASP.NET sache comment les manipuler, ce qui serait provoque l'exécution de 'aspnet_compiler.exe'. Cependant, cela ne devrait pas prendre autant de temps. Combien de fichiers avez-vous et combien de temps cela prend-il? Comme je l'ai dit plus tôt, il s'agit d'un comportement ASP.NET normal, à moins que cela ne prenne un caractère déraisonnable. Btw, même si vous n'utilisez pas de sites précompilés, le fichier 'aspnet_compiler.exe' sera exécuté, suivi de' csc.exe'. – marcind