исходный код net framework

Перевод нескольких статей, в т.ч. Shawn Burke (thanks!), ScottGu(thanks!), Paul Krill (thanks!) и John Robbins (First great thanks! Second great thanks!)

Если у Вас есть какие-либо проблемы, пожалуйста, для начала убедитесь что Вы выполнили все шаги. В ТОЧНОСТИ как написано у нас. Если все же ничего не помогает, обратите внимание на секцию FAQ в конце документа. Если и это не заработает, пишите Ваши комментарии, мы будем решать их все вместе.

Основная настройка

Для начала отмечу, что если у Вас установлена MS VS 2008 Express Edition, то у Вас это работать не будет.

1) Установите Visual Studio QFE. Это исправление просто обновляет DLL, которые являются частью отладчика Visual Studio, который выбирает исходные файлы. Все подробности оп исправлениям читайте на странице загрузки.

Если вы получили сообщение об ошибке установки обновления, попробуйте вставить ваш DVD VS 2008 и запустите EXE снова. Это возможно поможет установить исправление правильно.

2) Запустите Visual Studio и выберите Tools > Options > Debugging > General. Если Вы работаете над Visual Basic Profile, Вам необходимо установить флажок в нижней части диалога Options Dialog, «Show All Settings» перед тем как продолжить.

3) Далее выберите из дерева свойств Debugging > Symbols. Установите источник символов для скачивания и места на Вашем жестком диске, где Visual Studio будет их кэшировать:
Добавьте в Symbol file (.pdb) location адрес: http://referencesource.microsoft.com/symbols
Задайте расположение кэша. Убедитесь в том что это место имеет права на чтение и запись. Отличный вариант — место Ваших документов. Например, C:\Users\Stanislav\VsSymbols.
Включите флажок: Search the above locations only whan symbols are loaded manually.

Все, установка произведена!

Отладка внутри исходного кода Framework

Для этого возьмем простой пример. Создадим пустой C# Windows Application проект. Установим точку входа на Form_Load.

Эти действия позволят загрузить символы из DLL с севрера, и Вы увидете что все строки, обозначающие вызовы внутри System.Windows.Forms.dll станут черными, т.е. доступными. Также станут доступными и номера строк. Помните, что каждый раз, когда Вам понадобится посмотреть на символы, нужно будет щелкнуть правой клавишей мыши и выбрать Load Symbols.

Итак, с этого момента загружены все символы для System.Windows.Forms.dll и теперь можно смотреть его код. Код вы можете просматривать совершенно также как и во время обычной отладки своего кода. Для этого, как обычно, щелкните дважды по строке CallStack либо зайдите внутрь методов сборки по (F11). Когда Вы в первый раз попробуете просмотреть код, то Вам предложат лицензию, на основани которой Вам разрешено его читать, и если Вы согласны с ней, нажмите Accept, после чего исходный код будет загружен.

Теперь для всех сборок, в которых Вы захотите отлаживаться, просто повторите все те шаги, которые описаны выше. Если Вам понадобилось отладки тех сборок, которых нет в Call Stack, откройте окно Modules и загрузите символы оттуда.

Теперь Вы можете в примере выше зайти в код DrawRectangle по F11.

Для продвинутых пользователей

Как правило, при каждом сеансе отладки, Visual Studio пытается загрузить символы для каждой DLL, которая загружается в отлаживаемый процесс. Чтобы найти информацию по символам, она порсматривает все пути, указанные в Options > Debugging > Symbols. Но есть проекты, которые используют очень много библиотек DLL, для которых нет никакой информации по символам. В этих случаях процесс запуска отладки будет очень долгим. Это основная причина, из-за которой мы советуем Вам использовать загрузку символов по требованию пользователя.

Существует, однако, способ сделать загрузку символов автоматически (что по сути, избавляет от шага «Load Symbols»), что увеличивает общую производительность. Этот флажок имеет смысл устанавливать только продвинутым пользователям системы, поскольку потом Вам придется довольно часто возвращаться в этот диалог. Кстати, для того чтобы быстро в него зайти, выберите «Symbol Settings. » в контекстном меню на изображении повыше.

Основа этого — получить все символы, скачать их и храниьб локально. Для этого отключите флажок «Search the above locations. ».

После этого запустите свой проект в отладчике. Да, кстати, извините, совсем забыл сказать. Наберитесь терпения, чаем и булочками. В зависимости от соединения скачивать студия будет либо долго, либо очень долго. Всего понадобится скачать порядка 50 мегабайт. И т.к. все это будет закешировано, то эот будет единовременно.

Как только этот процесс завершится, можно остановить отладчик и снять источник с адресом сервера и нажать OK:

После этих шагов все символы будут загружаться автоматичсеки, и Вы будете иметь возможность вмешиваться в стек вызовов без ранних ограничений. Обратите внимание, что если Вы будете работать над другим проектом, в котором не будет информации по загруженным символам, порсто повторите все эти шаги 😉

Также проверьте ваш «C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE» (или то место, куда Вы установили Visual Studio) файл с именем symsrv.no. Если этот файл существует, переименуйте его в symsrv.yes.

2) Когда я пытаюсь зайти отладчиком внутрь исходного кода, то получаю диалог «Source is not available for this location»
Во-первых посмотрите пункт (2) в FAQ. чтобы убедиться что все символы были загружены успешно. В этом можно убедиться, посмотрев в окно Modules, в колонку статуса символов. Если символы загружены, проверьте следующее:
Если Вы настроили Microsoft Symbol Server в прошлом, и Вы загрузили символы для этой DLL, которые не содержат исходных кодов. Попробуйте указать другое положение кэша либо удалите существующий кэш, после чего поврите команду «Load Symbols». Посмотрите также FAQ (3) для получения дополнительной информации.
Убедитесь лишний раз в том что Вы включили флажок «Enable Source Server» в окне Tools > Options > Debugging > General.
Убедитесь что папка, которая настроена на сбор кэша символов, имеет разрешения на чтение и запись
Если у Вас установлена _NT_SYMBOL_PATH, она будет переопределять все эти настройки. За подробностями сюда

3) Я также использую Microsoft Symbol Server для загрузки символов. В чем разница?

Microsoft Symbol Server обеспечит Вас символами без предоставления какой-либо информации в них. Эта информация будет удалена перед публикацией. Чтобы использовать и Reference Source path и Micrososft Symbol Server это расположение Reference Source path первым в списке

Однако если у Вас Microsoft Symbol Server настраивается через _NT_SYMBOL_PATH, помните, что _NT_SYMBOL_PATH перекрывает эти настройки.

4) Есть ли поддержка 64-разрядной ОС?

Да, при условии наличия 64-разряднных версий PDB. Здесь стоит отметить что есть DLL, которые работают на различных архитектурах. Потому для них понадобится всего одна PDB.

5) Как мне установить точки останова в коде Framework?

Изначально, Visual Studio требует чтобы код в точности соответствовал PDB файлу. Хотя довольно часто PDB файлы изменены не значительно. Например, автор добавил строки с авторскими правами. Но код по-прежнему можно легко отлаживать. Просто установите точку останова (появится не полностью закрашенная точка) и укажите расположение PDB файла (контекстное меню от точки останова, позиция Location. )

Затем установите флажок, указанный ниже:

После этих действий Вы сможете спокойно продолжить работу.

6) Почему такие функции как «Go To Defenition» не работают?

Потому что эта информация создается на периоде работы с кодом, а не во время исполнения.

7) Почему некоторые члены или локальные переменные не доступны? Почему я не могу заходить внутрь некоторых методов или ходить по некоторым строчкам кода?

8) Почему так долго загружаются PDB файлы?

Потому что их много, и среди них есть файлы под 1 мегабайт.

9) Можно ли открыть и посмотреть их через браузер?

Нет, вы получите ошибку HTTP 400.

Способ #2: Скачать с официального сайта Microsoft одним архивом (любая IDE)

Для того чтобы скачать все символы и исходные коды одним архивом, пройдите по ссылке: http://referencesource.microsoft.com/netframework.aspx.
Однако из всего набора предоставленных ссылок для скачивания, у меня работала всего одна. Не солидно.

Предназначен для скачивания всех символов и исходных кодов. Работает из командной строки и доступен в исходных кодах.

Для того чтобы скачать то что нам нужно, пройдите по ссылке (.NET MASS DOWNLOADER), скачайте его и запустите следующим образом:

Настройте Visual Studio так, как показано ниже:

Источник

I would like to solve it without using any external tools (e.g. dotPeek as source server).

2 Answers 2

Go to Tools / Options / Debugging / General, and perform these settings:

Go to Tools / Options / Debugging / Symbols, and:

Unpack the downloaded archive (zip) file to a convenient path on your PC.

Note: your application may start slower since it will download PDBs from the internet.

Note: I had to restart VS several times until it «did not crash» while looking for sources, this is most likely a bug in VS.

Note: Since VS saves the path you entered for the source files, you can stop debugging or restart VS; it will work next time, too. Besides, you do not have to manually select any more source files within the framework, because the VS will use the source folder you entered and will search in source files there.

Many people wondering why they can’t step into source although they does set the checkboxes as described above. I’m, too.

Because you can extract dotnet sources to any location, Visual Studio isn’t able to know about them and the reason can’t be the source files itself (why Visual Studio doesn’t find the files).

In short: you have to search a dll version of your file (which you like to debug) which contains FULL DEBUG INFORMATION. This is also the reason why context menu disables «goto source». I’m replacing this file temporary in global assembly cache for time of debug. This works for me.

Perhabs somebody can create a public database (wiki), which everyone can add files and versions for which full debug information are available?

Источник

Если анализатор обнаруживает нарушения правил, он отправляет о них оповещение в виде предложения, предупреждения или ошибки, в зависимости от настройки каждого правила. Нарушения анализа кода появляются с префиксом CA или IDE. Этот префикс отличает их от ошибок компилятора.

Анализ качества кода

Если вы используете Visual Studio:

Включенные правила

ИД диагностики	Категория	Уровень серьезности	Описание:
CA1416	Совместимость	Предупреждение	Анализатор совместимости платформ
CA1417	Совместимость	Предупреждение	Не используйте OutAttribute в параметрах строки для P/Invokes
CA1831	Производительность	Предупреждение	При необходимости используйте AsSpan вместо индексаторов на основе диапазона для строки
CA2013	надежность;	Предупреждение	Не используйте ReferenceEquals с типами значений
CA2014	надежность;	Предупреждение	Не используйте stackalloc в циклах
CA2015	надежность;	Предупреждение	Не определяйте методы завершения для типов, производных от MemoryManager
CA2200	Использование	Предупреждение	Повторно порождайте исключения для сохранения сведений стека
CA2247	Использование	Предупреждение	Аргумент, передаваемый конструктору TaskCompletionSource, должен иметь значение перечисления TaskCreationOptions вместо TaskContinuationOptions

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

Включение дополнительных правил

Режим анализа относится к предопределенной конфигурации анализа кода, в которой правила отключены или включены (несколько или все). В режиме анализа по умолчанию лишь небольшое количество правил включено в качестве предупреждений сборки. Вы можете изменить режим анализа для своего проекта, установив свойство в файле проекта. Допустимые значения:

Значение

Описание

AllDisabledByDefault

Это самый консервативный режим. По умолчанию все правила отключены. Можно выборочно принять отдельные правила, чтобы включить их.

AllDisabledByDefault

AllEnabledByDefault

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

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

Рассматривать предупреждения как ошибки

Предупреждения анализа кода будут отображаться по-прежнему, но при этом они не будут нарушать сборку.

Последние обновления

Дополнительные сведения и список возможных значений см. на странице AnalysisLevel.

При установке пакета NuGet Microsoft.CodeAnalysis.NetAnalyzers не нужно добавлять свойство EnableNETAnalyzers в файл проекта или в файл Directory.Build.props. После установки пакета NuGet и задания для свойства EnableNETAnalyzers значения true создастся предупреждение сборки.

Анализ стиля кода

Правила анализа стиля кода (IDExxxx) позволяют определять и поддерживать согласованный стиль кода в базе кода. Параметры включения по умолчанию:

Полный список правил анализа стиля кода см. на этой странице.

Включение при сборке

Выполните следующие действия, чтобы включить анализ стиля кода при сборке:

В файле .editorconfig настройте каждое правило стиля кода с префиксом IDE, которое вы хотите запускать при сборке как предупреждение или ошибку. Пример.

Кроме того, вы можете настроить всю категорию как предупреждение или ошибку по умолчанию, а затем выборочно отключить правила в этой категории, которые не нужно запускать при сборке. Пример.

Отключение предупреждений

Один из способов пропустить нарушение правила — установить для параметра важности этого идентификатора правила значение none в файле EditorConfig. Пример.

Дополнительные сведения и другие способы отключения предупреждений см. на этой странице.

Сторонние анализаторы

Источник

.NET Core vs Framework. Производительность коллекций

Мне стало интересно, какой прирост производительности можно ожидать от Core в самых базовых классах, которые максимально часто используются в коде. Например, коллекции List, Array и Dictionary.

Если вам тоже интересно, как и почему изменилась производительность основных коллекций в Core 3 — прошу под кат!

Бенчмарки

Также я прогонял все тесты на двух дополнительных машинах (на Haswell и Sky Lake), чтобы убедиться, что результаты тестов стабильны и воспроизводятся на другом железе.

Цикл for

Method	Runtime	Size	Mean	Error	StdDev	Ratio
IterateFor_Int	.NET 4.8	1000	565.09 ns	0.191 ns	0.127 ns	1.00
IterateFor_Int	.NET Core 2.1	1000	451.14 ns	0.236 ns	0.156 ns	0.80
IterateFor_Int	.NET Core 3.1	1000	451.08 ns	0.143 ns	0.085 ns	0.80
IterateFor_String	.NET 4.8	1000	574.80 ns	6.795 ns	4.494 ns	1.00
IterateFor_String	.NET Core 2.1	1000	460.86 ns	3.771 ns	2.494 ns	0.80
IterateFor_String	.NET Core 3.1	1000	460.35 ns	0.681 ns	0.405 ns	0.80

В Core JIT генерирует более эффективный код, чтение элементов из List в цикле for стало быстрее на

Цикл foreach

Method	Runtime	Size	Mean	Error	StdDev	Ratio
IterateForEach_Int	.NET 4.8	1000	1,574.5 ns	2.73 ns	1.81 ns	1.00
IterateForEach_Int	.NET Core 2.1	1000	1,575.8 ns	3.82 ns	2.27 ns	1.00
IterateForEach_Int	.NET Core 3.1	1000	1,568.1 ns	0.61 ns	0.40 ns	1.00
IterateForEach_String	.NET 4.8	1000	8,046.3 ns	36.51 ns	24.15 ns	1.00
IterateForEach_String	.NET Core 2.1	1000	6,465.0 ns	15.26 ns	10.09 ns	0.80
IterateForEach_String	.NET Core 3.1	1000	5,886.3 ns	14.65 ns	9.69 ns	0.73

Итерирование List с ссылочными типами через foreach стало быстрее на 27%, но для значимых типов ничего не поменялось. Здесь можно оценить, насколько foreach медленнее, чем for. Разница в их эффективности на Core составляет 3.5x (value types) и 12x (reference types), примерно также как и в полном фреймворке.

Чтобы протестировать метод без ресайза внутреннего массива в тесте используется конструктор List с заданной ёмкостью (capacity).

Method	Runtime	Size	Mean	Error	StdDev	Ratio
Add_Int	.NET 4.8	1000	2,006.5 ns	11.65 ns	6.93 ns	1.00
Add_Int	.NET Core 2.1	1000	1,249.0 ns	1.00 ns	0.60 ns	0.62
Add_Int	.NET Core 3.1	1000	1,260.9 ns	5.88 ns	3.89 ns	0.63
Add_String	.NET 4.8	1000	3,250.8 ns	53.13 ns	35.14 ns	1.00
Add_String	.NET Core 2.1	1000	2,816.8 ns	37.26 ns	22.18 ns	0.87
Add_String	.NET Core 3.1	1000	2,538.2 ns	30.55 ns	20.21 ns	0.78

Contains

Давайте возьмём негативный сценарий для метода Contains: будем искать элементы, которых нет в коллекции.

Method	Runtime	Size	Mean	Error	StdDev	Ratio
Contains_Int	.NET 4.8	1000	1,128.975 us	5.4951 us	3.6347 us	1.00
Contains_Int	.NET Core 2.1	1000	456.040 us	0.1437 us	0.0950 us	0.40
Contains_Int	.NET Core 3.1	1000	188.002 us	0.1619 us	0.0964 us	0.17
Contains_String	.NET 4.8	1000	4,027.20 us	9.479 us	5.641 us	1.00
Contains_String	.NET Core 2.1	1000	3,332.93 us	2.156 us	1.128 us	0.83
Contains_String	.NET Core 3.1	1000	2,723.48 us	2.460 us	1.464 us	0.68

Кстати, раньше я всегда думал, что метод Contains внутри вызывает IndexOf, но оказалось, что это верно только для Core. В полном фреймворке это разные методы, и работают они с разной скоростью.

List Methods Summary

Сводная таблица относительной производительности (ratio) основных методов List при N = 1000.

List Method	Type	.NET 4.8	Core 2.1	Core 3.1	Details
Ctor	Int	1.00	0.82	0.47	Report
Ctor	String	1.00	0.90	0.92	Report
IterateFor	Int	1.00	0.80	0.80	Report
IterateFor	String	1.00	0.80	0.80	Report
IterateForEach	Int	1.00	1.00	1.00	Report
IterateForEach	String	1.00	0.80	0.73	Report
Add	Int	1.00	0.62	0.63	Report
Add	String	1.00	0.87	0.78	Report
Contains	Int	1.00	0.40	0.17	Report
Contains	String	1.00	0.83	0.68	Report
IndexOf	Int	1.00	0.99	0.43	Report
IndexOf	String	1.00	0.95	0.95	Report

Array Methods Summary

Подробно останавливаться на методах массива я не буду, поскольку List — это обертка над массивом.
Так что здесь я приведу таблицу относительной производительности Array при N = 1000.

Array Method	Type	.NET 4.8	Core 2.1	Core 3.1	Details
Ctor	Int	1.00	0.73	0.88	Report
Ctor	String	1.00	0.75	0.84	Report
IterateFor	Int	1.00	0.86	1.00	Report
IterateFor	String	1.00	1.00	1.00	Report
IterateForEach	Int	1.00	0.84	1.00	Report
IterateForEach	String	1.00	1.00	1.00	Report

Здесь можно отметить, что как и прежде, цикл foreach для массива преобразуется в обычный for. Т.е. с точки зрения производительности для итерации массива нет разницы какой из циклов использовать.

Dictionary

Randomized Hash

Method	Runtime	Size	Mean	Error	StdDev	Ratio
Add_IntKey	.NET 4.8	1000	10.449 us	0.0690 us	0.0456 us	1.00
Add_IntKey	.NET Core 2.1	1000	12.270 us	0.0492 us	0.0325 us	1.17
Add_IntKey	.NET Core 3.1	1000	11.355 us	0.0723 us	0.0478 us	1.09
Add_StringKey	.NET 4.8	1000	33.229 us	0.0331 us	0.0219 us	1.00
Add_StringKey	.NET Core 2.1	1000	35.303 us	0.1821 us	0.1084 us	1.06
Add_StringKey	.NET Core 3.1	1000	26.976 us	0.1248 us	0.0825 us	0.81

Добавление в Dictionary с ключом String стало быстрее на 19%. В случае с Int ключом результат (ratio) зависит от размера: на 100 — 0.95, на 1’000 — 1.09, на 10’000 — 0.93. Отклонения небольшие, возможно, это просто «шум». На других машинах отклонения ещё меньше. Будем считать, что с ключом типа Int добавление элемента происходит примерно с той же скоростью.

GetValue

Method	Runtime	Size	Mean	Error	StdDev	Ratio
GetValue_IntKey	.NET 4.8	1000	10.916 us	0.019 us	0.013 us	1.00
GetValue_IntKey	.NET Core 2.1	1000	10.985 us	0.135 us	0.089 us	1.01
GetValue_IntKey	.NET Core 3.1	1000	9.424 us	0.086 us	0.056 us	0.86
GetValue_StringKey	.NET 4.8	1000	31.622 us	0.294 us	0.175 us	1.00
GetValue_StringKey	.NET Core 2.1	1000	31.787 us	0.090 us	0.047 us	1.00
GetValue_StringKey	.NET Core 3.1	1000	23.572 us	0.098 us	0.058 us	0.75

Получение элемента по строковому ключу стало быстрее на 25%, по Int ключу — на 14%. Однако, здесь есть зависимость от размера Dictionary. Чем меньше размер — тем больше Framework отстает от Core 3 и наоборот. На маленьких размерах Core 3 работает в 1.5 раза быстрей. При достижении размера в 10’000 производительность Core 3 падает до уровня Framework и даже чуть ниже (см. отчеты ниже).

В коде класса Dictionary слишком много изменений, чтобы однозначно сказать, какие из них больше всего повлияли на производительность.

Dictionary Methods Summary

Сводная таблица относительной производительности основных методов Dictionary при N = 1000.

Dictionary Method	Type	.NET 4.8	Core 2.1	Core 3.1	Details
Ctor	Int	1.00	0.95	0.62	Report
Ctor	String	1.00	4.06	3.84	Report
Add	Int	1.00	1.17	1.09	Report
Add	String	1.00	1.06	0.81	Report
GetValue	Int	1.00	1.01	0.86	Report
GetValue	String	1.00	1.00	0.75	Report
ContainsKey	Int	1.00	0.84	0.78	Report
ContainsKey	String	1.00	0.99	0.73	Report
ContainsValue	Int	1.00	0.54	0.54	Report
ContainsValue	String	1.00	0.86	0.90	Report

Результаты

Как и ожидалось, почти все рассмотренные методы на Core 3 работают быстрее. Разница зачастую составляет 20-30%, а то и больше. Для таких базовых коллекций это отличный результат.

Код и детальные результаты всех тестов доступны на GitHub.

Источник

Читайте также: 86372 код какого города