Самый простой способ упаковать файлы содержимого в пакет .nuget - PullRequest
Новая
       33

Самый простой способ упаковать файлы содержимого в пакет .nuget

2 голосов
/ 23 октября 2019

Итак, я настроил что-то вроде следующего:

Source.sln имеет три проекта A.csproj, B.csproj и utils.csproj. И A, и B используют utils.csproj, но я преобразовал utils.csproj в пакет nuget, поэтому теперь A и B используют пакет utils nuget вместо ссылки на проект.

Следующее, что я делаю, это создаю пакет nuget для обоих ботов A и B. Итак, теперь у меня есть три пакета nuget

1.A.Nuget (использует utils.nuget) 2.B.nuget(использует utils.nuget) 3. Utils.nuget

Теперь у меня есть еще один consumer.csproj, который использует все три в качестве ссылок на nuget.

Проблема здесь в том, что и A.csproj, и B.csproj имели файлы inputA.json и inputB.json, которые требуются во время выполнения. Они не меняются вообще, поэтому лучше, чтобы они были упакованы с пакетом nuget

Мой вопрос заключается в том, что является самым чистым способом их укрытия? Я подумал о нескольких вариантах, но не удовлетворен ни одним из них:

  1. упакуйте их в папку utils.nuget / content, указав его в файле .csproj. Но проблема здесь в том, что код, читающий их из nuget, должен ссылаться на эти файлы из ../contents/inputA.json, чего нет в среде разработки. Они просто находятся в папке A.csproj / и на них можно ссылаться как «input.json». Таким образом, тот же код, который работает в Visual studio (ссылается на этот файл как input.json), прервется, когда consumer.csproj ссылается на A.nuget и utils.nuget

  2. Потребитель поставляет все эти файлы. Это может быть вариант, но я хочу избежать его, если это возможно.

  3. Каким-то образом найти способ скопировать эти файлы в папку / lib файла utils.nuget вместо / contents. В настоящее время я пытаюсь добиться этого с помощью файла .nuspec. но не уверен, что это самое чистое решение

Могу ли я сделать что-то лучше в этой ситуации?

1 Ответ

1 голос
/ 27 октября 2019

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

Если некоторые из ваших компьюмеров пакетов будутиногда хочется изменить содержимое, тогда я думаю, что создание вашего пакета с расширяемым API было бы лучше, чем наличие файла конфигурации. Я не знаю, работали ли вы вообще с ASP.NET Core, но я думаю, что их конфигурация великолепна. Вся конфигурация - это код, использующий обратные вызовы. Например: 

app.UseWhateverMiddleware(options => {
  // options contains default values, my app can change the values I care about here
})

Это решает очень много проблем. Если ваш пакет перезаписывает файлы содержимого проекта, то потребители вашего пакета потеряют свои настройки. Если ваш пакет не перезаписывает файлы содержимого, то у вас нет хорошего способа обновить значения по умолчанию или добавить новые параметры в проекты, уже использующие ваш пакет. В зависимости от того, кто ваши клиенты, они могут не быть довольны вынужденной настройкой вашей библиотеки, хотя файл должен быть развернут вместе с их приложением. В частности, для веб-приложений некоторым людям нравятся файлы конфигурации, некоторые хранят конфигурацию в базе данных или переменные среды, все конфигурации в одном файле, разные файлы конфигурации для разных библиотек или разные файлы конфигурации для разных областей / функций приложения.

Используя шаблон опций ядра ASP.NET , он позволяет проектам настраиваться так, как хочет проект, а не так, как хочет пакет.

...