Open sussexrick opened 2 weeks ago
We could create another package that just contains the core assemblies and no other output. We could then make a dependency from this package to the 'Core' package, just to get the assemblies. That would also have the desired effect. I ran into a build issue because of the client files being copied multiple times. This has been documented here: https://stackoverflow.com/questions/69919664/publish-error-found-multiple-publish-output-files-with-the-same-relative-path
We already have a core library which is the ThePensionsRegulator.Umbraco
package. It only has types in it that are purely about Umbraco though, nothing to do with GOV.UK or TPR. Nonetheless it does cover one of your scenarios, which I'll flag on the relevant PR.
For Razor class libraries, rather than create yet more packages we could look first at extending this approach which already tackled a similar issue of unwanted files in test projects.
You might want the SASS files, because they're variables and mixins intended to be used in the SASS code for your Razor class libraries, but it could be that you only get them if you have a 'Styles' folder.
I agree uSync files and App_Plugins wouldn't be needed, but that could be excluded using the approach above.
wwwroot might be trickier, because there could be a wwwroot folder without you wanting the files from the package. We could potentially look for the <AddRazorSupportForMvc>true</AddRazorSupportForMvc>
property of razor class libraries to determine whether to copy.
If you host all your code in one web project, the current setup is fine.
If you have a larger solution with code separated into multiple Visual Studio projects (typically Razor Class libraries) that are brought together into one web project at build or deploy time, then those separated projects always have GOV.UK uSync files, SASS files and wwwroot files that they don't want.
This might be resolved by:
ThePensionsRegulator.Umbraco
project; or