Наверное, одним из самых интригующих нововведений в Visual Studio 2010 является IntelliTrace или как его представляли ранее historical debugger. И после релиза новой студии можно сложить свое мнение об этой возможности и ее практическом применении или необходимости – в общем, если быть кратким, нужно определится – зачем оно нам необходимо

Что такое IntelliTrace? Это новая фича, и соответственно новое окно при отладке, которое объединяет в себе обычную трассировку (output окно в Visual Studio), отладчик и стек вызовов. Т.е. такой себе микс уже существующих окон и соответственно возможностей – output + callstack + debugger = IntelliTrace.

Основная цель strong name или подписи сборки это ее уникальность в GAC(Global assembly cache). На основании сборки во время подписи вычисляется криптографический открытый ключ, закрытый хранится в секрете у производителя сборки, хеш-функция от которого и составляет public token, что, по сути, есть strong name для сборки. Public token сохраняется в метаданных сборки и в паре с именем сборки, версией, и культурой, и служит для уникальной ее идентификации.

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

Но многие заблуждаются думая, что сборка со строгим именем защищена от модификации. Справедливости ради, стоит заметить, что если производитель сборки опубликовал public token или открытый ключ, например на своем сайте, то всегда можно проверить соответствует ли этот ключ или токен тому ключу, который зашит в используемые сборки, но это скорее придется проверить вручную. Важно другое, что строгое имя не защитит сборку от модификации, как многие думают, и соответственно механизм в CLR не отработает, как положено и загрузит модифицированную сборку.

В FxCop есть такое правило Override GetHashCode on overriding Equals, переопределяйте GetHashCode переопределяя Equals. Так вот с этим правилом связан подводный камень. В Rule Description там написано об этом но как на мой взгляд не совсем ясно.

Это связано с принципом работы  HashTable и Dictionary в .NET, и для того чтобы сравнение производилось верно при переопределении Equals необходимо обязательно переопределить GetHashCode в зависимости от тех данных которые учувствуют в сравнении. Иначе Equals просто не будет вызван, хотя многие разработчики ожидают что он будет вызыватся всегда. Equals вызывается только тогда когда GetHashCode возвращает одинаковые значения, что как было сказано выше, связано с принципом работы словарей и хеш-таблиц, для того чтобы разрешить коллизии в хеш-таблице.

С другой стороны на такие неправильные выводы вполне возможно наталкивает поведение System.Object метод GetHashCode которого возвращает значения, которые не зависят от данных хранящихся в объекте и возвращает разные хеш-коды для одинаковых объектов.

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