J'ai cette exception de type Son System.AccrégationException code>: InnerException code> est ce System.reflet. CibleInvocationException CODE>: P> <package id="Microsoft.AspNet.SignalR" version="1.0.1" targetFramework="net40" />
<package id="Microsoft.AspNet.SignalR.Core" version="1.0.1" targetFramework="net40" />
<package id="Microsoft.AspNet.SignalR.JS" version="1.0.1" targetFramework="net40" />
<package id="Microsoft.AspNet.SignalR.Owin" version="1.0.1" targetFramework="net40" />
<package id="Microsoft.AspNet.SignalR.SystemWeb" version="1.0.1" targetFramework="net40" />
3 Réponses :
Il semblait que le problème n'était pas lié à Signalr. Cela a à voir avec Je regardais le page MSDN de la méthode AGGEATEXception.getBaseException et j'ai trouvé ceci:
retourne la considération d'agrégate qui est la cause première de cette exception
alors je suppose que la documentation de exception.getbaseException méthode est valide uniquement si la méthode n'est pas remplacée. agrégatexceptions .
Selon msdn GetbaseException devrait se comporter comme et états Pour toutes les exceptions dans une chaîne d'exception, la méthode GetBaseException doit renvoyer le même objet (l'exception de base).
Qui pose la question, pourquoi cette méthode est-elle virtuelle? Il semblerait que tout dérogation ne puisse correspondre à la mise en œuvre ou enfreindre le contrat. Selon MSDN AggregateException.getBaseException Renvoie l'accompagnement des agrégats qui est la cause première de cette exception.
par la déclaration de l'OP (et l'inspection de la source), "renvoie l'agrégatexception" peut être violée car le résultat n'est pas toujours une exception d'agrégate. Franchement, je trouve la déclaration entière comme une non-séquiture, car je considérerais la «première» non-agrégateException à être «la cause fondamentale de cette exception» dans la mesure où on peut identifier une cause fondamentale singulière («la«). Étant donné que les exceptions "régulières", se déplacent simplement dans des impressions d'agrégates, car on se déplace vers la racine d'un traitement parallèle "fan" ". mon ma meilleure interprétation est que AggregateException.getBaseException est destiné à "Déplacez" des impressions imbriquées inutiles non parallèles non parallèles jusqu'à atteindre un niveau où "fan sorti" se produit réellement. Le bogue ici (plus tard fixé) semblerait être ce qui se passe quand il n'y a pas de «fan», c'est-à-dire une exception agrégate avec une seule exception (s) (s) (non agrégée). Dans ce cas, il renvoie cette exception (non agrégée). .... qui a une implémentation / interprétation de getBaseException différente. edit 2020: à un moment donné dans les années intermédiaires AggregateException.getBasException L'implémentation a été fixée pour correspondre à l'interprétation ci-dessus. @ Jan-Slodicka La réponse indique qu'il a été fixé au moins dans Mono dès 2016.
Ceci est le code source mono:
public override Exception GetBaseException() {
Exception back = this;
AggregateException backAsAggregate = this;
while (backAsAggregate != null && backAsAggregate.InnerExceptions.Count == 1) {
back = back.InnerException;
backAsAggregate = back as AggregateException;
}
return back;
}
Question étonnante. Exception à l'exception en raison d'une exception.
Un type d'exception doit être sérialisable s'il traverse une limite de contexte d'exécution. Aucune idée si c'est le cas pour Signalr, probablement.