Здравствуйте, breee breee, Вы писали:

А>>в свойствах точно выставлено. ну а уж требует ли либа при старте этот 4 нет или нет — не понятно.
А>>по идее она не должна подгружаться, если не находит подходящего CLR... но эт в теории...

BB>Можно узнать при помощи такой команды:
BB>

BB>ildasm.exe library.dll /metadata[=MDHEADER] /text /noil
BB>

BB>Вывод:
BB>

BB>// ================================= M E T A I N F O ================================================

BB>// ===========================================================
BB>// Metadata section: 0x424a5342, version: 1.1, extra: 0, version len: 12, version: v4.0.30319
BB>//            flags: 0x00, streams: 5
BB>...
BB>

да, все так и есть. круто, да? таких глюков по теории и быть то не должно. но они есть....
не жизнь, а рассадник бермудских треугольников))

Здравствуйте, Caracrist, Вы писали:

C>Здравствуйте, Аноним, Вы писали:

А>>А этот NDA.... Вы реально верите в его силу и необходимость и придерживаетесь его? Особенно в случае микрокуска кода?
А>>несвязанного с какой-то патентной областью или ноу-хау конторы?

C>Вы выбрали КОМ обёртку. Это не двух минутный патч. Вам нужно полностью переписать обёртку и добавить всё что уже упоминалось. Это работа, и не на один день. Ищите человека, вопросы и ответы вас ни куда не продвинут.

не могли бы вы уточнить — а что ВСЁ именно тут упоминалось? Я тока реально видел предложение о AppDomain.UnhandledException event.
а вопросы и ответы — ВСЕГДА, запомните, ВСЕГДА куда то да приводят и дают нужную пищу для размышлений и действий.

Здравствуйте, abibok, Вы писали:

A>Во-первых, лучше psscor, чем sos.
Лучшее враг хорошего.

A>А во-вторых, windbg не поможет, если дамп сохранен неправильно. Т.е. ничего более полезного, чем стек исключения, аналогичный тому, что показывает Exception.ToString(), там не будет.
Да, если что-то делать неправильно, то это не поможет. Предлагаю сохранять дамп правильно. Какие-то особенные грабли на которые вы, видимо, намекаете, мне как-то не попадались.

A>Причем для интеропа clr-com такой стек будет совершенно не информативным в плане расследования проблемы.
A>Нужен человек, который как минимум понимает чем отличается 6BA от 6BE.

Если под "мы видим тока библиотеки CLR времени исполнения дотнета" ТС подразумевал что-то типа

mscorlib_ni+0x2f2bbb
mscorlib_ni+0x3675d1
mscorlib_ni+0x36740f

и его цель получить из этого на нормальный managed-стек, то ваш комментарий к делу не относится.

Здравствуйте, abibok, Вы писали:

IB>>пожалуйста логируйте стектрейс, он есть в классе Exception, не забудьте про InnerException

A>1) Для этого придется вставлять код логирования во все catch.
A>2) Стектрейс может быть искажен, если исключение ловилось и перебрасывалось внутри try-catch.
A>3) Исключение в parallel task может сидеть незамеченным, если мы не получаем результат таска, а потом убьет процесс при выполнении финализатора.
A>4) Не поможет, если у нас несколько исключений одновременно, например что-то крэшится в finally, dispose или конструкторе объекта.
A>5) Логировать имеет смысл только unhandled exceptions, а не все. Как это определить в конкретном catch? Можно через рефлексию пройти по стеку вверх и найти все вышестоящие catch, но это дорого и ненадежно.

A>Если лень/нет времени заниматься полноценным решением, стоит хотя бы добавить свой обработчик на AppDomain.UnhandledException event (http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx)

A>Сохранять дамп нужно из своего процесса, чтобы не потерять контекст исключения. При этом лучше из отдельного потока, который нужно создать в начале работы приложения, чтобы вносить как можно меньше шума. Не забудьте про Process.EnterDebugMode и то, что Id потока с исключением должен быть native, а не managed.

Товарищи — еще раз — в дотнет мы полезли — потому что определенное устройство работает тока через дотнет либу.
Мы вообще то программисты тока С++. Поэтому все умные слова, связанные с дотнетом, чтоб билл им икался месяц...
просьба переводить или на чисто русский — или дать ссылки на эту самую предметную область, где более менее корректно все сделано/расписано.
Ибо фраза "Не забудьте про Process.EnterDebugMode" — не вносит ни какого прояснения. Не забыть о чем? О том что такая функция есть? Ее обязательно надо вызывать? Или не вызывать? Или перехватчик-обработчик на нее повесить? Или все действия тока после нее/из нее можно делать...
Мы прекрасно понимаем как дамп под С++ писать — но под дотнет, чтоб его....
Потому — если хоть какой то полноценный вариант кода, реализующего хоть насколько-то верный подход, для дампинга
вы знаете — то просто покажите, ткните носом. У нас реально нет времени изучать все примочки дотнета с нуля. И все его подводные камни...

Во-первых, лучше psscor, чем sos.
А во-вторых, windbg не поможет, если дамп сохранен неправильно. Т.е. ничего более полезного, чем стек исключения, аналогичный тому, что показывает Exception.ToString(), там не будет. Причем для интеропа clr-com такой стек будет совершенно не информативным в плане расследования проблемы.

Нужен человек, который как минимум понимает чем отличается 6BA от 6BE.

отвечу сразу как бы на весь этот subthread разговора.

Да, вы видим, чтото типа
mscorlib_ni+0x2f2bbb
mscorlib_ni+0x3675d1
mscorlib_ni+0x36740f

ДА, хотим увидеть — как минимум нормальные имена функций рядом.
Причем бесит то — что почему то нашей библиотеки ни разу ни в одном стектрейсе не было видно.
тока библиотеки CLR. Что вообще ни какие правильные мысли не наводит, к сожалению.

Нет — WinDBG даже и не думали юзать — ибо на кой ляд тогда в купленной студии существует свой
дебаггер? С С++ кодом, что нам надо — он отлично справляется. И с дампами кода на основе С++ тоже.
Так что чем он ТАК принципиально отличается от WinDBG — что вы предлагаете юзать его при отладке
managed кода?

Итак — есть С++ код, которому надо обратиться к функционалу, работающему только в дотнет библиотеке, чтоб её...
Для этого по совету с MSDN накатали на С++ прокси-dll, в которой идет перевод обращений от С++ в COM объект,
который создан на C# на основе интерфейсных функций из дотнетовской библиотеки. Вроде принципиально все заработало.
НО вдруг стало порой выдавать окно — мол приложение совершило бяку и будет закрыто...
Приклеили запись стектрейсов и минидампов на нашу C++ прогу. И удивились — ибо стектрейс выдавал lite трейс с либами,
которые тока в дотнете существуют. Хммм.. Значит не вы виноваты, но! проблема, что стектрейс не полный (нет
интерфейса функций — мы видим тока библиотеки CLR времени исполнения дотнета), дамп тоже ничего не показывает
нормального — видимо не может он записать/показать инфу по managed коду, когда мы его вызываем из С++'ного.

Вопрос — КАК правильно написать ловлю исключительных ситуаций под дотнет код — не имея доступа к этому коду,
который содержится в юзаемой нами дотнет библиотеке. У нас тока доступ к managed коду создания COM объекта,
и к С++ коду прокси либы. Мы хотим чтоб при возникновении каких либо фиговых ситуаций в нутрях дотнета — мы
получали полноценный стектрейс, характерный именно для managed кода (со всеми верными функциями) и чтоб писался
такой дамп, который при открытии мог показать именно внутренности дотнет среды исполнения — со всеми локальными
переменными с переменными в куче и т.д. Для С++ у нас это вышло — но походу для того, чтоб это сработало для
дотнет либы надо чтото особенное проделать....

Здравствуйте,

Дампы раскрываются только под дот нет 4. Просто переходите на него если можете.

Почему не пользуетесь интерроп(managed c++), по мне так удобней и больше возможностей.

А>Вопрос — КАК правильно написать ловлю исключительных ситуаций под дотнет код — не имея доступа к этому коду,

напишите свою .NET обертку над либой, в которой сделайте логирование всех unhanled exceptons
http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx

Здравствуйте, igor-booch, Вы писали:

А>>Вопрос — КАК правильно написать ловлю исключительных ситуаций под дотнет код — не имея доступа к этому коду,

IB>напишите свою .NET обертку над либой, в которой сделайте логирование всех unhanled exceptons
IB>http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx

логирование? эммм. хотелось бы полные дампы и стектрейс — как я указал в стартовом топике.
Просто текущий лог — мол, я такой-то, чет такое поймал — нам от такой строки легче не станет.
И Хотелось бы какой то полный пример найти. Неужели никто таким не интересовался и не выкладывал
в паблик свои лучшие результаты кода по ловле и дампингу исключений.

Дамп нужно сохранять не в catch — там уже слишком поздно, стек раскручен, локальные переменные потеряны. А нужно внутри exception filter.
В интернете полно примеров сохранения managed dump, при этом я не видел ни одного 100% правильного. Но это легко допиливается вручную, если разобраться как все работает.

Здравствуйте, abibok, Вы писали:

A>Дамп нужно сохранять не в catch — там уже слишком поздно, стек раскручен, локальные переменные потеряны. А нужно внутри exception filter.
A>В интернете полно примеров сохранения managed dump, при этом я не видел ни одного 100% правильного. Но это легко допиливается вручную, если разобраться как все работает.

дык потому то и обращаюсь сюда — чтоб знающие люди подсказали — и может даже выложили этот правильный кусочек кода.
у нас время на разбор понимания нет — наши устройства уже у заказчика и вдруг начался их падеж.....
на тестовых сборках и устройствах ни малейшего сбоя... а что там у заказчика стало происходить — не понятно — потому и прошу срочной помощи
с детализацией того — КАК это можно сделать....
мы просто уже понятно дело попробовали пару примеров с инета — и весьма похоже-что они те самые "неверные"....

А>логирование? эммм. хотелось бы полные дампы и стектрейс — как я указал в стартовом топике.
пожалуйста логируйте стектрейс, он есть в классе Exception, не забудьте про InnerException
log4net вам в помощь
По дампам не знаю, посмотрите http://blogs.msdn.com/b/tess/archive/2009/06/16/first-look-at-debugging-net-4-0-dumps-in-visual-studio-2010.aspx

IB>пожалуйста логируйте стектрейс, он есть в классе Exception, не забудьте про InnerException

1) Для этого придется вставлять код логирования во все catch.
2) Стектрейс может быть искажен, если исключение ловилось и перебрасывалось внутри try-catch.
3) Исключение в parallel task может сидеть незамеченным, если мы не получаем результат таска, а потом убьет процесс при выполнении финализатора.
4) Не поможет, если у нас несколько исключений одновременно, например что-то крэшится в finally, dispose или конструкторе объекта.
5) Логировать имеет смысл только unhandled exceptions, а не все. Как это определить в конкретном catch? Можно через рефлексию пройти по стеку вверх и найти все вышестоящие catch, но это дорого и ненадежно.

Если лень/нет времени заниматься полноценным решением, стоит хотя бы добавить свой обработчик на AppDomain.UnhandledException event (http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx)

Сохранять дамп нужно из своего процесса, чтобы не потерять контекст исключения. При этом лучше из отдельного потока, который нужно создать в начале работы приложения, чтобы вносить как можно меньше шума. Не забудьте про Process.EnterDebugMode и то, что Id потока с исключением должен быть native, а не managed.

Здравствуйте, abibok, Вы писали:

IB>>пожалуйста логируйте стектрейс, он есть в классе Exception, не забудьте про InnerException

A>1) Для этого придется вставлять код логирования во все catch.
A>5) Логировать имеет смысл только unhandled exceptions, а не все. Как это определить в конкретном catch? Можно через рефлексию пройти по стеку вверх и найти все вышестоящие catch, но это дорого и ненадежно.
A>Если лень/нет времени заниматься полноценным решением, стоит хотя бы добавить свой обработчик на AppDomain.UnhandledException event (http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx)
Скажите что значит полноценное решение?


A>2) Стектрейс может быть искажен, если исключение ловилось и перебрасывалось внутри try-catch.
A>3) Исключение в parallel task может сидеть незамеченным, если мы не получаем результат таска, а потом убьет процесс при выполнении финализатора.
A>4) Не поможет, если у нас несколько исключений одновременно, например что-то крэшится в finally, dispose или конструкторе объекта.
Если в библиотеке исходный код которой недоступен неправильно обрабатываются исключения, то тут уже ничего не поделаешь. Может только дампы помогут.

Поясню свое решение во избежании недоразумений:

Есть библиотека, исходный код которой недоступен

class Lib
{

    void A(...)
   {
   ...
   }

   void B(...)
   {
   ...
   }
}

обращаемся из C++ не напрямую к этой библиотеке, а к обертке

class LibWrapper
{
   public LibWrapper()
   {
       AppDomain.CurrentDomain.UnhandledException += (s, eventArgs) => 
       {
           //логирование
       }

   }

   void A(...)
   {
   ...
   }

   void B(...)
   {
   ...
   }
}

Что Вы предлагаете?

Может проще нанять человека, который умеет? Дешевле выйдет. А здесь все равно никто не даст рабочих исходников. 90% в этой теме не рубят, остальные связаны NDA.

Здравствуйте, abibok, Вы писали:

A>Может проще нанять человека, который умеет? Дешевле выйдет. А здесь все равно никто не даст рабочих исходников. 90% в этой теме не рубят, остальные связаны NDA.

чтоб нанять такого — надо быть уверенным — что такой чувак есть. И если в своей С++ сфере мы понимаем КАК искать и ГДЕ искать,
если вдруг понадобится такое дело — то в дотнете — это "первый раз в первый класс". И результаты могут быть непредсказуемыми.
Этот нанятый — может точно также из инета по быстрому скачать пару примеров — их коды переложить на наш код и свалить.
А мы потом будем расхлебывать....
А этот NDA.... Вы реально верите в его силу и необходимость и придерживаетесь его? Особенно в случае микрокуска кода?
несвязанного с какой-то патентной областью или ноу-хау конторы?

Здравствуйте, Аноним, Вы писали:

А>А этот NDA.... Вы реально верите в его силу и необходимость и придерживаетесь его? Особенно в случае микрокуска кода?
А>несвязанного с какой-то патентной областью или ноу-хау конторы?

Вы выбрали КОМ обёртку. Это не двух минутный патч. Вам нужно полностью переписать обёртку и добавить всё что уже упоминалось. Это работа, и не на один день. Ищите человека, вопросы и ответы вас ни куда не продвинут.

Здравствуйте, Аноним, Вы писали:

А>но! проблема, что стектрейс не полный (нет
А>интерфейса функций — мы видим тока библиотеки CLR времени исполнения дотнета), дамп тоже ничего не показывает
А>нормального — видимо не может он записать/показать инфу по managed коду, когда мы его вызываем из С++'ного.

Можно подробнее каким образом вы пытались смотреть managed стеки? Расширением sos для WinDbg пользовались?

Здравствуйте, Аноним, Вы писали:

Можно запускать managed код под самодельным отладчиком: http://msdn.microsoft.com/en-us/library/ms404484.aspx

А>>но! проблема, что стектрейс не полный (нет
А>>интерфейса функций — мы видим тока библиотеки CLR времени исполнения дотнета), дамп тоже ничего не показывает
А>>нормального — видимо не может он записать/показать инфу по managed коду, когда мы его вызываем из С++'ного.

BB>Можно подробнее каким образом вы пытались смотреть managed стеки? Расширением sos для WinDbg пользовались?

Если у вас есть дампы падения, то вполне возможно вся информация в них уже есть и дополнительно ничего прикручивать не нужно. Просто для анализа managed стека используются не те команды отладчика, что для анализа нативного (C++) кода. Начните с команды !analyze -v. Если она не показывает стек и исключение, можно попробовать так:

.loadby sos mscorwks // для .NET 3.5 и ниже

или

.loadby sos clr // для .NET 4.0 и выше

далее, например

~* e !dumpstack

Эта команда должна показать стеки всех потоков в дампе, включая managed.

А>Да, вы видим, чтото типа
А>mscorlib_ni+0x2f2bbb
А>mscorlib_ni+0x3675d1
А>mscorlib_ni+0x36740f

Отключите JIT. Убедитесь, что у вас есть CLR reference sources и правильные pdb. Это можно на сайте микрософта взять.

А>Причем бесит то — что почему то нашей библиотеки ни разу ни в одном стектрейсе не было видно.

Потому что стек у вас неправильный. А неправильный он потому что сохраняете дамп неправильно. Без контекста исключения. Вы может быть даже не в тот thread смотрите. А еще managed дампу флаги нужны другие, лучше всего сохранять все по максимуму, минидампом отделаться не получится, потому что managed heap.

А>Так что чем он ТАК принципиально отличается от WinDBG — что вы предлагаете юзать его при отладке
А>managed кода?

В вопросах сложной отладки C++, а особенно взаимодействия C++ и C#, отладчик студии может не потянуть. А windbg — сила.

Здравствуйте, Аноним, Вы писали:

А>Нет — WinDBG даже и не думали юзать — ибо на кой ляд тогда в купленной студии существует свой
А>дебаггер? С С++ кодом, что нам надо — он отлично справляется. И с дампами кода на основе С++ тоже.
А>Так что чем он ТАК принципиально отличается от WinDBG — что вы предлагаете юзать его при отладке
А>managed кода?

При открытии дампа в VS у вас есть кнопка "Debug with Mixed"? Или только "Debug with Native Only"?
Какую версию .NET используете?

Здравствуйте, breee breee, Вы писали:

BB>Здравствуйте, Аноним, Вы писали:

А>>Нет — WinDBG даже и не думали юзать — ибо на кой ляд тогда в купленной студии существует свой
А>>дебаггер? С С++ кодом, что нам надо — он отлично справляется. И с дампами кода на основе С++ тоже.
А>>Так что чем он ТАК принципиально отличается от WinDBG — что вы предлагаете юзать его при отладке
А>>managed кода?

BB>При открытии дампа в VS у вас есть кнопка "Debug with Mixed"? Или только "Debug with Native Only"?
BB>Какую версию .NET используете?

Debug with Native Only.
На всех компах в офисе стоит 4. Она же должна стоять и на машинах заказчика — ибо все проги ему были
выданы. тут этот момент мы проверить не можем — просто верим ему.
Но есть мини подозрение — ибо при открытии дампа в студии мы видим строку
Сведения о системе — версия среды исполнения — 2.0
WTF?
по идее такого быть не должно.

Здравствуйте, Аноним, Вы писали:

А>Debug with Native Only.
А>На всех компах в офисе стоит 4. Она же должна стоять и на машинах заказчика — ибо все проги ему были
А>выданы. тут этот момент мы проверить не можем — просто верим ему.
А>Но есть мини подозрение — ибо при открытии дампа в студии мы видим строку
А>Сведения о системе — версия среды исполнения — 2.0
А>WTF?
А>по идее такого быть не должно.

Версия CLR 2.0 соответствует .NET версий 2.0, 3.0 и 3.5, но не .NET 4.0. Mixed-mode debugging дампов в студии поддерживается только для .NET 4.0+. Скорее всего поэтому вы не можете посмотреть managed-стеки.

Здравствуйте, breee breee, Вы писали:

BB>Здравствуйте, Аноним, Вы писали:

А>>Debug with Native Only.
А>>На всех компах в офисе стоит 4. Она же должна стоять и на машинах заказчика — ибо все проги ему были
А>>выданы. тут этот момент мы проверить не можем — просто верим ему.
А>>Но есть мини подозрение — ибо при открытии дампа в студии мы видим строку
А>>Сведения о системе — версия среды исполнения — 2.0
А>>WTF?
А>>по идее такого быть не должно.

BB>Версия CLR 2.0 соответствует .NET версий 2.0, 3.0 и 3.5, но не .NET 4.0. Mixed-mode debugging дампов в студии поддерживается только для .NET 4.0+. Скорее всего поэтому вы не можете посмотреть managed-стеки.

но мы же точно ставили дотнет 4 версии. КАК тогда мы могли получить CLR 2.0?

может в студии для дотнета надо спецопции включать? мыж ее тока под С++ затачивали...

Здравствуйте, Аноним, Вы писали:

BB>>Версия CLR 2.0 соответствует .NET версий 2.0, 3.0 и 3.5, но не .NET 4.0. Mixed-mode debugging дампов в студии поддерживается только для .NET 4.0+. Скорее всего поэтому вы не можете посмотреть managed-стеки.

А>но мы же точно ставили дотнет 4 версии. КАК тогда мы могли получить CLR 2.0?

А>может в студии для дотнета надо спецопции включать? мыж ее тока под С++ затачивали...

Но дамп-то взят не с ваших машин, я правильно понял? Возможно, заказчик не установил .NET 4.0, а использует более старую версию, оттого и падения и до вашей библиотеки дело не доходит.
В студии, при открытии дампа в списке модулей, какой версии модули mscoree.dll и mscorlib.ni.dll?

Здравствуйте, breee breee, Вы писали:

BB>Здравствуйте, Аноним, Вы писали:

BB>>>Версия CLR 2.0 соответствует .NET версий 2.0, 3.0 и 3.5, но не .NET 4.0. Mixed-mode debugging дампов в студии поддерживается только для .NET 4.0+. Скорее всего поэтому вы не можете посмотреть managed-стеки.

А>>но мы же точно ставили дотнет 4 версии. КАК тогда мы могли получить CLR 2.0?

А>>может в студии для дотнета надо спецопции включать? мыж ее тока под С++ затачивали...

BB>Но дамп-то взят не с ваших машин, я правильно понял? Возможно, заказчик не установил .NET 4.0, а использует более старую версию, оттого и падения и до вашей библиотеки дело не доходит.
BB>В студии, при открытии дампа в списке модулей, какой версии модули mscoree.dll и mscorlib.ni.dll?

хренотень какая то... mscoree.dll — 4.0. mscorlib.ni.dll — 2.0. mscorjit.dll — 4.0 и вот так вот чередование идет....
Да ну как такое возможно? что это за тупейшие грабли?

BB>>Но дамп-то взят не с ваших машин, я правильно понял? Возможно, заказчик не установил .NET 4.0, а использует более старую версию, оттого и падения и до вашей библиотеки дело не доходит.
BB>>В студии, при открытии дампа в списке модулей, какой версии модули mscoree.dll и mscorlib.ni.dll?

А>хренотень какая то... mscoree.dll — 4.0. mscorlib.ni.dll — 2.0. mscorjit.dll — 4.0 и вот так вот чередование идет....
А>Да ну как такое возможно? что это за тупейшие грабли?

Это выглядит как будто у них установлен 4.0, но ваша программа просит версию ниже.
У вас в свойствах C#-проекта точно Target framework выставлен .NET Framework 4.0 (а также либа требует эту версию)?

Здравствуйте, breee breee, Вы писали:

BB>>>Но дамп-то взят не с ваших машин, я правильно понял? Возможно, заказчик не установил .NET 4.0, а использует более старую версию, оттого и падения и до вашей библиотеки дело не доходит.
BB>>>В студии, при открытии дампа в списке модулей, какой версии модули mscoree.dll и mscorlib.ni.dll?

А>>хренотень какая то... mscoree.dll — 4.0. mscorlib.ni.dll — 2.0. mscorjit.dll — 4.0 и вот так вот чередование идет....
А>>Да ну как такое возможно? что это за тупейшие грабли?

BB>Это выглядит как будто у них установлен 4.0, но ваша программа просит версию ниже.
BB>У вас в свойствах C#-проекта точно Target framework выставлен .NET Framework 4.0 (а также либа требует эту версию)?

в свойствах точно выставлено. ну а уж требует ли либа при старте этот 4 нет или нет — не понятно.
по идее она не должна подгружаться, если не находит подходящего CLR... но эт в теории...

А>в свойствах точно выставлено. ну а уж требует ли либа при старте этот 4 нет или нет — не понятно.
А>по идее она не должна подгружаться, если не находит подходящего CLR... но эт в теории...

Можно узнать при помощи такой команды:

ildasm.exe library.dll /metadata[=MDHEADER] /text /noil

Вывод:

// ================================= M E T A I N F O ================================================

// ===========================================================
// Metadata section: 0x424a5342, version: 1.1, extra: 0, version len: 12, version: v4.0.30319
//            flags: 0x00, streams: 5
...

Здравствуйте, Аноним, Вы писали:

А>таких глюков по теории и быть то не должно. но они есть....

Это Вам кажется, бо Вы теорией не владеете.

CLR всегда поддерживала side-by-side исполнение для обычного managed-кода. А с 4.0 поддерживает сию фичу и для managed COM-компонент. Теперь оные по-умолчанию запускаются в той версии CLR, для которой были собраны. В независимости от того, была ли загружена в процесс другая версия CLR.

Так что иметь две версии CLR в одном процессе — тривиально.

Здравствуйте, drol, Вы писали:

D>Здравствуйте, Аноним, Вы писали:

А>>таких глюков по теории и быть то не должно. но они есть....

D>Это Вам кажется, бо Вы теорией не владеете.

D>CLR всегда поддерживала side-by-side исполнение для обычного managed-кода. А с 4.0 поддерживает сию фичу и для managed COM-компонент. Теперь оные по-умолчанию запускаются в той версии CLR, для которой были собраны. В независимости от того, была ли загружена в процесс другая версия CLR.

D>Так что иметь две версии CLR в одном процессе — тривиально.

т.е. независимо от того, что либу собрали с жестким условием — работать тока с версией 4.0 — в реальности она может запуститься и под 2.0?
по вашей цитате "запускаются в той версии CLR, для которой были собраны" — но собрано то было под и для 4.0. Что же она с компонентами 2.0 то работает?

Здравствуйте, Аноним, Вы писали:

А>т.е. независимо от того, что либу собрали с жестким условием — работать тока с версией 4.0 — в реальности она может запуститься и под 2.0?

И как Вы умудрились из моего постинга сделать такой вывод

А>по вашей цитате "запускаются в той версии CLR, для которой были собраны" — но собрано то было под и для 4.0. Что же она с компонентами 2.0 то работает?

С чего Вы решили, что это именно Ваша компонента работает в CLR 2.0 ?

Здравствуйте, drol, Вы писали:

D>Здравствуйте, Аноним, Вы писали:

А>>т.е. независимо от того, что либу собрали с жестким условием — работать тока с версией 4.0 — в реальности она может запуститься и под 2.0?

D>И как Вы умудрились из моего постинга сделать такой вывод
дык ну под не понятен до конца был пост — поэтому я не вывод сделал(и откуда Вы вывод сделали, что эт я вывод сделал ) — а вопрос задал,
мол вот так что ли понимать Ваши слова надо? Если не так — проясните.

А>>по вашей цитате "запускаются в той версии CLR, для которой были собраны" — но собрано то было под и для 4.0. Что же она с компонентами 2.0 то работает?

D>С чего Вы решили, что это именно Ваша компонента работает в CLR 2.0 ?

В нашей проге более нет ничегошеньки дотнетовского. И если я сделал дамп при падении и в дампе я нахожу сведения о том, что использовался CLR 2.0
и вижу модули подгруженные для дотнета 2 и 4, то для какого же компонента он тогда мог использоваться? Или дотнет во все процессы проникает — как вирус?
И упоминания о нем можно просто вот в любом дампе для любой проги найти?