.NET эквивалент статических библиотек? - PullRequest
5 голосов
/ 02 октября 2009

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

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

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

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

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

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

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

Ответы [ 7 ]

6 голосов
/ 02 октября 2009

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

2 голосов
/ 02 октября 2009

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

1 голос
/ 12 ноября 2009

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

1 голос
/ 02 октября 2009

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

0 голосов
/ 02 октября 2009

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

0 голосов
/ 02 октября 2009

Remotesoft Salamander подключит вас. Это в основном нативный компилятор и компоновщик.

0 голосов
/ 02 октября 2009

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

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

...