Режим отладки против режима деблокирования - IsJITOptimizerDisabled Свойство

Question

Я просто просмотрел предыдущие вопросы по теме, но у меня есть некоторые странные результаты.

Прежде всего, я следовал и использовал метод, который Скотт Hanselman предложенный в старый пост в своем блоге: http://www.hanselman.com/blog/HowToProgrammaticallyDetectIfAnAssemblyIsCompiledInDebugOrReleaseMode.aspx

Таким образом, Используя IsJITOptimizerDisabled я должен проверить, если конкретный DLL был составлен в или в режиме отладки.

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

Затем я передал это простое приложение коллеге, который подтвердил, что на его рабочей станции результаты ожидаются, а в DLL Debug отображается «Debug», релиз «Release» (эти две библиотеки содержатся в одной и той же папке простое приложение).

Но, когда он пытается проверить эти DLL с помощью этого простого приложения на другом сервере (через mstsc) для обеих библиотек, простое приложение покажет «Отладка» (даже если открыть DLL с помощью ILDASM, все кажется прекрасным, а некоторые конкретные методы, содержащиеся внутри области «#if DEBUG», отсутствуют в dll Relase).

Теперь я схожу с ума, есть ли причина в этой проблеме? Я слишком стар, чтобы посмотреть, что происходит? Может быть отражение как-то зависит от окружающей среды? Есть ли пакет обновления, который решил аналогичную известную проблему?

Приветствие,

Джанлука

Answer 1

DebuggableAttribute является атрибутом, который не компилируется в код IL, содержащемся в исполняемой сборке. Он вставляется во время выполнения, когда сборка загружена. На создание атрибута могут влиять настройки среды.

Например, профилировщик, включенный в систему, мог создать переменные среды или параметры реестра, которые влияют на флаги отладки. A thread on the MSDN forums предлагает проверить переменные среды с именем COR_* или настройки реестра под HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework (и, возможно, HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework).

Answer 2

Использование Assembly.LoadFrom() - не очень хорошая идея в данном конкретном случае. Используйте fuslogvw.exe, чтобы узнать, почему ваша программа загрузила неправильную сборку. GAC, наверное.

Здесь вызывается Anyhoo, LoadFile().