Могу ли я использовать библиотеку .NET 4.0 в приложении .NET 2.0?

Question

У меня проблемы с использованием библиотек .NET 4.0 в приложениях .NET 2.0. Думаю, у меня сложилось впечатление, что, будучи Windows DLL, мои другие приложения .NET смогут получить к ней доступ. Разве это не так? Любые рекомендации по поддержке приложений в обеих средах?

РЕДАКТИРОВАТЬ : я понимаю, что мне нужно установить .NET 4.0 Framework на целевой системе, есть ли другие причины, по которым это не будет / не должно работать?

РЕДАКТИРОВАТЬ : Вероятно, должно быть более конкретным. У нас есть текущее, большое / сложное приложение, написанное на .NET 2.0 (точнее ASP.NET). У нас есть новый набор инструментов интеграции и элементов рабочих процессов, которые мы пишем в .NET 4.0. Мы хотели добавить одну из созданных библиотек 4.0 в проект .NET 2.0 (в настоящее время в VS2008) и использовать несколько его методов. Когда мы делаем это, мы сталкиваемся с проблемами, часто загадочными ошибками, связанными с памятью.

Похоже, что и Уорвикер, и Брайан Расмуссен в конце верны. Поскольку я не слишком заинтересован в том, чтобы разоблачать вещи через COM (не уверен, технически ли это COM или нет, но независимо от этого), я думаю, что я буду придерживаться идеи, что эти два понятия не «совместимы», и буду искать другие способы, которые, я думаю, мы основаны на наших конкретных потребностях. В долгосрочной перспективе мы рассмотрим возможность перемещения кода .NET 2.0 до 4.0.

Answer 1

Да, это вполне возможно. Вы просто выставляете компоненты, написанные в 4.0, как COM-объекты. Хостинговое приложение 2.0 просто использует их как COM-объекты и не знает, являются ли они родными, 2.0, 4.0 или чем-то еще. COM - это общий интерфейс, который обе версии времени выполнения должны реализовывать одинаково.

Новая внутрипроцессная поддержка SxS в 4.0 означает, что при загрузке COM-объекта на основе 4.0 он загружает требуемое время выполнения вместо попытки запуска на 2.0, поэтому обе среды выполнения присутствуют в процессе, управляющем своими собственными объекты. Хотя вы не можете напрямую передавать объекты CLR между ними, вы можете передавать интерфейсы COM, и CLR прозрачно оборачивает ваши объекты в интерфейсы COM для вас.

Я не знаю, можно ли сделать одну сборку взаимодействия для обеих версий. Но ясно, что вы можете написать сборку взаимодействия в C # в 2.0, экспортировать ее в .tlb, а затем импортировать в сборку в 4.0. Это дает вам две совпадающие сборки взаимодействия, описывающие идентичные интерфейсы COM. (Или просто создайте один и тот же источник C # в проекте сборки каждой версии).

Обновление бонуса: Будет ли полученное приложение основано на COM (с какими бы то ни было проблемами)?

Зависит от того, как вы на это смотрите. Авторы компонентов будут делать их как компоненты COM. Поэтому хост-приложение должно найти и загрузить их как компоненты COM. Это означает дурачиться с GAC, реестром или манифестами SxS, что гораздо менее чисто, чем просто указывать авторам компонентов отбрасывать их сборки в определенном каталоге, чтобы вы могли загрузить их с отражением.

И это оказывает влияние во время выполнения: когда хост имеет ссылку на компонент, будет задействован не один, а три объекта. Хост имеет ссылку на RCW, который имеет указатель на интерфейс COM, реализованный CCW, который, в свою очередь, содержит ссылку на фактический компонент. CCW в середине - это COM-объект с подсчетом ссылок, а RCW хоста имеет финализатор, который вызывает Release на CCW, и когда он уничтожается, он освобождает GCRoot, который поддерживает действительный компонент.

Это означает, что - при достаточно сложном расположении указателей обратного вызова и т. Д. - система может столкнуться с проблемами подсчета циклических ссылок, когда все отключенные «островки» объектов содержат ссылки друг на друга, и поэтому они никогда не получат перераспределена.

Answer 2

Я только что опубликовал пост, в основном то, что предложил Даниэль.

Как использовать DLL на основе .NET 4 из приложения на основе .NET 2

Исходный код и описание по адресу: http://code.msdn.microsoft.com/Using-a-NET-4-Based-DLL-bb141db3

Answer 3

Обратите внимание, что версия 4.0 - это больше, чем просто дополнительные сборки. Само время выполнения также было изменено в этой версии (новый параллельный режим GC, множество изменений в пуле потоков, mscorwks.dll теперь называется clr.dll и т. Д.).

Answer 4

Это может быть возможно в зависимости от того, как вы его используете. В .Net 4.0 у вас есть опция В процессе параллельного выполнения (InProc SxS). Это позволяет размещать две разные версии CLR в одном и том же пространстве процесса. Это объяснено здесь .

Можете ли вы воспользоваться этим в вашей ситуации, я не знаю. У меня нет прямого опыта, чтобы помочь вам.

Некоторые сценарии , в которых это можно использовать.

Answer 5

Похоже, что внутренняя параллельная функция, которая была добавлена ​​в CLR 4, не поможет в этом случае, поскольку он хочет использовать библиотеку .NET4.0 в приложении .NET2.0. Насколько я понимаю, внутрипроцессный SxS был бы полезен, если бы ситуация была противоположной (использование .NET2.0 в приложении .NEt4.0), поскольку CLR 4.0 будет работать бок о бок с 2.0 в тот же процесс ..

Answer 6

У меня была похожая проблема с моим приложением, когда я не мог ссылаться на API, который использовал компоненты .net 4.0.
Чтобы решить эту проблему, я создал новый проект библиотеки классов, который ссылался на мой проект .net 4.0, а затем вызвал эту новую сборку из моего проекта .net 2.0. Я сопоставил данные, возвращаемые из проекта .net 4.0, которые будут использоваться моим проектом .net 2.0.
Это решило мою проблему.

Answer 7

Ваша сборка, скомпилированная для .NET 4, будет содержать ссылки на другие библиотеки .NET 4 Framework, которых нет в .NET 2.0.

Если вы хотите, чтобы ваши приложения были совместимы с .NET 2.0, вы можете использовать Visual Studio 2005 или target свои проекты в .NET 2.0, если вы используете Visual Studio 2008 или 2010. Конечно, если вы Направляя свои проекты на .NET 2.0, вы не сможете воспользоваться функциями .NET 3.5 / 4.