Pourquoi System.Numerics.BigInteger n'a pas de méthode Parse dans Silverlight 4.0, mais dans .Net 4.0?

Question

Je suis tombé sur un écart étrange entre BigInteger s utilisé par. Net 4.0 et Silverlight 4.0; Dans .Net, BigInteger a une méthode Parse et TryParse où, comme dans la version Silverlight, il n'a pas l'un de ces.

Si vous regardez la version .Net de System.Numerics dans le réflecteur, vous voyez aussi que lorsque vous désassembler le code, chaque méthode simple est juste vide, et il ne possède pas les BigIntergerBuilder et amis de la version Silverlight:

public static BigInteger Parse(string value) 
{ 
} 

Que se passe-t-il ici?

Answer 1

Je ne pense pas que System.Numerics.dll fasse partie de la distribution de Silverlight 4.0. Mais ce n'est pas le vrai point. Ce que vous regardez est une version spéciale de l'assemblage de référence. Vous en trouverez un dans c:\program files\reference assemblies\microsoft\framework\.netframework\v4.0 par exemple.

Les assemblages sont dépouillés de leur IL. Leurs métadonnées sont par ailleurs identiques aux assemblages de référence "réels" dans c:\windows\microsoft.net\framework\v4.0.30319

Je n'ai aucune idée de ce que la fonction de ces assemblages dénudés est supposée être. Je peux seulement imaginer qu'ils sont destinés à accélérer la compilation, puisque le compilateur n'a besoin que des métadonnées. Mais c'est un peu long. Je peux aussi imaginer que cela a quelque chose à voir avec le mystérieux nouvel attribut [TargetedPatchingOptOut], un tir très long aussi puisque le mécanisme qui le sous-tend n'est expliqué nulle part que je pourrais trouver. J'ai eu une conversation avec JaredPar à ce sujet, il allait demander à MSFT à ce sujet. Je n'ai pas entendu de retour.

Eh bien, pas de vraie réponse, mais cela explique ce que vous avez vu.

---

Suite à cela, j'ai une autre théorie, inspirée quand j'ai noté que le dossier s'appelait "v4.0". Notez que le numéro de build n'en fait pas partie, comme dans c: \ windows \ microsoft.net. Cela devrait avoir des effets intéressants lors de la publication de nouvelles versions, similaires aux mises à jour des assemblys de base de .NET 2.0 lors de la publication des Service Packs. Malheureusement, une chose qui est allé très mal est que ces mises à jour ont eu des changements dans les classes de base, sans une modification de la [AssemblyVersion]. Le plus visible était la classe WaitHandle, elle a acquis la surcharge WaitOne (int). Très utile, car personne ne pourrait jamais comprendre ce qu'il faut passer pour l'argument exitContext. Utiliser cette nouvelle surcharge était facile à faire, en ciblant .NET 2.0 ne l'empêche pas, mais l'enfer se déchaîne si la machine cible a la version .NET 2.0 RTM d'origine installée sans obtenir les Service Packs.

Ma conjecture: ces assemblages de référence sont les assemblages de base pour toute version actuelle et future de .NET 4.0. Leur interface publique est gelée. Et vous empêche d'utiliser accidentellement une méthode publique qui est ajoutée dans une version ultérieure. Il s'ensuit que l'IL n'est pas utile parce que cela va changer.

Answer 2

Bien que clairement n'est pas le code de BigInteger.Parse - il ne compilera pas, étant donné qu'il ne retourne rien.

Ce n'est pas la seule chose "manquante" dans Silverlight, bien sûr - il y a beaucoup de bits de l'API .NET qui ne sont pas dans Silverlight. C'est une version réduite du cadre. J'ai peur que ce soit juste la façon de faire les choses.

Les entiers étant ce qu'ils sont, il ne serait probablement pas trop difficile à implémenter vous-même d'une manière naïve ... si vous êtes d'accord avec cela étant assez inefficace, je suppose que ce ne serait pas beaucoup de code du tout.