Плагин — сборка .NET 2.0 mixed-mode, ее неуправляемые функции импортируются процессом-хостом. Когда хост неуправляемый или .NET 2.0 и выше — все работает нормально. Когда хост .NET 1.0, происходит ошибка — err: 1114 A dynamic link library (DLL) initialization routine failed
В чем может быть причина?

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

AF>Плагин — сборка .NET 2.0 mixed-mode, ее неуправляемые функции импортируются процессом-хостом. Когда хост неуправляемый или .NET 2.0 и выше — все работает нормально. Когда хост .NET 1.0, происходит ошибка — err: 1114 A dynamic link library (DLL) initialization routine failed
AF>В чем может быть причина?

В том, что сборка .NET 2.0 будет запускаться только на фрейворке 2.0 и выше, что логично.

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

AS>В том, что сборка .NET 2.0 будет запускаться только на фрейворке 2.0 и выше, что логично.

Здесь должен работать side-by-side execution

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

AF>Здесь должен работать side-by-side execution
Должен. Но не волшебным образом, а явно.
Здесь написано, что нужно написать в хост.exe.config чтобы он испоьзовал .net 2.0 CLI, с которым ваш плагин будет работать.

У меня таким образом reflector.exe грузит мой плагин, который я на .net 3.5 собираю.

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

БП>Должен. Но не волшебным образом, а явно.

С неуправляемым хостом все работало автоматически.
А нельзя сделать, чтобы сам хост работал в CLR 1.0, а плагин в 2.0? С точки зрения хоста плагин — это просто unmanaged DLL, которая вызывается через pinvoke.

Здравствуйте, Andrei F., Вы писали:
AF>Здесь должен работать side-by-side execution
С чего бы это? Side-by-side относится к разным приложениям, а не к коду внутри одного приложения.

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

AF>С неуправляемым хостом все работало автоматически.
Потому что автоматически запускалась нужная версия CLR.
AF>А нельзя сделать, чтобы сам хост работал в CLR 1.0, а плагин в 2.0? С точки зрения хоста плагин — это просто unmanaged DLL, которая вызывается через pinvoke.
Нет, нельзя. В одном хост-процессе может жить только один CLR.

Именно поэтому, в частности, не рекомендуется делать управляемые плагины к неуправляемым программам. Со стороны хоста нужна шибко специальная поддержка для такой функциональности — в частности, IIS гоняет ASP.NET на разных версиях CLR в разных Application Pools.

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

S>Нет, нельзя. В одном хост-процессе может жить только один CLR.

Где написано, что нельзя?

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

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

S>>Нет, нельзя. В одном хост-процессе может жить только один CLR.

AF>Где написано, что нельзя?

Где-то в МСДН. Искать надо по ключевым словам "managed, extension, explorer".

К примеру, управляемое расширение на 1.1 в экплорере внедряет CLR 1.1 во все системные диалоги, в том числе и OpenFileDialog. При вызове ofd bз приложения на .Net 2.0 и старше — приложение упадёт.

Почитать можно здесь

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

AF>С неуправляемым хостом все работало автоматически.
AF>А нельзя сделать, чтобы сам хост работал в CLR 1.0, а плагин в 2.0? С точки зрения хоста плагин — это просто unmanaged DLL, которая вызывается через pinvoke.

Выносите свою unmanaged dll в отдельный процесс. Две версии CLR в один процесс загрузить нельзя

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

TK>Выносите свою unmanaged dll в отдельный процесс. Две версии CLR в один процесс загрузить нельзя

Боюсь, что придется — хост не работает в 2.0. Есть идеи, как это сделать проще всего?

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

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

TK>>Выносите свою unmanaged dll в отдельный процесс. Две версии CLR в один процесс загрузить нельзя

AF>Боюсь, что придется — хост не работает в 2.0. Есть идеи, как это сделать проще всего?

dll surrogate?

Здравствуйте, Константин Л., Вы писали:

КЛ>dll surrogate?

Ну это очевидно. Где и как запускать настоящую dll, как передавать параметры — это уже посложнее.

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

AF>Здравствуйте, Константин Л., Вы писали:

КЛ>>dll surrogate?

AF>Ну это очевидно. Где и как запускать настоящую dll, как передавать параметры — это уже посложнее.

если это COM, то все очевидно

Здравствуйте, Константин Л., Вы писали:

КЛ>если это COM, то все очевидно

только это не COM завернуть сборку в COM — тоже в принципе решение, но это много ручной работы

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

AS>Где-то в МСДН. Искать надо по ключевым словам "managed, extension, explorer".
AS>К примеру, управляемое расширение на 1.1 в экплорере внедряет CLR 1.1 во все системные диалоги, в том числе и OpenFileDialog. При вызове ofd bз приложения на .Net 2.0 и старше — приложение упадёт.
AS>Почитать можно здесь

Да, очень неприятная особенность. К слову, у Silverlight CLR такого ограничения нет — в одном процессе могут жить несколько любых версии Silverlight CLR и обычный CLR одновременно. Но Silverlight CLR по неизвестным причинам не позволяет создавать standalone приложения.