Почему System.Numerics.BigInteger не имеет метода Parse в Silverlight 4.0, а в .Net 4.0?

Question

Я столкнулся со странным несоответствием между BigInteger s, используемыми в .Net 4.0 и Silverlight 4.0; В .Net , BigInteger есть метод Parse и TryParse, где, как и в версии Silverlight , он не имеет ни одного из них.

Если вы посмотрите на .Net версию System.Numerics в Reflector, вы также увидите, что когда вы разбираете код, каждый отдельный метод просто пуст, и ему не хватает BigIntergerBuilder и друзей версии Silverlight:

public static BigInteger Parse(string value)
{
}

Что здесь происходит?

Answer 1

Я не думаю, что System.Numerics.dll является частью дистрибутива Silverlight 4.0. Но дело не в этом. То, на что вы смотрите, является специальной версией справочной сборки. Например, вы найдете его в c:\program files\reference assemblies\microsoft\framework\.netframework\v4.0.

У сборок там есть все их IL, снятые с них. Их метаданные в остальном идентичны «реальным» эталонным сборкам в c:\windows\microsoft.net\framework\v4.0.30319

Понятия не имею, какой должна быть функция этих раздетых сборок. Я могу только представить, что они предназначены для ускорения компиляции, так как компилятору нужны только метаданные. Но это немного далеко. Я также могу предположить, что это как-то связано с таинственным новым атрибутом [TargetedPatchingOptOut], очень длинным выстрелом, так как механизм, стоящий за ним, нигде не объяснен, который я мог найти. У меня был разговор с JaredPar об этом, он собирался спросить об этом в MSFT. Не получил ответа.

Ну, реального ответа нет, но он объясняет, что ты видел.

---

В продолжение этого у меня есть еще одна теория, вдохновленная, когда я заметил, что папка называется "v4.0". Обратите внимание, что номер сборки не является его частью, как в c: \ windows \ microsoft.net. Это должно иметь интересные эффекты при выпуске новых сборок, аналогично обновлениям базовых сборок .NET 2.0, когда выпускались пакеты обновления.

Печально, но одна вещь, которая пошла не так, как надо - это то, что в этих обновлениях произошли изменения в основных классах, без изменения в [AssemblyVersion]. Наиболее заметным был класс WaitHandle, он получил перегрузку WaitOne (int). Очень полезно, потому что никто никогда не мог понять, что передать для аргумента exitContext . Использовать эту новую перегрузку было легко, нацеливание на .NET 2.0 не помешает этому, но он сломается, если на целевой машине установлен исходный выпуск .NET 2.0 RTM без получения пакетов обновления.

Мое предположение: эти эталонные сборки core сборки для любой текущей и будущей версии .NET 4.0. Их публичный интерфейс заморожен. И предотвращает случайное использование открытого метода, который добавляется в более поздней сборке. Следовательно, IL бесполезен, потому что это изменится.

Answer 2

Ну, ясно, что не код BigInteger.Parse - он не скомпилируется, учитывая, что ничего не возвращает.

Конечно, это не единственное, чего не хватает в Silverlight - есть множество кусочков .NET API, которых нет в Silverlight. Это урезанная версия фреймворка. Я боюсь, что это просто способ вещей.

Целые числа являются такими, какие они есть, и, вероятно, было бы не сложно реализовать их самостоятельно наивным способом ... если вы согласны с тем, что это довольно неэффективно, я подозреваю, что это будет не очень все.