Open coreyasmith opened 5 years ago
Great idea. I propose the following rules:
Sound good?
Sounds great.
hey guys, the solution I'm working with right now is configured with PackageReferences and I've hit the same problem @coreyasmith described above. I'm wondering if this feature request is already being worked on as it sounds so much better than building my own custom build steps. If not, I'd be happy to take a stab at it
@ezlateva just to clarify, if the PackageReference with the content a reference of Website or one of the modules?
in my case, both actually
Interesting. Looking the NuGet.targets, the content files should get published. I wonder if it doesn't follow that path when running via a legacy (non-SDK) csproj
Yes I think that's the case @richardszalay.
In which case, solving it for Website should be simple enough as we can trigger the same target and/or Task that gets used by sdk projects.
Modules will be more difficult. Need to think it through a little more.
I'll look into it again as soon as I can. If either of you want to do the same, to figure it what's executing I recommend the MSBuild binary log viewer.
I've had a little time to investigate this further:
Files in content/
are not supported at all in the PackageReference model. Since the're used by Unicorn and pretty much every other legacy-supporting package, we should definitely support this.
Files in contentFiles/
are explicitly skipped by both Visual Studio and NuGet CLI restores when a legacy project is using PackageReference`. I propose we do not support contentFiles due to:
If/when Sitecore supports .NET Core, we can review the above.
Thoughts?
In both cases, adding support for content/
in PackageReferences on the Website project is on the lower end of effort but supporting PackageReferences of referenced modules is a bit more complex.
NB. We should definitely use the project lock file rather than the PackageReference
items, since the former includes downstream references and the latter does not.
I think that by the time all of Sitecore is running on .NET Core, we'll be using project formats that support all of the Package Reference features natively and HPP won't need to support contentFiles
.
Focusing on publishing only files in the content
folder will definitely be a big win. However, it'd still be nice to support publishing from the contentFiles
folder just because I think it promotes better development habits.
My only issue is that supporting it properly (ie. without breaking a bunch of packages), we'd have to reimplement all of the tokenisation transform support. content/
is much easier to support since it only supports a bunch of files. It does support config transforms, but we can leave for a future release.
Here's my plan for the implementation:
$(ProjectLockFile)
)ExcludeAssets
metadata value?) FilesForPackagingFromProject
Content
, and configure this target with BeforeTargets="ContentFilesProjectOutputGroup"
CollectFilesFromHelixModulesContent
to inject the new targets file into the ContentFilesProjectOutputGroup
invocation by using CustomBeforeMicrosoftCommonTargets
There will be no support for prioritising content from multiple projects that both include the same package. As with regular content files, this will generate a publish-time warning via WPP.
For Sitecore 9.1 and beyond, it's recommended to convert the
ASP.NET Web Application
projects in your solution to use the NuGet PackageReference format for reasons I won't expound here. After you convert anASP.NET Web Application
project to use the PackageReference format, config files in NuGet packages (e.g., Unicorn, Synthesis, Glass Mapper) will no longer be automatically added in to your project when those NuGet packages are installed or updated. Instead, you have to track down the configs in the%USERPROFILE%\.nuget\packages
folder and manually copy them in to your project. This makes it easy to miss critical config changes when upgrading NuGet packages.The
ASP.NET Core Web Application
project type does not suffer from this problem. When anASP.NET Core Web Application
project is published, all assets in thecontentFiles
directory of the NuGet packages that the project references are automatically published to the publish target. Due to this mechanism, it is not necessary for assets incontentFiles
to be added toASP.NET Core Web Application
project types.It would be awesome if HPP handled publishing of assets in the
content
andcontentFiles
folders of referenced NuGet packages when using the PackageReference format with theASP.NET Web Application
similar to the way they are handled forASP.NET Core Web Application
projects. This feature should not be enabled forASP.NET Web Application
projects still using thepackages.config
format. I think there should be some intelligence for packages with configs/assets duplicated in both thecontent
andcontentFiles
folders for backwards compatibility (e.g., Synthesis) so that a double publish doesn't occur, if possible.