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