honey the codewitch Ответов: 1

Вы также держите "фреймворк" кода C# вокруг, чтобы включать биты при кодировании других проектов?


Итак, у меня есть эта кодовая база под названием Grimoire, которая содержит большинство вещей, которые я нашел достойными сделать дважды.

Парсеры, генераторы состояний FA, сетевые вещи, даже обработка MIDI.

Затем, когда я хочу использовать его, я включаю соответствующий код.

Когда это началось, это были просто фрагменты почти.

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

Посмотрите мою "пробную" часть и скажите мне, есть ли лучший способ управлять сложными исходными зависимостями.

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

Что я уже пробовал:

Чтобы исправить эту проблему и сохранить исходный код в удобном для включения формате, я построил способ генерации Объединенных и "уменьшенных" "кирпичей" исходного кода, которые затем "символически связываю" в свой проект из основного репозитория. Таким образом, мне не нужно добавлять полдюжины файлов для некоторой функциональности, и мне не нужно отслеживать все эти перекрестные зависимости в моей голове. Все они находятся в одном "кирпиче", созданном с помощью пользовательского инструмента VS из набора входных файлов. Это делает его таким, что мне нужно ссылаться только на один файл в моем целевом проекте, и это включает в себя весь мой необходимый библиотечный код.


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

________________________ примерная часть "кодового кирпича" ________________

// Зависимости для котла
#define COLLECTIONUTILITY_CS
#определение STRINGUTILITY_CS
#определение STRINGUTILITY_PARSING_CS
#define PARSECONTEXTEXPRESSIONS_REGEX_CS
#определение STRINGUTILITY_RANGES_CS
#определение STRINGUTILITY_PARSING_CSHARP_CS
#определение STRINGUTILITY_PARSING_T4_CS
#определение FAUTILITY_CS
#define FAUTILITY_CODEGENERATOR_CS
использование системы;
использование системы.Коллекции.Общий;
использование системы.ИО;
использование System.Text;
#если !GRIMOIRELIB
Гримуар пространства имен{с помощью системы;используя систему.Коллекции;использование системы.Коллекции.Generic;использование IEnumerable
=Система.Коллекции.IEnumerable;использование IEnumerator=System.Коллекции.IEnumerator;
#если ГРИМУАРЛИБ
общественный
#еще
внутренний
#endif
статический частичный класс CollectionUtility{
CollectionAdapter области #
внутреннюю герметичную CollectionAdapter класса:интерфейс ICollection{внутренний CollectionAdapter(интерфейс IEnumerable внутренний){_inner
=внутри;}только для чтения интерфейс IEnumerable _inner;общественная int Граф{get{возвращение графа(_inner);}}общественная bool IsSynchronized
{get{return false;}}object ICollection.SyncRoot{get{return this;}}public void CopyTo(Array array,int
index){CollectionUtility.Метод CopyTo(_inner,массив,индекс);}общественная интерфейс IEnumerator метод getenumerator(){возвращение _inner.Метод getenumerator();
}}внутреннюю герметичную CollectionAdapter класс и л;т>:интерфейс ICollection&ЛТ;п&ГТ;{внутренний CollectionAdapter(интерфейс IEnumerable&ЛТ;п&ГТ;
внутренний){_inner=внутренний;}только для чтения интерфейс IEnumerable&ЛТ;п&ГТ;_inner;общественная int Граф{get{возвращение графа(_inner);}}общественная
bool IsReadOnly{get{return true;}}public void CopyTo(T[]array,int index){CollectionUtility.Метод CopyTo(_inner,
массив,индекс);}public IEnumerator<t>GetEnumerator(){return _inner.Метод getenumerator();}недействительными интерфейс ICollection в<Т>.Добавить(Т
пункт){бросить новое исключение notsupportedexception("коллекция" только чтение".");}логический интерфейс ICollection в<Т>.Удалить(Т
item){throw new NotSupportedException("коллекция доступна только для чтения.");} void ICollection<t>.Четкий(){
throw new NotSupportedException("коллекция доступна только для чтения.");}public bool Contains(T item){return
Содержит<t>(_inner,item);}IEnumerator IEnumerable.Метод getenumerator(){возвращение _inner.Метод getenumerator();}}
#endregion CollectionAdapter

1 Ответов

Рейтинг:
9

RickZeeland

Вы также можете использовать такую утилиту, как ILmerge или даже лучше Фоди Костура чтобы объединить все dll - файлы в один exe-файл. Однако это не сработает для сложных проектов.
Гитхаб - Фоды/Costura: размещения ссылок на ресурсы[^]
GitHub - dotnet/ILMerge: ILMerge-это статический компоновщик для сборок .NET.[^]
Слияние.Сетевые сборки с использованием ILMerge[^]


honey the codewitch

Спасибо. В последний раз, когда я пытался использовать ILMerge для этого, он сломался для некоторых сборок и никогда не мог понять, почему. Это было много лет назад, когда он все еще был размещен в MSR или где-то еще и экспериментально. Я забыл об этом, пока ты не упомянул об этом.

Я обязательно вернусь к этому еще раз.

Я хочу избежать встраивания ссылок в качестве ресурсов (что-то я уже рассматривал) из - за дополнительных проблем, которые это вызывает с точки зрения ограничений безопасности .NET и требований к нефиксированному дисковому пространству-обычно это не имеет значения, но когда это происходит, это плохо ломается.

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

Ваш ответ относительно Ильмерге потенциально является хорошим решением, но мне нужно изучить его.