Я начну с того, что прошу вас спросить, почему вы пытаетесь это сделать. Поставь себя на место пользователя. Как бы вы себя чувствовали, если бы вы использовали пакет, хотели сделать небольшое изменение в том, как он работает в вашем проекте, но обнаружили, что вам пришлось создавать дополнительные файлы и использовать заранее определенные точки расширения и не иметь возможности вносить изменения, если автор пакета не предоставили определенную расширяемость, которую вы хотите использовать? Также учтите, что с HTTP 1.x время установления нового TCP / HTTP-соединения велико по сравнению с тем, чтобы сделать файл CSS или JS немного больше, поэтому конечные пользователи обычно получают лучший опыт, когда веб-приложение объединяет все в один файл, но ваш пакет пытается заставить приложение использовать несколько файлов js и css.
Если вы все еще хотите запретить разработчикам, использующим ваш пакет, изменять файлы из вашего пакета, вы не сможете использовать функции NuGet content или contentFiles. content, используется, когда на пакет ссылаются с помощью packages.config, копируются в целевой проект при установке пакета, и разработчик, безусловно, может вносить изменения в файлы в каталоге своего проекта. contentFiles используются, когда проект ссылается на пакет с PackageReference. Он не копирует файлы в каталог проекта, но файлы могут по-прежнему появляться в обозревателе решений, что позволяет пользователю легко открывать и изменять (даже если они не понимают, что это повлияет на все проекты / решения на компьютере). и изменения не будут частью контроля версий их проекта). Поскольку contentFiles работает с использованием элементов MSBuild, а MSBuild - это инструмент времени сборки, попытка распространять статические файлы (js и css) таким образом, вероятно, дает разработчикам плохой опыт, поскольку файлы не будут доступны для ASP.NET во время отладка, только после публикации.
Один из вариантов - использовать поддержку NuGet для файлов MSBuild .props и .targets. Вместо того, чтобы помещать ваши файлы js и css в каталоги NuGet content или contentFiles, вы помещаете его в другое место (возможно, в каталог build, поскольку именно там должны быть ваши файлы .props и .targets), и у вас есть инструкции MSBuild для добавления файлов в сборку, но с атрибутом Visible="false", поэтому он не отображается в обозревателе решений. Однако, поскольку файл не будет находиться на диске в каталоге проекта, он может дать разработчику плохой опыт разработки, поскольку обработчик статических файлов не сможет найти / обслужить файлы во время отладки и будет там только тогда, когда опубликовано веб-приложение, которое является той же проблемой, что и NuGet contentFiles.
Другой вариант - не распределять ресурсы в вашем пакете NuGet. Разместите их на своем веб-сайте или в CDN, и ваш HTML загрузит их оттуда. Разработчики не могут изменять файлы, которые находятся не на серверах, которыми они управляют, но если они могут изменить URL-адрес, с которого ваш HTML-файл загружает эти ресурсы, они могут просто скопировать ваши js и css в свой проект и в любом случае использовать и изменять их. Веб-сайт, на котором вы размещаете эти файлы, также представляет риск для любого, кто использует ваш пакет, поскольку, если веб-сайт веб-приложения работает, но ваши файлы css и js не могут быть загружены, то веб-приложение может не работать. Если ваш пакет полезен для внутренних корпоративных приложений, ваш пакет может не работать для них, если его политика безопасности запрещает любой доступ к внешней сети.
Еще один вариант - встроить ресурсы в вашу сборку .NET. Это означает, что вы больше не сможете использовать статический обработчик файлов ASP.NET. Если ваш пакет уже не является каким-то промежуточным программным обеспечением или обработчиком, который должен быть зарегистрирован при запуске приложения, вам нужно будет создать методы для вызова пользователей пакета, и ваш код добавит маршруты к маршрутизатору для ваших css и js файлы, и поставщик обработчик для возврата соответствующих файлов, когда маршрут совпадает. Для небольших статических файлов вы, вероятно, не заботитесь о поддержке запросов диапазона HTTP, If-Modified-Since и других HTTP-функций, которые используются браузерами, но если вы хотите сделать все «правильно», вам потребуется достаточно много работы, потому что Вы не хотите, чтобы файлы были на диске и, следовательно, редактировались.
Я уверен, что творческий человек может придумать больше способов, чтобы гарантировать, что кто-то, использующий ваш пакет, не сможет редактировать ресурсы, необходимые вашему пакету, но я снова прошу вас подумать, почему вы пытаетесь это сделать , Это помогает разработчику использовать ваш пакет, или вы просто пытаетесь управлять им? Представьте себе различные способы, которыми кто-то может захотеть использовать ваш пакет, некоторые из этих способов будут отличаться от того, как вы собираетесь использовать свой пакет. Помогает ли способ, которым вы предотвращаете редактирование ресурсов, для разработчика неоправданно трудно использовать ваш пакет так, как он хочет его использовать? Какой именно риск / вред вы пытаетесь избежать, мешая разработчику редактировать файлы js или css, распространяемые вашим пакетом? Существуют ли другие способы минимизировать риск и / или вред, кроме как предотвратить их редактирование файлов?