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