Le contrôle de mappage ASP.NET ne fonctionne plus avec .NET 4

Question

Je viens de mettre à niveau .NET 4 et mon contrôle graphique ASP.NET ne s'affiche plus.

Pour .NET 3.5, le code HTML produit par le contrôle utilisé pour ressembler à ceci:

<img id="20_Chart" src="/ChartImg.axd?i=chart_5f6a8fd179a246a5a0f4f44fcd7d5e03_0.png&amp;g=16eb7881335e47dcba16fdfd8339ba1a" alt="" style="height:300px;width:300px;border-width:0px;" /> 

et maintenant, pour 4 .NET, il ressemble à ceci (notez le changement dans le chemin source):

<img id="20_Chart" src="/Statistics/Summary/ChartImg.axd?i=chart_5f6a8fd179a246a5a0f4f44fcd7d5e03_0.png&amp;g=16eb7881335e47dcba16fdfd8339ba1a" alt="" style="height:300px;width:300px;border-width:0px;" /> 

Le tableau est dans une vue partielle MVC qui est dans un dossier zone MVC appelé « Statistiques » et Vues MVC dossier appelé « Résumé » (par exemple «/zones/Statistiques/Vues/Résumé »), donc c'est évidemment d'où vient le changement de chemin.

Tout ce que j'ai fait est de passer de l'assembly System.Web.DataVisualization de, 3.5 à 4.0.

Toute aide grandement appréciée.

Answer 1

Merci pour vos réponses, mais je ne pense pas que le mien était un IIS6/Problème IIS7.

Je retracée au fait que la valeur par défaut pour ImageStorageMode sur un ChartControl a changé UseImageLocation-UseHttpHandler. Mon ChartControl a maintenant quelques attributs supplémentaires et tout fonctionne bien.

<asp:Chart ... ImageStorageMode="UseImageLocation" ImageLocation="/Temp/ChartPic_#SEQ(300,3)"> 

je devais changer aussi le ImageLocation pour être non relative (en ajoutant /Temp/) comme cela a également causé un problème lorsque vous parcourez DataPoints du ChartControl dans un code-behind.

Answer 2

Nous avons rencontré le même problème sur IIS 6 après la mise à niveau d'ASP.NET 3.5 vers ASP.NET 4.0 avec ASP.NET MVC. Tout fonctionnait correctement sur IIS 7, mais IIS 6 nous a posé problème.

Le problème était que la propriété HttpContext.Current.Request.CurrentExecutionFilePath a donné un résultat différent dans IIS 6 et IIS 7:

• Url: /Controller.mvc/Action/1/2
• IIS 6: /Controller.mvc/Action/1/2
• IIS 7: /Controller.mvc

Ce qui a donné lieu à Urls pour les cartes comme:

• IIS 6: /Controller.mvc/Action/1/ChartImg.axd?i=chart_...
• IIS 7: /ChartImg.axd?i=chart_...

Le ChartHttpHandler a une fonction là-dedans qui calcule le chemin d'accès basé sur l'HttpContext.Current.Request.CurrentExecutionFilePath:

private static string GetHandlerUrl() 
{ 
    string str = Path.GetDirectoryName(HttpContext.Current.Request.CurrentExecutionFilePath ?? "").Replace(@"\", "/"); 
    if (!str.EndsWith("/", StringComparison.Ordinal)) 
    { 
     str = str + "/"; 
    } 
    return (str + "ChartImg.axd?"); 
} 

La façon dont ASP.NET UrlRewriting fonctionnait, puisque les chemins d'accès à ChartImg.axd contenaient encore .mvc, le gestionnaire MVC était invoqué à la place du gestionnaire Chart.

Il y avait 3 façons que nous avons trouvé pour y faire face (voir ci-dessous pour plus de détails):

1. Ajouter une carte de script explicite pour « .mvc » à ASP.NET 4.0 dll
2. Ajoutez un peu plus ne pas tenir compte de trajets à la table de routage pour couvrir les permutations
3. Substituer la execute() du contrôleur et le mettre dans une redirection au /ChartImg.axd

---

(1) Il s'avère que si nous avons ajouté une carte de script pour .mvc via IIS 6.0 pour .mvc la demande.CurrentExecutionFilePath obtiendrait calculé comme le chemin racine que nous voulions plutôt que comme le chemin plus profond

• IIS 6.0 Gestionnaire
• Propriétés -> Répertoire -> Configuration
• Mappages onglet
• Executable: c: \ WINNT \ microsoft.net \ Framework \ v4.0.30319 \ aspnet_isapi.dll, Extension: .mvc

---

(2) Nous avons constaté que ad ding certaines entrées de table de routage fonctionneraient, mais nous devions tenir compte de toutes les profondeurs possibles dans les chemins pour qu'ASP.NET MVC ignore le ChartImg.axd s'il était profondément intégré dans le chemin et non à la racine:

RouteTable.Routes.IgnoreRoute("{resource}.axd/{*pathInfo}"); 
RouteTable.Routes.IgnoreRoute("{a}/{resource}.axd/{*pathInfo}"); 
RouteTable.Routes.IgnoreRoute("{a}/{b}/{resource}.axd/{*pathInfo}"); 
RouteTable.Routes.IgnoreRoute("{a}/{b}/{c}/{resource}.axd/{*pathInfo}"); 
RouteTable.Routes.IgnoreRoute("{a}/{b}/{c}/{d}/{resource}.axd/{*pathInfo}"); 

---

(3) en redéfinissant Execute() sur tous nos contrôleurs en faisant un contrôleur de base que tous nos contrôleurs héritent, nous pourrions globalement remplacer Execute() pour tenir compte de cette situation et redirigent vers/ChartImg. axd

public partial class MyController: Controller 
    { 
     protected override void Execute(RequestContext cc) 
     { 
      // the url for chartimg.axd to be in the application root. /Controller.mvc/Action/Param1/ChartImg.axd gets here first, 
      // but we want it to go to /ChartImg.axd, in which case the IgnoreRoute does work and the chart http handler does it's thing. 
      if (cc.HttpContext.Request.Url.AbsoluteUri.Contains("ChartImg.axd")) 
      { 
       var url = new UriBuilder(cc.HttpContext.Request.Url); 
       url.Path = "/ChartImg.axd"; 
       cc.HttpContext.Response.Redirect(url.ToString()); 
       return; 
      } 
     } 
    } 

Answer 3

Alors que la solution @ Michael est informative sur la Si le problème existe, il existe une solution plus simple. Lors de l'enregistrement des routes dans vos contrôleurs à gérer Global.asax.cs, vous pouvez ajouter une route ignorée avec un contstraint, comme suit:

protected void Application_Start() { 
    ... 
    RouteTable.Routes.Ignore("{*pathInfo}", new { pathInfo = @"^.*(ChartImg.axd)$" }); 
    ... 
}