Я имел в виду то что есть издатель приложения. Он подписывает сборку своими ключами. Плагины могут разрабатывать сторонние разработчики. У них другие ключи. Издатель приложения свой закрытый ключ им не даст. Т.е. подпись строгим именем у плагина будет другая. Плагин может создать издатель плагина, а может и злоумышленник изменив его и внедрив код и подписав своим ключом. Т.е. для основного приложения стоит задача отделить две неизвестные ему подписи и определить «правильную» сборку по токенам.
В таком случае наверное может помочь механизм регистрации плагина у издателя основного приложения. В таком случае издатель внесет строгое имя в какой-то свой список чтобы распознать плагин от его злонамеренной модификации.
Да, согласен, но пример с -Vr (ну и реестром, это ведь одно и то же по сути) будет отклонять проверку только на локальной машине. При удалении строгого имени и соотв. атрибута из сборки — на любой. Собственно, как написал mezastel ниже.
Да можно и так, только тогда проверка на соответствие строгого имени сборки не будет проходить только на локальной машине. А вот если полностью удалить строгое имя — тогда на любой.
Про то что сборку нужно обфусцировать и криптовать я упомянул, также то что неплохо было бы вручную проверять строгое имя в разных частях сборки тоже.
Про принуительную проверки не писал так как это из разряда «ручная проверка».
Хотя абсолютно согласен было бы неплохо так делать перед загрузкой плагинов, только сами плагины, если они от 3-х разработчиков тогда должны как-то сообщать программе их действительные а не поддельные строгие имена, так как в данном случае строгие имена плагинов и программы не обязаны совпадать.
Глянул спасибо, только вы немного ошиблись ссылкой, про строгие имена во второй части не нашел там. Но там автор подает это как механизм защиты. Я же утверждаю и написал статью именно для того чтобы избежать подобных заблуждения.
А вот про то что можно удалить строгие имена легко нашел в третьей части www.codeproject.com/KB/security/NeCoder03.aspx. Судя по всему автор пересмотрел свое мнение от первой-второй части до третьей
Строгие имена — это не надежный механизм защиты от модификации сборки и основное предназначение их не в этом. А вообще эта тема возникла тогда когда возникли строгие имена с .NET — так что я думаю и автор на кодпроджекте и я не первые и не последние, потому что например во 2-ой редакции рихтера, насколько я помню, строгие исена подаются как, дополнительно, механизм защиты от модификации. Хотя там не говорится насколько надежный и упоминается оговорка про цифровые подписи и Autheticode
Модификация CLR сборок отдельная тема, можно конечно им все поудалять строгое имя. Но там помимо строгого имени есть цифровая подпись.
Но зачем из них удалять строгое имя? Код приложения там не содержится, смысла делать это нет. Есть смысл удалять строгое имя со сборок приложения.
Проверьте насколько они защищены, напитсав простое приложеньеце из нескольких сборок и попробовав модифицировать код сборок. Не хотел добавлять в текст банальный пример консольного приложения с сателитной сборкой.
Ну что ж в плане мобильных платформ тогда лучше оставаться на 2008 студии, хотя весьма жаль. Возможно что мы и не увидим поддержку кроме Windows Phone так как, судя по всему, майкрософт не намерена поддерживать WM.
А по поводу закрытия опять же есть способ. Точно такой же. Только если комманда закрытия всех документов вынесена в меню, то текущего нет. Нужно кастомизировать один из тулбаров, например стандартный, и вынести на него комманду Window.CloseDocumentWindow — она то и будет закрывать текущий докумет, она висит по-умолчанию на шорткате Ctrl+F4
У меня тоже не возникало проблем при переименовании и переносе файлов внутри проект, и в комманду у нас ни у кого. Из проблем все что было это один раз неправильно перерисовалось окно судя по всему wpf-овский баг, но это мелочь. Solution explorer терял фокус и получал его только после перезагрузки студии, но мы юзаем coderush я думаю это уже его вина. Так что это все мелочи.
Общая кнопка закрытия. Это не проблема. Поместите себе на тулбар комманду в виде кнопки «Close All»(Close All Documents в меню Window), назначьте на нее shortcut, коллеги по комманде кто заскучал за этим так и сделали и не ноют.
По поводу мобильных платформ. Я конечно могу ошибатся, но насколько я знаю, для разработки под WM 6/6.5 на VS 2008 приходилось ставить SDK, который и добавлял возможность писать под эти платформы. Писать на WM 5 новые проекты — мне кажется несколько бессмысленно.
VS 2010 — не идеал, но она версия лучше чем VS 2008 и тем более лучше чем более ранние версии
1) Потому что вы не шарите. Потому что для этого имплементирован IEqualityComparer. Не был бы имплементирован, пришлось бы оверрайдить. А про ваш «жуткий втык» который вы нашли, так он в статье подается как распространенная ошибка. Специально чтобы избежать двузначности добавил коммент в код
// распространенная ошибка, неверно
И вы хотите сказать что внимательно читали?
2) Пример вполне из жизни. Вам как опытному программисту я решил помочь абстрагироваться и поменял имена на марки машин. Не говорите теперь что пример не из жизни.
3)4) это ваша личная имха, которая вообще не аргумент. Видимо мой ответ что вы придерживаетесь к двум строчкам вас задел.
5) Согласен логично что GetHashCode применяется только там, но как же быть с реализацией GetHashCode из System.Object, она немного не вписывается в общую концепция. Так что не будьте так категоричны. В CLR благодаря System.Object существует некая двузначность, может стоило эти методы вообще убрать от туда и тех кто хочет использовать свои объекты в словарях и хеш-таблицах заставлять вручную реализовывать GetHashCode например из того же IEqualityComparer, ведь собственно так и происходит почти всегда.
5) Опять вы невнимательно читали ни статью ни мои ответы вам. Приоритетов нет. Приоритетами — так был назван порядок вызова методов GetHashCode и Equals. Потому что многие разработчики думают что Equals вызывается всегда — это ошибка и суть статьи была указать именно на нее. Я убрал это предложение чтобы не было больше двучтений.
По поводу «Если вы нормально напишите о применимости метода GetHashCode ...» я добавил ссылки, потому что незачем дублировать материал из википедии и мсдн.
Я думал что холливар бывает между линуксоидами и не линуксоидами :) А оказывается и здесь ересь.
Значится так все необходимые упоминания соблюдены.
Строка «Так как GetHashCode при сравнении имеет больший приоритет перед Equals» подразумевает порядок вызова методов. Чтобы в ее не извращали добавлю приписку «в порядке вызова методов»
«Наверное такое поведение было сделано для улучшения производительности» — строку я для вас убрал. А то вы спать не можете.
«Вы делаете выводы… » — это ваше личное мнение.
Вы прицепились к двум строчкам и пытаетесь удалить статью. И при том что в статье изначально указано упоминание «Это связано с принципом работы HashTable и Dictionary». Напоминаю статья не о хеш-таблицах, поэтому о них здесь упоминанием и ограничится.
Хотите больше, пишите. Охотно почитаю и потроллю у вас в камментах.
Если доступны то дайте ссылку. Отладочные символы и рефлектор — это недоступные сорсы. Рефлектор по сути дизассемблер.
Я вот не пойму чего вы добиваетесь?
Да статья не про хеш-таблицы. Тем не менее все упоминания соблюдены. Ну так если вы очень хотите, напишите про хеш-таблицы, конечно статья уже есть в википедии, но будет еще и на хабре.
1) 2)Итак в код наведенном в статье присутствует хеш таблица? Нет. Что запрятано за кулисами CLR это одно, именно по этому и написано «связано с принципом работы HashTable и Dictionary», потому что для IEqualityComparer он за кулисами и используется «скорее всего». Опять придеретесь к «скорее всего»? Я так написал потому что кода CLR нет. Возьмите рефлектор повыдирайте куски и когда найдете их и покажете, я тогда исправлю на 100% там используется хеш-таблица.
List, IEnumerable — не хеш теблицы, а вот чтобы правильно отрабатывала операция и IEqualityComparer приведен.
Давайте еще такой вариант расcмотрим — System.Object у него GetHashCode — хеш-код для алгоритмов хеширования? нет. Читайте МСДН. Не везде где есть GetHashCode метод есть хеш-таблица. Вот строка из МСДН:
Consequently, the default implementation of this method [Object.GetHashCode] must not be used as a unique object identifier for hashing purposes.
Так вот, если бы вы внимательно почитали то Hashtable и Dictionary в коде статьи не присутствует. Да такое поведние как есть связано с принципом их работы о чем и указываеться в тексте.
Но причем хеш-таблица к List, массиву, Object. Или если мы переопределяем метод Object.GetHashCode — то Object — тоже хеш таблица.
Повторяюсь суть статьи об переопределении методов GetHashCode, Equals.
Я вообще-то веду речь об переопределении метода GetHashCode, Equals и потому что в нем фигурирует слово хеш еще не значит что это хеш таблица на примере обычного списка List<T> (берем общий случай IEnumerable), повторюсь List — обычный список, массив если хотите, размер которого меняется динамически. Скажите массив — это хеш таблица или нет?
Да если очень внимательно читать МСДН то сразу все станет ясно, но как показывает практика подобную описанную ошибку делают многие и она касается не хеш-таблицы как таковой а переопределения методов GetHashCode и Equals и почему Equals не вызывается как ожидают многие разработчики, особенно начинающие.
Я имел в виду то что есть издатель приложения. Он подписывает сборку своими ключами. Плагины могут разрабатывать сторонние разработчики. У них другие ключи. Издатель приложения свой закрытый ключ им не даст. Т.е. подпись строгим именем у плагина будет другая. Плагин может создать издатель плагина, а может и злоумышленник изменив его и внедрив код и подписав своим ключом. Т.е. для основного приложения стоит задача отделить две неизвестные ему подписи и определить «правильную» сборку по токенам.
В таком случае наверное может помочь механизм регистрации плагина у издателя основного приложения. В таком случае издатель внесет строгое имя в какой-то свой список чтобы распознать плагин от его злонамеренной модификации.
Ключ -Vr делает запись в реестре, см коммент habrahabr.ru/blogs/net/91999/#comment_2781797
Про принуительную проверки не писал так как это из разряда «ручная проверка».
Хотя абсолютно согласен было бы неплохо так делать перед загрузкой плагинов, только сами плагины, если они от 3-х разработчиков тогда должны как-то сообщать программе их действительные а не поддельные строгие имена, так как в данном случае строгие имена плагинов и программы не обязаны совпадать.
А вот про то что можно удалить строгие имена легко нашел в третьей части www.codeproject.com/KB/security/NeCoder03.aspx. Судя по всему автор пересмотрел свое мнение от первой-второй части до третьей
Строгие имена — это не надежный механизм защиты от модификации сборки и основное предназначение их не в этом. А вообще эта тема возникла тогда когда возникли строгие имена с .NET — так что я думаю и автор на кодпроджекте и я не первые и не последние, потому что например во 2-ой редакции рихтера, насколько я помню, строгие исена подаются как, дополнительно, механизм защиты от модификации. Хотя там не говорится насколько надежный и упоминается оговорка про цифровые подписи и Autheticode
www.copyscape.com
найдете не мою копию на любом языке, удалю статью и принесу извенения.
Статью писал сам и исследовал этот вопрос так как коллеги заблуждались по поводу строгого имени. Как оказалось не только они одни.
Если есть предложения по поводу стиля, грамматики, ошибок и прочего литературного охотно их расмотрю и внесу правки
Но зачем из них удалять строгое имя? Код приложения там не содержится, смысла делать это нет. Есть смысл удалять строгое имя со сборок приложения.
Проверьте насколько они защищены, напитсав простое приложеньеце из нескольких сборок и попробовав модифицировать код сборок. Не хотел добавлять в текст банальный пример консольного приложения с сателитной сборкой.
А по поводу закрытия опять же есть способ. Точно такой же. Только если комманда закрытия всех документов вынесена в меню, то текущего нет. Нужно кастомизировать один из тулбаров, например стандартный, и вынести на него комманду Window.CloseDocumentWindow — она то и будет закрывать текущий докумет, она висит по-умолчанию на шорткате Ctrl+F4
Общая кнопка закрытия. Это не проблема. Поместите себе на тулбар комманду в виде кнопки «Close All»(Close All Documents в меню Window), назначьте на нее shortcut, коллеги по комманде кто заскучал за этим так и сделали и не ноют.
По поводу мобильных платформ. Я конечно могу ошибатся, но насколько я знаю, для разработки под WM 6/6.5 на VS 2008 приходилось ставить SDK, который и добавлял возможность писать под эти платформы. Писать на WM 5 новые проекты — мне кажется несколько бессмысленно.
VS 2010 — не идеал, но она версия лучше чем VS 2008 и тем более лучше чем более ранние версии
// распространенная ошибка, неверно
И вы хотите сказать что внимательно читали?
2) Пример вполне из жизни. Вам как опытному программисту я решил помочь абстрагироваться и поменял имена на марки машин. Не говорите теперь что пример не из жизни.
3)4) это ваша личная имха, которая вообще не аргумент. Видимо мой ответ что вы придерживаетесь к двум строчкам вас задел.
5) Согласен логично что GetHashCode применяется только там, но как же быть с реализацией GetHashCode из System.Object, она немного не вписывается в общую концепция. Так что не будьте так категоричны. В CLR благодаря System.Object существует некая двузначность, может стоило эти методы вообще убрать от туда и тех кто хочет использовать свои объекты в словарях и хеш-таблицах заставлять вручную реализовывать GetHashCode например из того же IEqualityComparer, ведь собственно так и происходит почти всегда.
5) Опять вы невнимательно читали ни статью ни мои ответы вам. Приоритетов нет. Приоритетами — так был назван порядок вызова методов GetHashCode и Equals. Потому что многие разработчики думают что Equals вызывается всегда — это ошибка и суть статьи была указать именно на нее. Я убрал это предложение чтобы не было больше двучтений.
По поводу «Если вы нормально напишите о применимости метода GetHashCode ...» я добавил ссылки, потому что незачем дублировать материал из википедии и мсдн.
Значится так все необходимые упоминания соблюдены.
Строка «Так как GetHashCode при сравнении имеет больший приоритет перед Equals» подразумевает порядок вызова методов. Чтобы в ее не извращали добавлю приписку «в порядке вызова методов»
«Наверное такое поведение было сделано для улучшения производительности» — строку я для вас убрал. А то вы спать не можете.
«Вы делаете выводы… » — это ваше личное мнение.
Вы прицепились к двум строчкам и пытаетесь удалить статью. И при том что в статье изначально указано упоминание «Это связано с принципом работы HashTable и Dictionary». Напоминаю статья не о хеш-таблицах, поэтому о них здесь упоминанием и ограничится.
Хотите больше, пишите. Охотно почитаю и потроллю у вас в камментах.
Я вот не пойму чего вы добиваетесь?
Да статья не про хеш-таблицы. Тем не менее все упоминания соблюдены. Ну так если вы очень хотите, напишите про хеш-таблицы, конечно статья уже есть в википедии, но будет еще и на хабре.
List, IEnumerable — не хеш теблицы, а вот чтобы правильно отрабатывала операция и IEqualityComparer приведен.
Давайте еще такой вариант расcмотрим — System.Object у него GetHashCode — хеш-код для алгоритмов хеширования? нет. Читайте МСДН. Не везде где есть GetHashCode метод есть хеш-таблица. Вот строка из МСДН:
Consequently, the default implementation of this method [Object.GetHashCode] must not be used as a unique object identifier for hashing purposes.
Но причем хеш-таблица к List, массиву, Object. Или если мы переопределяем метод Object.GetHashCode — то Object — тоже хеш таблица.
Повторяюсь суть статьи об переопределении методов GetHashCode, Equals.
Да если очень внимательно читать МСДН то сразу все станет ясно, но как показывает практика подобную описанную ошибку делают многие и она касается не хеш-таблицы как таковой а переопределения методов GetHashCode и Equals и почему Equals не вызывается как ожидают многие разработчики, особенно начинающие.
Как раз материал и построен относительно .net.