mscorlib.dll И System.dll
Ошибка анализа: синтаксическая ошибка, неожиданный T_PAAMAYIM_NEKUDOTAYIM
Оператор разрешения области также называется «Paamayim Nekudotayim» с иврита פעמיים נקודתיים. это означает «двойная двоеточие» или «двойная точка дважды».
Эта ошибка обычно возникает, если вы случайно поместите :: в свой код.
Вопросы, относящиеся:
- Ссылка: Ошибки анализа / синтаксиса PHP; и как их решить?
- Что означают два двоеточия в PHP?
- В чем разница между :: (double толстой кишки) и - & gt; (стрелка) в PHP?
- Неожиданный T_PAAMAYIM_NEKUDOTAYIM, ожидающий T_NS_Separator
Документация:
6 ответов
<забастовка>, которую делает Mscorlib, содержит и собственный и управляемый код.
Среди других вещей это содержит Систему. Реализация объектов, которая должна всегда присутствовать для всего для работы.
Это имеет различие того, чтобы быть единственной сборкой, которой CLR требует, чтобы быть загруженным в каждом управляемом процессе.
Первоначально, много "дополнительного" материала (вещи, которые технически не требуются запустить приложение) было помещено в mscorlib, потому что они были вещами, которые, очень вероятно, будут использоваться всеми. Это включает вещи как HashTable и Список.
Это дало повышение перфекта. Если все собираются хотеть использовать что-то, то имеет смысл помещать его в блоке, который все должны загрузить. Тогда Вы не должны напрасно тратить время, идя и связывая целый набор различных блоков.
материал в system.dll был в основном всем, что не было "достойно" того, чтобы быть включенным в mscorlib.
Эта тенденция, однако, начинает инвертироваться. CLR прилагает усилия для сокращения размера mscorlib. Много материала было удалено для Silverlight, например (для сокращения размера загрузки).
я думаю, что они могли бы делать больше этого вида материала для V4 (и более поздние версии), но я не уверен в деталях.
Я работаю над командой CLR/BCL и просто ответил на Вашу электронную почту. Здесь это вставляется ниже:
ответ Jared на Переполнении стека является правильным на. mscorlib.dll плотно связывается с CLR по причинам, которые он упоминает. Обратите внимание, что mscorlib.dll самостоятельно не содержит собственного кода (как Scott предполагает), но существует много мест, где он должен звонить непосредственно в CLR. По сути, CLR и mscorlib должны быть имеющими версию вместе.
System.dll, с другой стороны, плотно не связывается с CLR (он не требует никаких вызовов во время выполнения). Мы полагаем, что System.dll на более высоком слое, чем mscorlib.dll. Наличие этих блоков в двух отдельных слоях допускает больше гибкости, облегчая присваивать версию System.dll отдельно от версии CLR/mscorlib.dll (если мы хотели сделать так). Мы, в теории, могли внести изменения и добавить функциональность к System.dll, не газуя на версии CLR/mscorlib. Разделение также облегчает управлять правилами зависимости между компонентами в этих различных слоях.
, Поскольку Scott упоминает, действительно кажется, что существует много "дополнительного" материала в mscorlib. Это главным образом по историческим причинам и потому что некоторые вещи просто необходимы другим вещам. Например, нет никакой технической причины почему Система. IO.IsolatedStorage должен быть в mscorlib, но это, где это, оказалось, было добавлено в 1,0, прежде чем мы действительно думали о таких проблемах управления версиями/разделения на уровни. Кроме того, Список находится в mscorlib, потому что другой код в mscorlib имеет потребность в основном наборе списка.
Длительный срок мы хотели бы уменьшить сумму "дополнительного" материала в mscorlib как можно больше. Или путем продвижения материала из mscorlib или создания нового, большего количества ядра, блок, который просто содержит абсолютный минимум необходимые типы (например, Система. Объект, Система. Int32, и т.д.), чтобы заставить управляемый код работать. Это даст нам гибкость, чтобы добавить новые идеи к "дополнительному" материалу и облегчить создавать различные наименования Платформы.NET (например, Клиентский Профиль.NET, Silverlight, и т.д.), не имея необходимость газовать на времени выполнения.
я надеюсь, что это помогает!
Спасибо, Justin
Подробно останавливаясь на ответе Scott.
Любая данная версия CLR высоко связывается с конкретной версией mscorlib.dll. Это особенное DLL очень многими способами. Время выполнения CLR требует, чтобы определенные типы/методы были доступны, и реализует много методов, определенных в фактической кодовой базе. Сложность управления этими отношениями уменьшается при наличии небьющейся ссылки между версией CLR и версией mscorlib.
Бросьте хороший взгляд на Ссылочный узел любого проекта. Вы никогда не будете находить mscorlib.dll перечисленным там. Это является особенным, для любого компилятора нужен он, потому что это содержит типы, которые требуются, чтобы заставлять синтаксис языка работать. Система. Массив, Система. Int32, Система. Строка, Система. Исключение, и т.д.
можно записать программу, которая не имеет зависимости от System.dll (хотя это было бы твердо), но Вы не можете записать тот, который не зависит от mscorlib.dll
Упомянутая собственная/управляемая вещь звучит вероятной, но я полностью все еще не убежден. В любом случае MS кажется представлению mscorlib.dll как базовый lib, необходимый для система , в то время как System.dll содержит базовую функциональность для программисты - который также звучит хорошим.
я только что послал этот тот же вопрос по электронной почте команде BCL. Если кто-либо может ответить... Когда (если?) Я получаю ответ, я отправлю его здесь. Спасибо за ответы до сих пор!
Это - просто предположение, но mscorlib.dll, вероятно, также имеет некоторый код C, это важно для времени выполнения CLR, а также быть блоком.NET или некоторым кодом смешанного режима. System.dll, вероятно, все управляют.