У нас есть (чистый нативный C ++) .DLL, созданный VS. В качестве клиентов у нас есть несколько собственных приложений C ++ и .Net-Wrapper вокруг этой DLL, написанной на C ++ / CLI. Наконец, есть несколько клиентских приложений для .Net-Wrapper, написанных на C #.
Моя проблема заключается в том, что native.dll должен распространяться не так, как мир .Net, а VS не отслеживает эту DLL.
Поэтому, чтобы все мои приложения на C # работали правильно, я должен скопировать его в каждый исполняемый каталог или поместить его где-нибудь в% PATH% (чего я бы не хотел использовать на компьютерах разработчиков, поскольку они могут захотеть запускать разные приложения с разными версиями DLL).
Еще большие проблемы возникают, если существуют UserControls, которые ссылаются на Wrapper-DLL: Вы должны скопировать DLL в каталог VS или снова в% PATH%.
Но худший случай происходит с нашим инструментом Переводчик. Этот инструмент отслеживает .Net-сборки и упаковывает их в пакеты-переводчики, которые можно отправить внешнему переводчику. Насколько я знаю, нет никакого способа поместить нативный .DLL в этот пакет!
Так что я планирую статически связать нативную DLL в .Net-Wrapper, что решит мои проблемы.
Но для наших родных приложений эта нативная DLL должна быть DLL.
Так что у меня есть два варианта:
- Сделайте два проекта из этого (один, который генерирует статическую библиотеку; и другой, который создает динамическую библиотеку => Я стараюсь избегать этого)
- Найти решение для статической связи библиотек DLL
- Найдите способ позволить VS генерировать два выхода из одного проекта