Visual Studio 2010 — связывание библиотеки Common Language Runtime (/ clr) .dll со статическими библиотеками, статически связанными с C / C ++ Runtime Library.

У меня есть приложение WPF, которое я компилирую в Visual Studio 2010, которое использует CLR .dll для взаимодействия с некоторым неуправляемым кодом C / C ++. Идея состоит в том, что WPF ссылается на CLR .dll, которая, в свою очередь, ссылается на неуправляемый код. К сожалению, я сталкиваюсь с ужасными проблемами компоновки, потому что неуправляемый код C / C ++ и связанные библиотеки все статически связываются со средой выполнения C / C ++, но если я пытаюсь использовать этот метод генерации кода в CLR .dll, он выдает ошибку потому что опция / clr и статическое связывание с CRT несовместимы. Мне нужно как-то склеить эти вещи.

Я думал, чтобы попытаться создать дополнительный .DLL, которая просто содержит весь неуправляемый код в одном пакете (также статически связанный с CRT), затем ссылка тот в CLR .dll, которая, в свою очередь, ссылается на приложение (блех!). Я пытался создать такой .dll, но проблема в том, что (может быть, очевидно?) Он не извлекал ни одного символа из статических файлов .lib, потому что он не нуждался ни в одном из них. Я пытался форсировать ссылки на символы (/ OPT: NOREF), но это не помогло. Это просто пустой .dll, который «связывает» с библиотеками, но на самом деле ничего не делает. Так что большой провал в этой идее.

Я все неправильно понимаю?

У меня нет исходного кода для некоторых неуправляемых библиотек, поэтому я не могу перекомпилировать их для динамической связи с CRT. Эти проблемы связывания становятся действительно расстраивающими!

Спасибо за любые предложения!

ОБНОВИТЬ: Я думаю, это равносильно попытке смешать /MT а также /MD модули вместе, которые, согласно этому, это невозможно. Как получается, что вы должны связывать проекты, в которых у вас нет контроля над сторонними библиотеками? Вы просто надеетесь, что все они выбрали один и тот же метод компоновки библиотеки времени выполнения ?! Похоже, ужасная идея …