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

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

EDIT. Я понимаю, что мне нужно установить .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.

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

Если вы можете воспользоваться этим в своем situtaion, я не знаю. У меня нет прямого опыта, чтобы помочь вам.

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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