v8 PackageReference NuGet style not supported

[zpqrtbnk]

Our NuGet packages don't support being used with the new PackageReference style - only package.config - because they rely on install.ps1 which is deprecated with PackageReference.

Need to find a replacement for install.ps1 or something...

[Shazwazza]

Closing this one - since - well the build server is running :)

[Shazwazza]

Ah... this is the ps1 file as part of the actual nuget package, ok will re-open and see what @nul800sebastiaan says

[zpqrtbnk]

yup - basically, install.ps1 is deprecated - but we still rely on it

[nul800sebastiaan]

@zpqrtbnk @Shazwazza I love the idea but there's a few things we do in install.ps1 that can't just be covered with targets files I think. Some stuff we can probably let go of by now but one thing would be a bit of a struggle: making a proper web.config transform instead of overwriting the default one when installing Umbraco. This means we'll need to create a full transform for each and every element we no have in web.Template.config. And then we also need to figure out if an upgrade won't just apply that transform again. 🙈

It might be too early, the NuGet team also don't have a good answer.. NuGet/Home#5963

[nul800sebastiaan]

Remember, we're "special" on NuGet since we don't just distribute a class library. So we're definitely abusing the system a little bit.. 🙃

[ronaldbarendse]

I've just looked into this and it could be accomplished the following way:

1. Create a PowerShell module tools\Umbraco.psm1 with Install-Umbraco and Update-Umbraco functions:

function Install-Umbraco {}
function Update-Umbraco {}

Export-ModuleMember Install-Umbraco, Update-Umbraco

2. Import the module in tools\Init.ps1 (the -Force makes sure it's re-imported on package updates):

 param($installPath, $toolsPath, $package)

 Import-Module (Join-Path $toolsPath Umbraco.psm1) -Force

3. Execute the Install-Umbraco or Update-Umbraco function in tools\Install.ps1, so the actions are still automatically executed for packages.config projects

For PackageReference projects, you would only require executing the correct function in the PM console after installing/updating Umbraco. The update function could even automate the NuGet package upgrade itself (Update-Package UmbracoCms), so upgrading would become a single command 🎉

[soreng]

For PackageReference projects, you would only require executing the correct function in the PM console after installing/updating Umbraco. The update function could even automate the NuGet package upgrade itself (Update-Package UmbracoCms), so upgrading would become a single command 🎉

@ronaldbarendse thats the thing that keeps PackageReference from being implemented. You should not have to rely on manual steps, since they won't be performed.

[ronaldbarendse]

@soreng It would certainly be better to remove any manual steps, I agree, but lets do it one step at a time 😉

The Umbraco projects already use the PackageReference style, so only the consuming projects can't use it (yet). This is because the install.ps1 isn't executed, but also the config transforms aren't run:

Umbraco-CMS/build/NuSpecs/UmbracoCms.nuspec

Lines 52 to 64 in 0dea835

	<!-- tools -->
	<!-- beware! install.ps1 not supported by PackageReference -->
	<file src="tools\install.ps1" target="tools\install.ps1" />
	<file src="tools\Readme.txt" target="tools\Readme.txt" />
	<file src="tools\ReadmeUpgrade.txt" target="tools\ReadmeUpgrade.txt" />
	<!-- config transforms -->
	<!-- beware! config transforms not supported by PackageReference -->
	<file src="tools\Web.config.install.xdt" target="Content\Web.config.install.xdt" />
	<file src="tools\serilog.config.install.xdt" target="Content\config\serilog.config.install.xdt" />
	<file src="tools\ClientDependency.config.install.xdt" target="Content\config\ClientDependency.config.install.xdt" />
	<file src="tools\umbracoSettings.config.install.xdt" target="Content\config\umbracoSettings.config.install.xdt" />
	<file src="tools\Views.Web.config.install.xdt" target="Views\Web.config.install.xdt" /> <!-- FIXME: Content\ !! and then... transform?! -->

We can show a readme.txt with instructions in the meantime (using the above commands). I'm not sure if adding this file to the NuGet package root only shows it on PackageReference install; if that's the case, we can even be more specific with the instructions... The readme files need some updating either way: #6700.

[soreng]

Hi @ronaldbarendse

I know the drill - I went through it this summer on some internal packages.

I don’t think it’s worth doing, if it introduces a manual step.

[ronaldbarendse]

Well, it's only a manual step if you're using PackageReference 😉 The packages.config style will still run the install.ps1 script and config transforms.

Most of the install.ps1 commands and config transforms can be moved to build targets or even Umbraco migrations, so it's possible without manual steps!

[bielu]

Hello Guys,
Actually I notice one thing if anyone is using Rider as editor instead of Visual Studio package will fail to install as the rider doesn't have secretly implement back-compatibility to older NuGet and using newest NuGet version. And install.ps1 will be not runned on Rider :)
I think all commands should be moved to build targets as soon as possible :).
The only issue which I am seeing is copying config files - > they will be readonly as NuGet doesn't support anymore not read/write files :)

[soreng]

@bielu in short: Rider is not supported by umbraco :-)

The Challenge is that some of the dependencies may also use powershell scripts in their install

[bielu]

@soreng yeah and force people to use Vs great idea ;)
Yeah, about dependencies - they couldn't as Umbraco is built-in PackageReference format at least v8 :)
I slowly looking into PowerShell script and only 2 things what is doing is copy files and change web.config but still nuget don't support Read/Write files :)

[umbrabot]

Hiya @zpqrtbnk,

Just wanted to let you know that we noticed that this issue got a bit stale and might not be relevant any more.

We will close this issue for now but we're happy to open it up again if you think it's still relevant (for example: it's a feature request that's not yet implemented, or it's a bug that's not yet been fixed).

To open it this issue up again, you can write @umbrabot still relevant in a new comment as the first line. It would be super helpful for us if on the next line you could let us know why you think it's still relevant.

For example:

@umbrabot still relevant
This bug can still be reproduced in version 8.9.0

This will reopen the issue in the next few hours.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[ronaldbarendse]

@umbrabot still relevant
This is still a feature Umbraco 8 can greatly benefit from, as it would allow upgrading by simply changing the version in the PackageReference of a website project.

[nul800sebastiaan]

Closing this as this is how v9 works and we have no plans to overhaul v8 to support this.