Могу ли я использовать библиотеку .NET 4.0 в приложении .NET 2.0?
Это похоже на то, что вы пытаетесь сделать. Но я не буду рекомендовать это, поскольку читаемость страдает.
data = [('a',1),('b',3),('a',4),('c',9),('b',1),('d',3)]
print reduce(lambda d,i: [d.__setitem__(i[0],d.get(i[0],0)+i[1]),d][1], data, {})
Выход
{'a': 5, 'c': 9, 'b': 4, 'd': 3}
5 ответов
Да, это вполне возможно. Вы просто представляете компоненты, написанные в 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 , который является сохраняя действующий компонент.
Это означает, что - при достаточно сложном расположении указателей обратного вызова и т. Д. - система может столкнуться с проблемами циклического подсчета ссылок, когда отключенный «остров» объектов содержит ссылки друг на друга, и поэтому они никогда не получают освобожден.
Обратите внимание, что версия 4.0 - это больше, чем просто дополнительные сборки. Сама среда выполнения также была изменена в этой версии (новый режим параллельной сборки мусора, множество изменений в пуле потоков, mscorwks.dll теперь называется clr.dll и т. Д.).
Похоже, что функция параллельной обработки внутри процесса, которая была добавлена в CLR 4, не поможет в этом случае, поскольку он хочет использовать библиотеку .NET4.0 в приложении .NET2.0. Насколько я понимаю, внутрипроцессный SxS был бы полезен, если бы все было наоборот (использование .NET2.0 в приложении .NEt4.0), поскольку CLR 4.0 будет работать бок о бок с 2.0 в тот же процесс ..
Это может быть возможно в зависимости от того, как вы его используете. В .Net 4.0 у вас есть возможность параллельного выполнения в процессе (InProc SxS). Это позволяет размещать две разные версии CLR в одном пространстве процессов. Это объясняется здесь .
Не знаю, сможете ли вы воспользоваться этим в вашей ситуации. У меня нет прямого опыта, чтобы помочь вам.
Некоторые сценарии , в которых это может быть использовано.
Ваша сборка, скомпилированная для .NET 4, будет содержать ссылки на другие библиотеки фреймворка .NET 4, которых нет в .NET 2.0.
Если вы хотите, чтобы ваши приложения были совместимы с .NET 2.0, вы можете использовать Visual Studio 2005 или нацелить ваши проекты на .NET 2.0, если вы используете Visual Studio 2008 или 2010. Конечно, если вы нацелите свои проекты на .NET 2.0, вы не сможете воспользоваться возможностями .NET 3.5/4.