TypeLoadException dit 'pas d'implémentation', mais c'est implémenté
J'ai un bug très étrange sur notre machine de test. L'erreur est:
System.TypeLoadException: Method 'SetShort' in type 'DummyItem' from Assembly 'ActiveViewers (...)' does not have an implementation.
Je n'arrive pas à comprendre pourquoi. SetShort est présent dans la classe DummyItem et j'ai même recompilé une version avec des écritures dans le journal des événements simplement pour m'assurer qu'il ne s'agit pas d'un problème de déploiement/de version. La chose étrange est que le code appelant n'appelle même pas la méthode SetShort.
NOTE- Si cette réponse ne vous aide pas, prenez le temps de faire défiler les autres réponses ajoutées depuis.
Réponse courte
Cela peut arriver si vous ajoutez une méthode à une interface dans un assembly, puis à une classe d'implémentation dans un autre assembly, mais que vous reconstruisez l'assembly d'implémentation sans faire référence à la nouvelle version de l'assembly d'interface.
Dans ce cas, DummyItem implémente une interface à partir d'un autre assembly. La méthode SetShort a récemment été ajoutée à l'interface et au DummyItem - mais l'assembly contenant DummyItem a été reconstruit en faisant référence à la version précédente de l'assembly d'interface. Donc, la méthode SetShort est effectivement là, mais sans la sauce magique qui la relie à la méthode équivalente dans l'interface.
Longue réponse
Si vous voulez essayer de reproduire cela, essayez ce qui suit:
Créez un projet de bibliothèque de classes: InterfaceDef, ajoutez une seule classe et construisez:
public interface IInterface { string GetString(string key); //short GetShort(string key); }Créez un deuxième projet de bibliothèque de classes: implémentation (avec solution séparée), copiez InterfaceDef.dll dans le répertoire du projet et ajoutez-le comme référence de fichier, ajoutez une seule classe et générez:
public class ImplementingClass : IInterface { #region IInterface Members public string GetString(string key) { return "hello world"; } //public short GetShort(string key) //{ // return 1; //} #endregion }Créez un troisième projet de console: ClientCode, copiez les deux dll dans le répertoire du projet, ajoutez des références de fichier et ajoutez le code suivant dans la méthode Main:
IInterface test = new ImplementingClass(); string s = test.GetString("dummykey"); Console.WriteLine(s); Console.ReadKey();Exécutez le code une fois, la console affiche "hello world"
Décommentez le code dans les deux projets de DLL et reconstruisez - recopiez les deux DLL dans le projet ClientCode, reconstruisez et essayez à nouveau. Une exception TypeLoadException se produit lors de la tentative d'instanciation de ImplementingClass.
En plus de ce que le demandeur a déjà dit dans sa propre réponse, il convient de noter ce qui suit. La raison en est qu’il est possible pour une classe d’avoir une méthode avec la même signature en tant que méthode d’interface sans implémenter cette méthode. Le code suivant illustre cela:
public interface IFoo
{
void DoFoo();
}
public class Foo : IFoo
{
public void DoFoo() { Console.WriteLine("This is _not_ the interface method."); }
void IFoo.DoFoo() { Console.WriteLine("This _is_ the interface method."); }
}
Foo foo = new Foo();
foo.DoFoo(); // This calls the non-interface method
IFoo foo2 = foo;
foo2.DoFoo(); // This calls the interface method
Je l'ai eu lorsque mon application n'avait pas de référence à un autre assembly définissant une classe utilisée par la méthode dans le message d'erreur. L'exécution de PEVerify a généré une erreur plus utile: "Le système ne peut pas trouver le fichier spécifié."
Je suis tombé sur le même message et voici ce que nous avons trouvé: Nous utilisons des dll tierces dans notre projet. Après une nouvelle version de ceux-ci, nous avons modifié notre projet pour qu'il pointe vers le nouvel ensemble de DLL et soit compilé avec succès.
L’exception a été levée lorsque j’ai essayé d’instancier l’une de leurs classes interfacées en cours d’exécution .. Nous nous sommes assurés que toutes les autres références étaient à jour, mais nous n’avons toujours pas eu de chance .. Nous avions besoin d’un certain temps utilisant le navigateur d’objets) que le type de retour de la méthode dans le message d’erreur était un type complètement nouveau issu d’un nouvel assembly non référencé.
Nous avons ajouté une référence à l'Assemblée et l'erreur a disparu.
- Le message d'erreur était assez trompeur, mais indiquait plus ou moins la bonne direction (bonne méthode, mauvais message).
- L'exception s'est produite même si nous n'avons pas utilisé la méthode en question.
- Ce qui m'amène à la question: si cette exception est levée, pourquoi le compilateur ne la détecte-t-elle pas?
J'ai reçu cette erreur dans le scénario suivant.
- Les ensembles A et B ont tous deux référencé System.Web.Mvc Version 3.0.0.0.
- Assembly A référencé Assembly B et avait des classes qui implémentaient des interfaces de Assembly B avec des méthodes renvoyant des classes de System.Web.Mvc.
- Assembly A mis à niveau vers System.Web.Mvc version 4.0.0.0
- L'Assemblée C a exécuté le code ci-dessous (FertPin.Classes.Contact était contenu dans l'Assemblée A):
var target = Assembly.GetAssembly(typeof(FertPin.Classes.Contact));
Le correctif pour moi consistait à mettre à niveau la référence System.Web.Mvc dans Assembly B vers 4.0.0.0. Cela semble évident maintenant!
Merci à l'affiche originale!
L'autre fois où vous pouvez obtenir cette erreur est si vous avez une version incorrecte d'un assembly signé. Ce n'est pas le symptôme normal de cette cause, mais voici le scénario où je l'ai eu
un projet asp.net contient Assembly A et Assembly B, B est fortement nommé
L'assembly A utilise Activator.CreateInstance pour charger l'assembly C (c'est-à-dire qu'il n'y a aucune référence à C qui est construit séparément)
C a été construit en faisant référence à une version plus ancienne de Assembly B que celle actuellement présente
j'espère que cela aide quelqu'un - il m'a fallu un temps fou pour comprendre cela.
J'ai eu cette erreur aussi, elle a été causée par un CPU exe référencant tous les assemblys de CPU qui à leur tour référencé un Assembly x86.
L'exception se plaignait d'une méthode sur une classe dans MyApp.Implementations (Any CPU), à l'origine de MyApp.Interfaces (Any CPU), mais dans fuslogvw.exe, j'ai trouvé une "tentative de chargement de programme avec un format incorrect" de MyApp. .CommonTypes (x86) qui est utilisé par les deux.
J'ai rencontré cette erreur dans un contexte où j'utilisais Autofac et beaucoup de chargement dynamique d'Assembly.
Lors de l'exécution d'une opération de résolution Autofac, le moteur d'exécution ne parviendrait pas à charger l'un des assemblys. Le message d'erreur s'est plaint que Method 'MyMethod' in type 'MyType' from Assembly 'ImplementationAssembly' does not have an implementation. Les symptômes se sont produits lors de l'exécution sur une machine virtuelle Windows Server 2012 R2, mais pas s'est-il produit sur des machines virtuelles Windows 10 ou Windows Server 2016.
ImplementationAssembly référencé System.Collections.Immutable 1.1.37 et contenait les implémentations d'une interface IMyInterface<T1,T2>, définie dans une variable DefinitionAssembly. DefinitionAssembly référencé System.Collections.Immutable 1.1.36.
Les méthodes de IMyInterface<T1,T2> qui étaient "non implémentées" avaient des paramètres de type IImmutableDictionary<TKey, TRow>, définis dans System.Collections.Immutable.
La copie réelle de System.Collections.Immutable trouvée dans le répertoire du programme était la version 1.1.37. Sur ma machine virtuelle Windows Server 2012 R2, le GAC contenait une copie de System.Collections.Immutable 1.1.36. Sur Windows 10 et Windows Server 2016, le GAC contenait une copie de System.Collections.Immutable 1.1.37. L'erreur de chargement ne s'est produite que lorsque le GAC contenait l'ancienne version de la DLL.
Ainsi, la cause principale de l’échec de la charge de l’Assembly était les références incompatibles à System.Collections.Immutable. La définition d'interface et l'implémentation avaient des signatures de méthode d'aspect identique, mais dépendaient en réalité de différentes versions de System.Collections.Immutable, ce qui signifiait que le moteur d'exécution ne considérait pas la classe d'implémentation comme correspondant à la définition d'interface.
L'ajout de la redirection de liaison suivante à mon fichier de configuration d'application a résolu le problème:
<dependentAssembly>
<assemblyIdentity name="System.Collections.Immutable" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-1.1.37.0" newVersion="1.1.37.0" />
</dependentAssembly>
J'ai encore une autre solution ésotérique à ce message d'erreur. J'ai mis à niveau mon infrastructure cible de .Net 4.0 à 4.6 et mon projet de test unitaire m'indiquait l'erreur "System.TypeLoadException ... n'a pas d'implémentation" lorsque j'ai essayé de générer. Il a également donné un deuxième message d'erreur à propos de la même méthode supposée non implémentée qui disait "La tâche 'BuildShadowTask' a échoué de manière inattendue." Aucun des conseils ici ne semblant aider, j'ai donc cherché "BuildShadowTask" et trouvé une publication sur MSDN qui m'a amené à utiliser un éditeur de texte pour supprimer ces lignes du fichier csproj du projet de test unitaire.
<ItemGroup>
<Shadow Include="Test References\MyProject.accessor" />
</ItemGroup>
Après cela, les deux erreurs ont disparu et le projet construit.
Je l'ai eu avec une dépendance de projet en forme de "diamant":
- Le projet A utilise les projets B et D
- Le projet B utilise le projet D
J'ai recompilé le projet A mais pas le projet B, ce qui a permis au projet B d’injecter l’ancienne version du projet D dll
J'ai rencontré ce problème lorsque j'ai renommé un projet (et le nom de l'assembly), sur lequel reposait un projet ASP.NET. Les types du projet Web implémentent des interfaces dans l'assembly dépendant. Bien que Clean Solution ait été exécuté à partir du menu Générer, l’assemblée portant l’ancien nom est restée dans le dossier bin
var types = AppDomain.CurrentDomain.
GetAssemblies().
ToList().
SelectMany( s => s.GetTypes() /* exception thrown in this call */ )
;
l'exception ci-dessus a été levée, se plaignant du fait que les méthodes d'interface dans les types Web implémentant n'ont pas été réellement implémentées La suppression manuelle de l'assembly dans le dossier bin du projet Web a résolu le problème.
Je reviens sans cesse sur cette question .... Beaucoup de réponses ici expliquent très bien le problème, mais pas comment le résoudre.
La solution consiste à supprimer manuellement les fichiers bin du répertoire publié de vos projets. Il nettoiera toutes les références et obligera le projet à utiliser les dernières DLL.
Je ne suggère pas d'utiliser la fonction de suppression d'outils de publication, car cela tend à détourner IIS.
Je viens de mettre à niveau une solution de MVC3 vers MVC5 et j'ai commencé à recevoir la même exception de mon projet de test unitaire.
Vérifié toutes les références à la recherche d'anciens fichiers, éventuellement découvert que je devais faire quelques bindingRedirects pour Mvc, dans mon projet de test unitaire.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-Microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="0.0.0.0-5.1.0.0" newVersion="5.1.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
J'ai également eu cette erreur lorsque j'avais précédemment activé la couverture de code lors du test unitaire de l'un des assemblys. Pour une raison quelconque, Visual Studio a "tamponné" l'ancienne version de ce particulier DLL même si je l'avais mise à jour pour implémenter une nouvelle version de l'interface. La désactivation de la couverture de code a éliminé l'erreur.
Dans mon cas, cela a aidé à réinitialiser la boîte à outils WinForms.
J'ai eu l'exception lors de l'ouverture d'une Form dans le concepteur; Cependant, la compilation et l'exécution du code étaient possibles et le code s'est comporté comme prévu. L'exception s'est produite dans une UserControl locale implémentant une interface à partir de l'une de mes bibliothèques référencées. L'erreur est apparue après la mise à jour de cette bibliothèque.
Cette UserControl était répertoriée dans la boîte à outils WinForms. Probablement, Visual Studio a conservé une référence sur une version obsolète de la bibliothèque ou a mis en cache une version obsolète quelque part.
Voici comment j'ai récupéré de cette situation:
- Faites un clic droit sur la WinForms Toolbox et cliquez sur
Reset Toolboxdans le menu contextuel. (Cela supprime les éléments personnalisés de la boîte à outils).
Dans mon cas, les éléments de la Boîte à outils ont été restaurés à leur état par défaut. cependant, la flèche du pointeur était manquante dans la Boîte à outils. - Fermez Visual Studio.
Dans mon cas, Visual Studio s'est terminé avec une exception de violation et a été abandonné. - Redémarrez Visual Studio.
Maintenant tout se passe bien.
Cette erreur peut également être provoquée si un assembly est chargé à l'aide de Assembly.LoadFrom (String) et fait référence à un assembly déjà chargé à l'aide de Assembly.Load (Byte []).
Par exemple, vous avez incorporé les assemblys référencés de l'application principale sous forme de ressources, mais votre application charge des plug-ins à partir d'un dossier spécifique.
Au lieu d'utiliser LoadFrom, vous devriez utiliser Load. Le code suivant fera le travail:
private static Assembly LoadAssemblyFromFile( String filePath )
{
using( Stream stream = File.OpenRead( filePath ) )
{
if( !ReferenceEquals( stream, null ) )
{
Byte[] assemblyData = new Byte[stream.Length];
stream.Read( assemblyData, 0, assemblyData.Length );
return Assembly.Load( assemblyData );
}
}
return null;
}
J'ai eu cette erreur parce que j'avais une classe dans une Assemblée 'C' qui était sur la version 4.5 du framework, implémentant une interface dans Assembly 'A' qui était sur la version 4.5.1 du framework et servant de classe de base à Assembly 'B' qui était également sur la version 4.5.1 du framework. Le système a lancé l'exception en essayant de charger l'assemblage 'B'. De plus, j'avais installé des paquets de nuget ciblant .net 4.5.1 sur les trois assemblys. Pour une raison quelconque, même si les références de pépites ne figuraient pas dans l’Assemblée «B», la construction s’est bien déroulée.
Il s'est avéré que le vrai problème était que les assemblys faisaient référence à différentes versions d'un paquet de nuget contenant l'interface et que la signature de l'interface avait changé entre les versions.
FWIW, je l’ai eu quand il y avait un fichier de configuration qui a été redirigé vers une version inexistante d’un assemblage référencé. Fusion fusionne pour la victoire!
Dans mon cas, j'avais précédemment référencé un projet mylib dans un dossier frère situé à l'extérieur du référentiel - appelons cela v1.0.
|-- myrepo
| |-- consoleApp
| |-- submodules
| |-- mylib (submoduled v2.0)
|-- mylib (stale v1.0)
Plus tard, je l'ai fait correctement et l'ai utilisé via un sous-module git - permet d'appeler cela v2.0. Un projet consoleApp n'a cependant pas été mis à jour correctement. Il faisait toujours référence à l'ancien projet v1.0 en dehors de mon projet git.
De manière confuse , même si le *.csproj était manifestement faux et qu'il indiquait v1.0, Visual Studio IDE indiquait le chemin sous la forme du projet v2.0! pour inspecter l'interface et la classe sont aussi passés à la version v2.0.
L'assembly placé dans le dossier bin par le compilateur était la version v1.0, d'où le casse-tête.
Le fait que IDE m'ait menti rendait encore plus difficile la réalisation de l'erreur.
Solution : Suppression de références de projet de ConsoleApp et relecture de ces dernières.
Astuce générale: Recompilez tous les assemblages à partir de zéro (si possible, bien sûr, pour les paquets de nugets) et vérifiez les tampons datetime dans le dossier bin\debug. Toutes les vieilles assemblées datées sont votre problème.
Une autre explication à ce type de problème impliquant le C++ géré.
Si vous essayez de stub une interface définie dans un assembly créé à l'aide de C++ managé avec une signature spéciale, vous obtiendrez une exception lors de la création du stub.
Cela est vrai pour Rhino Mocks et probablement pour tout framework moqueur qui utilise System.Reflection.Emit.
public interface class IFoo {
void F(long bar);
};
public ref class Foo : public IFoo {
public:
virtual void F(long bar) { ... }
};
La définition d'interface obtient la signature suivante:
void F(System.Int32 modopt(IsLong) bar)
Notez que le type C++ long correspond à System.Int32 (ou simplement int en C #). C'est la variable modopt quelque peu obscure qui est à l'origine du problème comme l'a déclaré Ayende Rahien sur la liste de diffusion de Rhino Mocks .
J'ai fait face presque au même problème. J'étais en train de me gratter la tête à cause de cette erreur ..__ J'ai vérifié, toutes les méthodes ont été implémentées.
Sur Google, j'ai eu ce lien entre autres. Basé sur le commentaire de @Paul McLink, ces deux étapes ont résolu le problème.
- Redémarrer Visual Studio
- Nettoyer, construire (reconstruire)
et le error parti.
Merci Paul :)
J'espère que cela aide quelqu'un qui rencontre cette erreur :)
J'ai vu cela dans Visual Studio Pro 2008 lorsque deux projets ont construit des assemblys portant le même nom, l'un d'une classe lib SDF.dll et l'autre qui référencait la lib avec le nom d'assembly sdf.exe . Assemblée, l'exception est partie
Voici mon point de vue sur cette erreur.
Ajout d'une méthode extern, mais mon collage était défectueux. La DllImportAttribute a été mise sur une ligne commentée.
/// <returns>(removed for brevity lol)</returns>[DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool IsWindowVisible(IntPtr hWnd);
S'assurer que l'attribut était réellement inclus dans la source a résolu le problème.
J'ai également rencontré ce problème lors de l'exécution de mes unittests. L'application fonctionnait correctement et sans erreur. La cause du problème dans mon cas était que j'avais désactivé la construction des projets de test. La réactivation de la construction de mon projet de test a résolu les problèmes.
Je reçois cette erreur aujourd'hui. Mon problème était - ne pas faire dans TFS obtenir la dernière version. Dans le serveur était dll avec interface qui une des méthodes a été modifiée. J'ai travaillé avec un vieil homme - sur mon PC ses travaux. Comment réparer: obtenir le dernier, reconstruire
J'ai reçu cette erreur après une récente mise à jour de Windows. J'avais une classe de service définie pour hériter d'une interface. L'interface contenait une signature qui renvoyait un ValueTuple, une fonctionnalité relativement nouvelle en C #.
Tout ce que je peux deviner, c'est que la mise à jour Windows en a installé une nouvelle, mais y a même fait explicitement référence, en mettant à jour les redirections de liaison, etc. Le résultat final consistait simplement à changer la signature de la méthode en "standard".
En tant qu'addendum: cela peut également se produire si vous mettez à jour un paquet de nuget utilisé pour générer un faux Assembly. Supposons que vous installiez la version 1.0 d’un paquet Nuget et que vous créez un faux assemblage "fakeLibrary.1.0.0.0.Fakes". Ensuite, vous mettez à jour la dernière version du paquet Nuget, disons v1.1, qui ajoute une nouvelle méthode à une interface. La bibliothèque Fakes est toujours à la recherche de la v1.0 de la bibliothèque. Il suffit de retirer le faux assemblage et de le régénérer. Si tel était le problème, cela résoudra probablement le problème.
Cela signifie simplement que le projet de mise en œuvre est obsolète dans mes cas. La DLL contenant l'interface a été reconstruite, mais la DLL d'implémentation était périmée.
Dans mon cas, j'essayais d'utiliser TypeBuilder pour créer un type. TypeBuilder.CreateType a lancé cette exception. J'ai finalement réalisé que je devais ajouter MethodAttributes.Virtual aux attributs lors de l'appel de TypeBuilder.DefineMethod pour une méthode permettant de mettre en œuvre une interface. En effet, sans cet indicateur, la méthode ne met pas en œuvre l'interface, mais une nouvelle méthode avec la même signature (même sans spécifier MethodAttributes.NewSlot).
Je l’ai eu dans un service WCF parce qu’un type de construction x86 avait été sélectionné, ce qui faisait que bisn vivait sous bin\x86 au lieu de bin. En sélectionnant N'importe quel processeur, les DLL recompilées ont été placées aux emplacements appropriés (je n'entrerai pas dans les détails sur la manière dont cela s'est passé).
J'ai eu le même problème. J'ai compris que mon Assemblée, chargée par le programme principal, contenait des références avec "Copy Local" défini sur true. Ces copies locales de références cherchaient d'autres références dans le même dossier, ce qui n'existait pas car "Copier en local" des autres références était défini sur false. Après la suppression des références copiées "accidentellement", l'erreur disparaissait car le programme principal était configuré pour rechercher les emplacements corrects des références. Apparemment, les copies locales des références ont bousillé la séquence d’appel parce que ces copies locales ont été utilisées à la place des copies originales présentes dans le programme principal.
Le message à retenir est que cette erreur apparaît en raison du lien manquant pour charger l'assembly requis.
Je me suis heurté à cela et seule ma machine locale avait le problème. Aucun autre développeur de notre groupe ni mon VM n’avait le problème.
À la fin, cela semblait lié à un "pack de ciblage" Visual Studio 2017
- Ouvrez le programme d'installation de Visual Studio
- Sélectionnez Modifier
- Aller au deuxième onglet supérieur "Composants individuels"
- Voyez quels packs Frameworks et Targeting vous avez sélectionnés.
- Je n'ai pas sélectionné les deux derniers packs de ciblage
- J'ai aussi remarqué que je n'avais pas sélectionné "Fonctions ASP.NET avancées", contrairement aux autres machines.
- Sélectionné et installé les nouveaux éléments et tout va bien maintenant.
Encore une autre façon d’obtenir ceci:
class GenericFoo<T> {}
class ConcreteFoo : GenericFoo<ClassFromAnotherAssembly> {}
Code dans un assembly qui ne fait pas référence à Assembly of ClassFromAnotherAssembly.
var foo = new ConcreteFoo(); //kaboom
Cela m'est arrivé lorsque ClassFromAnotherAssembly était ValueTuple.
Juste pour ajouter mon expérience car elle n’a pas été abordée dans d’autres réponses:
J'ai eu ce problème lors de l'exécution des tests unitaires dans MsTest.
Les classes à l’essai se trouvaient dans une assemblée signée.
Une version différente de cette assemblée se trouvait dans le GAC (mais avec le même numéro de version d’assemblée).
L'algorithme de résolution de dépendance pour les assemblys nommés forts est légèrement différent de celui non signé, car le GAC est vérifié en premier.
Donc, MsTest récupérait l'assembly GAC'd Assembly plutôt que d'utiliser celui du dossier bin, et essayait d'exécuter les tests avec, ce qui ne fonctionnait évidemment pas.
La solution consistait à retirer l’assemblée GAC.
Notez que pour moi, cela n’était pas le cas lorsque les tests ont été exécutés, car la compilation compilerait les assemblys avec un nouveau numéro de version d’Assembly. Cela signifiait que les anciennes versions de l'Assemblée du GAC ne seraient pas prises en compte.
Aussi, j'ai trouvé une solution de contournement ici, si pour une raison quelconque vous ne pouvez pas accéder au GAC: https://johanleino.wordpress.com/2014/02/20/workaround-for-un-testing-code-that-reside -in-the-gac/
Notre problème résolu avec la mise à jour des fenêtres! Notre application Web est sur .Net 4.7.1 et c # 7.0. Comme nous l'avons testé dans différentes fenêtres, nous avons compris que le problème serait résolu en mettant à jour les fenêtres. En effet, le problème a été vu dans Windows 10 (version 1703) ainsi que dans un serveur Windows 2012 (non mis à jour l'an dernier). Après avoir mis à jour les deux, le problème a été résolu. En fait, la version mineure asp.net (la troisième partie de la version de clr.dll dans C:\Windows\Microsoft.NET\Framework64\v4.0.30319) a été modifiée un peu après la mise à jour.
Ce qui a résolu le problème pour moi était de Clean et Rebuild la Solution.