#c# #reference
#c# #ссылка
Вопрос:
У меня есть два проекта:
- ProjectMain (библиотека классов)
- LibraryProject (библиотека классов)
ProjectMain — это библиотека классов, которая должна быть скомпилирована только как отдельная библиотека, без ссылок на библиотеки. Мне требуется статическая ссылка на класс из LibraryProject, НО я не хочу, чтобы сборка LibraryProject компилировалась вместе со сборкой ProjectMain.
Я пробовал «ссылки на ссылки» в visual Studio, но это не решение, поскольку сборка библиотеки всегда компилируется с основной сборкой.
Существуют четкие стандартные решения этой проблемы, но я сильно ограничен существующими требованиями к реализации. Может быть скомпилирована только одна DLL без каких-либо зависимых сборок, находящихся в папке выполнения, GAC, частном пути, отражении и т.д.
Точные ограничения заключаются в следующем:
- Сборка, выполняемая в изолированной среде от стороннего поставщика, поддерживает добавление только одной сборки без прямых ссылок / отражения и т.д. (это ужасно, но у меня связаны руки)
- Мы хотели бы обработать организацию кода как можно лучше, что означает следование стандартным рекомендациям, к сожалению, из-за вышеуказанного ограничения это оказывается затруднительным.
Что я хотел бы знать, так это то, есть ли способ ссылаться на класс в другом проекте без компиляции / использования сборки классов, на которые ссылаются. Возможно, метод, при котором компилятор «внедряет» класс, на который ссылается класс, во время компиляции.
Комментарии:
1. Нет — ссылка на сборку — это именно то, что нужно. Вы могли бы использовать ilmerge для последующего объединения сборок, но это не совсем одно и то же. Или вы могли бы добавить «ссылку» на интересующий вас исходный файл (а не на саму сборку). Хотя все это звучит очень хрупко — если вы, возможно, сможете устранить ограничения, которые ставят вас в такую ситуацию, чтобы вы могли больше работать с обычным потоком разработки на C #, это, вероятно, будет работать лучше в долгосрочной перспективе.
2. Если вы определяете
Some.Class.Hierarchyв сборке A и снова в сборке B, тоSome.Class.Hierarchyв каждой сборке это другой класс, несмотря на то, что он имеет одно и то же имя в одном пространстве имен.3. Хм, просто отключите копирование при сборке, и в папке выполнения не будет ссылочных DLL-файлов. Я думаю, что ваш подход нуждается в изменении. Ваш проект не должен превратиться в адскую дыру.
4. Загадочность: я пытаюсь избежать дублирования кода. ДжоНскит: Я полностью согласен, что это очень хрупко (требуется серьезный рефакторинг, но на данный момент это невозможно). Я обновлю ограничения в вопросе. eocron: это было бы прекрасно, если бы это не приводило к исключениям file not found 🙂
5. Файла, который не найден, можно избежать, если скопировать ваш фактический файл в действие после сборки в project.
Ответ №1:
Если ваша изолированная среда не позволяет загружать другие библиотеки DLL в AppDomain, загрузите ее самостоятельно, внедрив. Вы можете использовать Costura.Как правило, для этой цели его легко использовать / установить, просто ссылайтесь на него из nuget.
Конечно, встраивать это в каждый сценарий — безумие и часто сопровождается совершенно непонятными ошибками, которые часто можно устранить, только включив трассировки в regedit.
Итак, в вашем случае я бы создал два проекта:
MyDll.csproj //it is my original project, with perfect code design and etc. Lovely.
MyDll.Sandbox.csproj //this one is the same as MyDll.csproj, except it is compiled with additional Costura.Fody reference, into single dll (every reference is put inside)
Таким образом, вам просто нужно убедиться, что файлы MyDLL и MyDLL.Sandbox совпадают.