При написании приложений, одной из важнейших вопросов являются потребление памяти и отзывчивость (скорость работы).

Считается, что сборщик мусора – черный ящик, работу которого нельзя предугадать.

А еще говорят, что GC в .NET практически не настраиваемый. А еще, что нельзя посмотреть исходники как классов .NET Framework, так и CLR, GC и т.п.

А я скажу как бы ни так!

В данной статье мы рассмотрим:

• структура организации размещения объектов в памяти
• CLR 4.5 Background Server GC
• правильная настройка сборщика мусора
• эффективный апгрейд приложений до .NET 4.0+
• правильное ручное управление памятью

Привет, это снова Без слайдов. Я Алексей Федоров, и на этот раз в гостях у меня побывал Сергей Шкредов, руководитель всего .NET-направления в компании JetBrains.



С Сергеем мы говорили:

• о последних релизах ReSharer;
• о новой схеме подписок и лицензий;
• про непростые отношения с Microsoft;
• о рантайме и развитии языка;
• о том, как поменял ситуацию выход Roslyn;
• о работе с фидбеком пользователей для улучшения продукта;
• о планах развития других продуктов .NET стека;
• о важности внутриотраслевого общения и обмена опытом;
• про разработку продуктов для С++;
• немного о ReSharper C++, на который должны подсесть даже разработчики Microsoft;
• О том, как пользователи почувствуют изменения;
• Как ReSharper будет развиваться дальше.

Вот видео



Под катом — текстовый вариант интервью.

Довольно давно я делился проблемой тестирования кода в финализаторе и недавно жаловался на падение теста (Как тестировать код финализатора (c#) и Как тестировать код финализатора (c#). Послесловие: тест все-таки упал).
В ходе обсуждения комрадом withkittens была высказана идея:

Финализатор (при правильной реализации IDisposable pattern) должен (should) вызывать Dispose(false). Этот факт можно тестировать статическим анализом. Соответственно, если Dispose(false) вызывает удаление файла (вы же написали тест?), то можно быть уверенным, что и финализатор тоже вызовет удаление файла, unit-тест излишен.

Мне эта идея показалась очень здравой, кроме того, иногда хочется контролировать исходный код более кастомно, чем дает встроенный анализ кода или решарпер.
Опыт реализации кастомных правил анализа кода под катом + «как ozcode помог в процессе исследования внешней библиотеки»

Только недавно мы выпустили ReSharper 7.1, но уже пора поздравить плагинописателей, которые сумели подготовить свои плагины для новой версии. Большинство выпущенных плагинов являются OSS-проектами, над которыми авторы работают в свободное время, так что нам бы хотелось поблагодарить их за поддержку нашей экосистемы. Вот небольшой обзор плагинов, которые уже готовы для работы с R# 7.1.

Доброго времени,

Как известно, Resharper решает много проблем по работе с кодом, но все-таки не все.

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