.NET-эквивалент статических библиотек?

Question

Я создаю инструмент на управляемом коде (в основном C++/CLI) в двух версиях: «обычной пользовательской» и «профессиональной» версии.

Тот факт, что основной код обеих версий идентичен, доставил мне небольшие проблемы, поскольку я хочу упаковать полученный инструмент как единую сборку (DLL) и не хочу включать файлы .cpp для общего использования. код в проектах двух версий инструментов.Я бы предпочел иметь проект для общего кода и проект для каждой версии инструмента, и чтобы каждая версия проекта инструментов зависела от общего кода и связывала его по желанию.

В неуправляемом C++ я бы сделал это, поместив общий код в статическую библиотеку и связав с ней обе версии инструмента.Кажется, я не могу заставить это работать на C++/CLI.Кажется, я вынужден встроить общий код в сборку DLL, и в результате получается больше DLL, чем хотелось бы.

Итак, подытоживая, я не могу понять, как собрать общий код в одном проекте и связать его с каждым конечным проектом продукта, чтобы создать две отдельные сборки DLL, обе из которых включают общий код.

Вероятно, я делаю что-то не так, но я пытался понять, как это сделать, используя сетевые модули и что-то еще, но у меня просто не получилось заставить это работать.В конце концов, единственный способ заставить это работать - это сказать компоновщику связать продукты сборки общего кода, а не результаты, что работает, но, ИМХО, это немного хак.

В любом случае, есть ли у кого-нибудь предложения о том, как мне ДОЛЖНО решить эту проблему?

Отредактировано: Думаю, мне следовало упомянуть тот факт, что генерируемые сборки не являются 100% управляемым кодом, они содержат смесь управляемого и неуправляемого кода, что, вероятно, довольно часто встречается в сборках, созданных с помощью C++/CLI...

Answer 1

Если вас раздражают все библиотеки DLL, скачайте ILMerge.Я использую это для объединения нескольких DLL в простой в использовании .EXE-файл для моих клиентов.

Answer 2

Как сказано, ILmerge - это один из способов, лично я предпочитаю, если вы объединяете какой-то exe с большим количеством dll. Нетц.

Answer 3

Вы могли бы использовать модули.Вы можете связать их в сборку с помощью компоновщика сборок. al.exe.

Answer 4

Если я правильно понимаю, у вас есть решение, содержащее два проекта.Один проект для «обычного» пользователя и один проект для «профессионала».Visual Studio позволяет добавлять «ссылку» на другой источник файла из другого проекта.Если в вашей «профессиональной» версии есть настоящий файл основного кода, а в «обычной» версии вы добавляете существующий -> найдите файл в «про» проекте, щелкните стрелку вниз кнопкой «Добавить» и выберите «Добавить как ссылку». ".Теперь у вас есть один и тот же файл в двух проектах.

Answer 5

Это обратная сторона процесса компиляции .Net: у вас не может быть таких вещей, как статические библиотеки и файлы заголовков, которые их объединяют, все хранится в одном большом файле DLL, и единственный способ поделиться информацией - это либо создать общую DLL, либо создать общую DLL. и ссылаться на него из других сборок или дублировать код в каждой dll (возможно, путем копирования/связывания файлов .cs между проектами).

Обратите внимание, что второй способ будет объявлять разные типы, даже если они имеют одно и то же имя.Это укусит вас за задницу такими вещами, как удаленное взаимодействие (или что-то еще, что требует приведения к определенным общим интерфейсам между процессами).

Answer 6

Дистанционное программное обеспечение Саламандра подцепит тебя.По сути, это собственный компилятор и компоновщик.

Answer 7

При использовании моно (или cygwin — опция) мкбандл также может быть правильным выбором.