Такой индикации в .Net - профайлере нет, все возможные условные обозначения описаны в документации по профайлеру, стр. 15.

Тут не совсем понятно, еще какую именно информацию по выполняемым методам хочется видеть?

Начиная с комплекта разработчика версии 6.0, для задания исключений из обфускации используется опция  /XML. C помощью утилиты ExclusionUtility.exe можно исключить из обфускации различные типы и методы. Для исключения шифрования строк, достаточно исключить из символьной обфускации метод в котором инициализируется строка.

Выделить оптимальные параметры для защиты Вашего приложения можете только Вы сами.

Имеется исполняемое приложение MyApp.exe и библиотека MyLib.dll.
В библиотеке MyLib.dll содержатся методы для работы с базой данных и множество SQL-запросов. MyApp.exe в свою очередь просто использует функции MyLib.exe.

Я использую такие опции для обфускации этих сборок: /INIT /SO /SE /OP /GS3S /GN3S /MAP=./grd_obfuscate.map
Проблема в том, что при опции /SE программа начинает медленнее работать в разы. Но я не могу оставить некоторые SQL-запросы в MyLib.dll не обфусцированными, т.к. они должны оставаться в тайне. В документации я наткнулся на опцию /SO_CFG=FileName.cfo, которая может создать список исключений для символьной обфускации.

Вопрос 5. Есть ли аналогичная опция исключения для строковой обфускации /SE ?  Как можно выборочно обфусцировать строковые константы ?

Вопрос 6. Как можно защитить обфускатором сборку, чтобы соотнощение  скорость работы/защищенность была оптимальной ?

Вопрос 3. По каким критериям вызванные методы помечаются красным цветом ?

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

Вопрос 4. Не планируете ли вы добавить в DotNetProfiler информации по выполняемым методам, которая могла сделать более аргументированный выбор функций для защиты?

Если защищать несколько копий одного и того же приложения с одинаковыми параметрами для опции /PER, то извлекаться будет одинаковый набор методов для каждой копии приложения.

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

При долгом тестировании программы без защиты с помощью CodeProtect (GrdApi остается) зависаний выявлено не было. Хочется заметить, что в самой программе нет критических секций, которые могли бы привести к Deadlock'у. В связи с этим я делаю предположение, что зависания связаны с защитой моего приложения с помощью CodeProtect.

Вопрос 1. Как еще мне можно подтвердить свои предположения кроме приведенного выше опыта.

Я использую ключ Sign III. Опции защиты таковы:
/INIT /PER=20 /RC=1 /ATR=2 /GS3S /GN3S /UN=1 /SIGN

Как видите, здесь используется процент защищаемых методов. Тут еще одно предположение, что какая-то часть кода при защите может служить причиной зависания. По опции /PER я не нашел в документации нужной мне информации.

Вопрос 2. По каким критериям выбираются методы для защиты, c случайно или же какой-то анализ присутствует?
Если взять 10 копий одного и того же незащищенного приложения, и каждое защитить с опцией /PER, то во всех десяти будут защищены одни и те же методы, или в каждой по разному?