RCL-ification of the package template.

[KevinJump]

Hi,

More than happy to explain this, but this makes the template use RCL stuff.

1. Change Package SDK from Microsoft.NET.Sdk to Microsoft.NET.Sdk.Razor
2. Add <StaticWebAssetBasePath> setting (set to App_Plugins) - this in effect tells net what the wwwroot folder will map to on the site when the package is installed ^
3. rename app_plugins to 'wwwroot'
4. remove the .targets file you don't need that anymore
5. remove the reference to the targets file from the test site - it doesn't need that anymore
6. Add placeholders for were scripts and css will be referenced in the package manifest filter**

^ in an RCL all the static files have to live in a wwwroot folder, you can't rename that in the package but the staticwebassetbasepath setting does rename it when the package is installed on a site, so your files look like they are in /app_plugins

** In v10 - Umbraco can't read package. Manifest files from RCL folders. so, you need to explicitly reference files in the manifest filter. in v11 it can read the package. Manifest files so you can put them in their instead if you want to. for cross compatibility its best to stick to the manifest filter.

[abjerner]

@KevinJump thought about this as well after seeing Lotte's tweet.

I thought for a moment that your <StaticWebAssetBasePath> was wrong, but then realized you have the assets in wwwroot/PackageStarter. I tend to have my files directly in wwwroot and then use <StaticWebAssetBasePath>App_Plugins/$(AssemblyName)</StaticWebAssetBasePath> instead.

I suppose both are right, but maybe mine is slightly simpler as there then doesn't need to be a sub folder the assets. On the other hand, with mine the destination folder has to use the assembly name 🤔

Anyways - Lotte wrote this in the README:

Why aren't you using Razor Class Libraries?
Honest answer is that I don't understand RCLs well enough yet! Get in touch if you want to enlighten me.

So to explain why RCLs are awesome, I think one of the key takeways is that when you're working locally in Visual Studio or similar, the assets from the package is added to your project virtually. Meaning that aren't physically on disk inside your project - they are instead pulled virtually from the NuGet package and made to appear as if they were inside your project. For one, this makes it easier to work in packages and version control, since you don't have to commit the assets to your repo.

It isn't until you do a publish that the files are added disk (or the generated ZIP).

ASP.NET Core and Umbraco can access the virtual files - eg. for exploring language files and backoffice icons. But like Kevin mentions, this isn't supported for package.manifest files in U10, and virtual backoffice icons are only supported from 10.3 (unless using my fix).

[KevinJump]

Yes, I too started with the package folder being "wwwroot". but I changed my mind 😊. (And this is an opinionated starter package)

I actually now think this way is simpler because it's one less thing hidden in a config file that you have to remember .

This might just be me on a journey towards just having "wwwroot/app_plugins/package-name" and nothing in the csproj file - which really might be the purest form and don't require umbraco secret knowledge or config changes 🤔

[abjerner]

I hadn't considered leaving out <StaticWebAssetBasePath> 🤔

I've build an internal tool to create new package stubs, so not really a problem for me. But for people not used to creating packages, I can see the benefit in keeping it simple 👍

[LottePitcher]

Thank you @KevinJump for the PR, and @abjerner for the explanations. Very interesting to hear the approaches you both take!
Switching it to be a Razor Class Library does seem like a good improvement so shall look to merge this ASAP (and link to this PR in the instructions in case people want to understand for themselves). #H5YR you both! 🙏

[LottePitcher]

Thank you so much for this @KevinJump !! I have finally found / made / forced ;-) the time to check this and that I understand it all before merging