Что мне делать с файлами содержимого при совместном использовании DLL сборки с другим программистом?

У меня есть проект библиотеки, в котором есть некоторые файлы содержимого (например, файлы XML и схемы, файлы изображений и т. Д.), Все с действием сборки, установленным на Content (всегда копировать).

Этот проект библиотеки находится в решении Visual Studio, в котором также есть тестовое приложение (WPF), которое ссылается на библиотеку.

Когда я создаю решение, все файлы содержимого из проекта зависимой библиотеки копируются в папку bin моего тестового приложения. (Они также копируются в папку bin проекта библиотеки.)

Сегодня я передал сборочную dll, сгенерированную моим библиотечным проектом, другому программисту для справки. Однако мне даже в голову не пришло, что этого недостаточно. Мне также нужно было передать ему файлы с контентом. Я так и сделал, и он добавил их в свой проект.

Это решение работает, но мне оно неудобно. Мне не нравится, что файлы содержимого смешиваются с файлами его проекта. Это увеличивает вероятность того, что они могут быть случайно изменены или удалены.

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

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

Спасибо.

РЕДАКТИРОВАТЬ:

Мне пришла в голову идея, что я могу скопировать только структуру папок и файлы содержимого из моего проекта библиотеки в новый проект библиотеки классов. Затем любой, кто ссылается на мой проект библиотеки, может добавить эту минимальную библиотеку классов в свое решение. Им все равно придется ссылаться на dll как на отдельный шаг, но это определенно лучше, чем текущее решение. Возможно, я мог бы даже написать событие после сборки, которое автоматически копирует все файлы содержимого из моего проекта библиотеки в минимальную библиотеку классов. (Теперь мне просто нужно исследовать, как на самом деле написать событие сборки :)). Комментарии приветствуются.

ИЗМЕНИТЬ 2:

Я построил свое первоначальное редактирование, чтобы придумать решение, которым, как мне кажется, буду доволен. Смотрите мой ответ ниже.


person devuxer    schedule 30.07.2009    source источник


Ответы (2)


Сделайте файлы содержимого встроенными ресурсами. Затем вы можете получить к ним доступ с помощью Assembly.GetManifestResourceStream(). Это делает вашу сборку намного более переносимой - вы больше не полагаетесь на расположение файловой системы во время выполнения.

person Jon Skeet    schedule 30.07.2009
comment
@Jon, это определенно решит проблему переносимости, но мне нужно, чтобы клиенты этой библиотеки могли просматривать файлы содержимого, поэтому я в первую очередь сделал их содержимым. - person devuxer; 30.07.2009
comment
@DanThMan: Не могли бы вы написать отдельный инструмент (или метод) для извлечения ресурсов для тех, кому они нужны, в виде отдельных файлов, но сохранить их в сборке для тех, кому они не нужны? - person Jon Skeet; 30.07.2009
comment
@Jon, Хм, вы имеете в виду создать собственный установщик для проекта моей библиотеки, который устанавливает файлы dll и содержимого непосредственно в папку bin приложения, ссылающегося на него? Я уверен, что что-то подобное возможно, но это звучит как небольшая затея. - person devuxer; 30.07.2009
comment
Не установщик, а отдельный исполняемый файл. Отчасти проблема в том, что я не знаю, для чего предназначена ваша библиотека, кто ваши клиенты и почему им нужно видеть файлы в файловой системе. - person Jon Skeet; 30.07.2009
comment
@Jon, это немного сложно объяснить, но одна из проблем заключается в том, что у меня есть набор схем XML, который содержит файлы xsd как из ссылающегося приложения , так и из указанной библиотеки. В частности, приложение расширяет указанный файл xsd с помощью элемента ‹xs: redefine›, добавляя дополнительные элементы таблицы к базовым таблицам, необходимым библиотеке. В результате получается одна большая схема, содержащая все таблицы и ключи / ключевые ссылки для установления ссылочной целостности. Таким образом, ссылающемуся приложению требуется доступ к файлам xsd из указанной библиотеки. - person devuxer; 30.07.2009
comment
Как они проделывают эту манипуляцию с XSD? Кажется, они могут вызвать некоторую функцию, которую предоставляет ваша библиотека, которая возвращает файл в виде строки. Если это сработает, то ваша реализация библиотеки может использовать предложение Джона. - person Frank Schwieterman; 30.07.2009
comment
@Frank, это определенно хорошее решение для среды выполнения, но трудно расширить (переопределить) файл схемы, который вы не видите. Также очень полезно иметь проверку XML-файлов во время разработки, если все файлы xsd физически доступны. - person devuxer; 30.07.2009

Я решил удалить файлы содержимого из проекта библиотеки и поместить их в новый проект библиотеки «только содержимое», который содержит только содержимое. Если кому-то нужно использовать проект библиотеки, я просто делюсь dll и папкой проекта библиотеки только для содержимого. Таким образом, отношения между проектами и файлами содержимого в папке решения остаются неизменными, и все обновляется автоматически при компиляции.

person devuxer    schedule 30.07.2009