Nous avons mis à niveau un grand projet de .NET 3.5 vers .NET 4.0. Tout fonctionne bien sauf l'erreur concernant le chargement des ressources de ListView. Maintenant, nous sommes juste avant la libération et c'est un bloqueur très.Le type sérialisé dans le fichier .resources n'était pas le même type que le fichier .resources indiquait qu'il contenait
Il s'agit d'un problème connu par Microsoft, par exemple here ou here. Il existe un hotfix pour ce problème, mais nous avons essayé tous les Service Pack disponibles pour .NET Framework 4.0, mais rien n'a fonctionné.
Nous avons essayé d'installer: KB2416472, KB2487367, KB2604121, KB2729449, KB2736428, KB2737019, KB2742595, KB2840628, KB2858302v2, KB2861188, KB2972106, KB2972215, KB2978125, KB2979575v2, KB3023221, KB3032662, KB3037578, KB3048074, KB3072309, KB3074547 - mais sans succès.
Le correctif doit être dans CLR dans 4.0.30319.461 (GDR).
J'ai également essayé de changer un peu de concepteur, pour forcer Visual Studio à le changer au format .NET 4. Cela n'aide pas.
La seule façon de résoudre ce problème était d'installer .NET Framework 4.5.2. Mais nous ne voulons pas abandonner le support de Windows XP.
Une autre solution consiste à basculer la propriété localisable sur false pour tous ces contrôles utilisateur. Cela me semble beaucoup de travail et nous voulons garder la localisation. Et c'est assez? Nous ne sommes pas en mesure de tester tous les contrôles et scénarios juste avant la sortie dans un délai raisonnable.
Existe-t-il une solution réelle? Y a-t-il un service pack disponible?
Je ne veux pas croire que .NET Framework 4.0 n'est pas stable. Ce contrôle Winform est une fonctionnalité de base dans .NET!
CLR Excepton: System.BadImageFormatException: The type serialized in the .resources file was not the same type that the .resources file said it contained. Expected 'System.Windows.Forms.ListViewItem' but read 'System.Windows.Forms.ListViewItem+ListViewSubItem'.
at System.Resources.ResourceReader.TypeLimitingDeserializationBinder.BindToType(String assemblyName, String typeName)
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Bind(String assemblyString, String typeString)
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.GetType(BinaryAssemblyInfo assemblyInfo, String name)
at System.Runtime.Serialization.Formatters.Binary.ObjectMap..ctor(String objectName, String[] memberNames, BinaryTypeEnum[] binaryTypeEnumA, Object[] typeInformationA, Int32[] memberAssemIds, ObjectReader objectReader, Int32 objectId, BinaryAssemblyInfo assemblyInfo, SizedArray assemIdToAssemblyTable)
at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped record)
at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryHeaderEnum binaryHeaderEnum)
at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
at System.Resources.ResourceReader.DeserializeObject(Int32 typeIndex)
at System.Resources.ResourceReader._LoadObjectV2(Int32 pos, ResourceTypeCode& typeCode)
at System.Resources.ResourceReader.LoadObjectV2(Int32 pos, ResourceTypeCode& typeCode)
at System.Resources.ResourceReader.LoadObject(Int32 pos)
at System.Resources.ResourceReader.ResourceEnumerator.get_Entry()
at System.Resources.ResourceReader.ResourceEnumerator.get_Current()
at System.ComponentModel.ComponentResourceManager.FillResources(CultureInfo culture, ResourceSet& resourceSet)
at System.ComponentModel.ComponentResourceManager.FillResources(CultureInfo culture, ResourceSet& resourceSet)
at System.ComponentModel.ComponentResourceManager.ApplyResources(Object value, String objectName, CultureInfo culture)
Il est un problème très obscur. Les chances que le correctif peut encore fonctionner sont zilch, .NET 4.0 a été mis à jour plusieurs fois depuis lors. Aussi très, très étrange qu'ils l'ont fait avec un patch CLR, n'a aucun sens. Assez peu probable que vous obteniez de l'aide ici quand vous ne pouvez pas démontrer le problème, la pile d'appels ne le coupe pas. Toujours vouloir prendre en charge XP coûte de l'argent, passer un appel téléphonique à Microsoft Support. Bien qu'ils vous disent probablement d'installer intentionnellement une ancienne révision de.NET afin que le correctif puisse toujours fonctionner. Ne faites pas cela votre problème. –