Можем ли мы иметь DLL, встроенную в .Net V2.0, ссылаться на другую встроенную в .Net V4.5?

Мне нужно иметь встроенную DLL в .net v2.0, которая будет вызываться из SQL Server 2008 как внешняя DLL (сборка CLR). Эта dll должна быть в .net v2.0, чтобы быть совместимой с нашей версией SQL Server, и предназначена только для создания моста между SQL Server и другими функциями C #, разработанными в .net V4.5. Поэтому я ссылаюсь на другую DLL, встроенную в .Net V4.5, но я не могу ее скомпилировать! У меня следующее предупреждение:

предупреждение MSB3258: не удалось разрешить первичную ссылку «my_dll», поскольку она косвенно зависит от сборки .NET Framework «mscorlib, Version = 4.0.0.0, Culture = нейтральный, PublicKeyToken = b77a5c561934e089», имеющей более высокую версию «4.0. 0.0 ", чем версия" 2.0.0.0 "в текущей целевой платформе.

Можем ли мы игнорировать совместимость версий сборки? Или у нас есть другое решение для вызова любой функции, разработанной в .net V.4.5, из SQL Server 2008?


c#
person Mr. Green    schedule 28.01.2017    source источник
comment
Это не может работать, потому что версия CLR вашего SQL Server тоже 2.0. Он не может загрузить сборку 4.5, даже если эта сборка вообще не ссылается ни на какие другие системные сборки (что, конечно, так). Перекомпилируйте все сборки для целевой .NET 2.0 или обновите свой сервер.   -  person Jeroen Mostert    schedule 28.01.2017
comment
@JeroenMostert выглядит так, как будто вы ввели ответ в поле для комментариев.   -  person Martin Smith    schedule 28.01.2017
comment
@MartinSmith: Я знаю, но это потому, что я ненавижу давать ответ: нет, ты не сможешь этого сделать без того, чтобы мой мозг, любящий проблемы, в любом случае очень, очень старался найти какое-то решение (может быть, ты мог бы злоупотребить COM! в этом случае вы могли бы ошибиться с заголовком версии сборки! Может быть ... ЗАКРЫТЬ). И ОП просил другое решение, и я знаю, что вопросы, на которые уже есть ответ, привлекают меньше внимания. ... Я перестану болтать.   -  person Jeroen Mostert    schedule 28.01.2017
comment
Единственная возможность выполнить эту работу (о которой я могу думать) - это какой-то другой компонент, не входящий в процесс, который нацелен на CLR 4.0, и механизм IPC. Честно говоря, вам придется пережить много горя, чтобы все заработало чисто. Комментарий Джероена действительно правильный ответ - обновите SQL.   -  person lesscode    schedule 28.01.2017

Ответы (2)


arrow_upward
0
arrow_downward

Я не уверен, что понимаю ваш вопрос, но чтобы ответить на него, вам просто нужно изменить зависимость проекта на .NET 4.5. Платформы .NET могут ссылаться на другие версии инфраструктуры, но вы должны учитывать порядок зависимости. Если 2.0 использует библиотеку 4.0, тогда он выйдет из строя, потому что у него нет собственной ссылки на компоненты. Когда ваш проект компилируется, он помещается в одну сборку, и эта сборка должна иметь ссылку на все используемые ингредиенты. Тем не мение; если ваши проекты представляют собой отдельные DLL, что звучит так, как будто они есть, тогда вы можете ссылаться между ними, пока члены 4.0 не отображаются публично в сборке. Тем не мение; это означает, что для работы dll требуется среда с установленной версией 4.0.

Чтобы запускать разные версии одних и тех же сборок, вам необходимо добавить AssemblyBinding в конфигурацию вашего проекта.

За этим немного сложно следить, но посмотрите этот пост и посмотрите, поможет ли он вам лучше понять, как этого добиться.

Опубликовать

person Michael Puckett II    schedule 29.01.2017

arrow_upward
0
arrow_downward

В соответствии с этим ответом здесь можно ссылаться на сборку .Net 4.5, выставив необходимые компоненты как COM. Все версии .Net основаны на COM в своей основе, поэтому его можно использовать в качестве канала связи с «наименьшим общим знаменателем». В зависимости от ваших требований вы также можете изучить использование именованных каналов, IPC или даже веб-служб.

person Willem van Ketwich    schedule 29.01.2017