PSResourceGet installs nuget.org packages like they were PowerShell packages

[o-l-a-v]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.

Steps to reproduce

As you can add any nuget v2 and v3 repository to PSResourceGet, maybe it would be smart to validate whether packages are ment for PowerShell before installing?

Take NuGet.Versioning for instance, it installs to $env:PSModulePath as a PowerShell module, but can't be imported as a module.

Steps to reproduce:

# Assets
$Repo = [ordered]@{
    'Name' = [string] 'NuGetv3'
    'Uri'  = [string] 'https://api.nuget.org/v3/index.json'
}


# Register NuGet as a resource repository
Register-PSResourceRepository -Name $Repo.'Name' -Priority 60 -ApiVersion 'V3' -Uri $Repo.'Uri'


# Find latest version of NuGet.Versioning from nuget.org
Find-PSResource -Repository $Repo.'Name' -Name 'NuGet.Versioning' | Format-List


# Install it
Install-PSResource -Repository $Repo.'Name' -TrustRepository -Scope 'CurrentUser' -Name 'NuGet.Versioning'


# Find it locally
Get-InstalledPSResource -Name 'NuGet.Versioning' | Format-List


# Try to import it - Does not work
Import-Module -Name 'NuGet.Versioning'


# One can add it as type though
## Find info for latest installed version
$NuGetVersioning = Get-InstalledPSResource -Name 'NuGet.Versioning' |
    Sort-Object -Property 'Version' -Descending |
    Select-Object -First 1

## Add type
Add-Type -Path (
    [System.IO.Path]::Combine(
        $NuGetVersioning.'InstalledLocation',
        'NuGet.Versioning',
        $NuGetVersioning.'Version'.ToString(),
        'lib',
        'netstandard2.0',
        'NuGet.Versioning.dll'
    )
)

## Test it
[NuGet.Versioning.NuGetVersion]'1.2.3'

Related comments:

• Install-Package support #487 (comment)
• Install-Package support #487 (comment)

Expected behavior

Validate whether a package is made for PowerShell. Tags? Content when decompressed?

Alternatively, do something else with non-PowerShell NuGet packages? Add to different path or something.

Actual behavior

Installs non-PowerShell resources as if they were modules.

Error details

No response

Environment data

• Windows 11 23H2
• Microsoft.PowerShell.PSResourceGet v1.0.3
• PowerShell v7.4.1 x64

Visuals

No response

[ThomasNieto]

Here are the two tags used in PSRG to denote if a NuGet package is a module or script.

• PSModule
• PSScript

The logic should be updated check packages on a repo and fail if either of those tags aren't found.

[o-l-a-v]

This seems to be by design: If neither a script or a module => Install as module.

PSResourceGet/src/code/InstallHelper.cs

Lines 1060 to 1067 in abfbf42

	else
	{
	// This package is not a PowerShell package (eg a resource from the NuGet Gallery).
	installPath = _pathsToInstallPkg.Find(path => path.EndsWith("Modules", StringComparison.InvariantCultureIgnoreCase));
	_cmdletPassedIn.WriteVerbose($"This resource is not a PowerShell package and will be installed to the modules path: {installPath}.");
	isModule = true;
	}

I don't understand that design decision. 🤔

[SydneyhSmith]

We should be installing nupkgs to the nugetcache
https://github.com/nuget/docs.microsoft.com-nuget/blob/main/docs/consume-packages/managing-the-global-packages-and-cache-folders.md#managing-the-global-packages-cache-and-temp-folders

[o-l-a-v]

I don't know how much sense it makes to install NuGet packages handled by PSResourceGet into the NuGet cache.

• Dotnet / NuGet might install NuGet packages with target frameworks that PowerShell versions supported by PSResourceGet (all the way down to Windows PowerShell) does not support.
• PSResourceGet will add an XML when Install-PSResource, which other NuGet package managers don't add or use.
• PSResourceGet Get-InstalledPSResource, Update-PSResource etc. will not detect NuGet packages installed by other NuGet package managers, as this XML will not be present.
• You might already have a given package and version installed outside PSResourceGet (with that XML file missing), what should PSResourceGet do then?

I think it'd be better to add NuGet packages 1) handled by PSResourceGet 2) with intention of being consumed by PowerShell directly to a directory side by side with \Modules and \Scripts: \NuGet?. And PowerShell Add-Type should be updated to search and resolve versions and compatibility directly when referencing the name of a NuGet package only.

• 2018-04-25 "Make using NuGet packages installed with Install-Package easier to use - make Add-Type support NuGet packages": Make using NuGet packages installed with Install-Package easier to use - make Add-Type support NuGet packages PowerShell#6724
• 2018-07-10 "Import-Module should support nupkg files": Import-Module should support nupkg files PowerShell#7259

Maybe PSResourceGet could use the NuGet cache to fetch packages from?

---

Other questions:

How to handle different package types (dependency vs. tool vs. template)?

• Maybe PSResourceGet only should offer to install package type "Dependency" (not "DotnetTool", "MSBuildSDK" and "Template")?
  • https://learn.microsoft.com/en-us/nuget/create-packages/set-package-type
• The NuGet Gallery API does not return package type, so how should PSResourceGet detect it?
• https://github.com/NuGet/Home/wiki/Surfacing-PackageType-as-part-of-NuGet-search-protocol
  • 2016-08-19 "Search by PackageType API Proposal": Search by PackageType API Proposal NuGet/NuGet.Services.Metadata#87
  • 2019-09-22 "Support packageTypes property in catalog": Support packageTypes property in catalog NuGet/NuGetGallery#7574
  • 2019-10-01 "Surface PackageType query parameter in the NuGet.org search API": Surface PackageType query parameter in the NuGet.org search API NuGet/NuGetGallery#7594
  • 2019-12-10 "Feature ask client side -- Surface PackageType query parameter in the NuGet.org search API": Feature ask client side -- Surface PackageType query parameter in the NuGet.org search API NuGet/Home#8915
  • Thoughts on how:
    • Use NuGet search API, example: https://azuresearch-usnc.nuget.org/query?q=packageid:nuget.versioning&packageType=dependency&take=1&prerelease=false
    • Download package, extract content, read the <package_name>.nuspec file and look for <packageTypes>?

Example dotnet-outdated-tool.nuspec

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
  <metadata>
    <id>dotnet-outdated-tool</id>
    <version>4.6.4</version>
    <authors>dotnet-outdated Team &amp; Contributors</authors>
    <license type="expression">MIT</license>
    <licenseUrl>https://licenses.nuget.org/MIT</licenseUrl>
    <projectUrl>https://github.com/dotnet-outdated/dotnet-outdated</projectUrl>
    <description>A .NET Core global tool to update project dependencies.</description>
    <releaseNotes>See https://github.com/dotnet-outdated/dotnet-outdated/blob/master/CHANGELOG.md# for release notes.</releaseNotes>
    <copyright>Copyright (c) Jerrie Pelser</copyright>
    <packageTypes>
      <packageType name="DotnetTool" />
    </packageTypes>
    <repository type="git" url="https://github.com/dotnet-outdated/dotnet-outdated.git" commit="3bad9cacfd8752a5d0a98fad47493c26bd8f5a88" />
  </metadata>
</package>

Example NuGet.Versioning.nuspec (it's a dependency, does not have "PackageTypes" inside it)

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
  <metadata>
    <id>NuGet.Versioning</id>
    <version>6.12.1</version>
    <authors>Microsoft</authors>
    <requireLicenseAcceptance>true</requireLicenseAcceptance>
    <license type="expression">Apache-2.0</license>
    <licenseUrl>https://licenses.nuget.org/Apache-2.0</licenseUrl>
    <icon>icon.png</icon>
    <readme>README.md</readme>
    <projectUrl>https://aka.ms/nugetprj</projectUrl>
    <description>NuGet's implementation of Semantic Versioning.</description>
    <copyright>© Microsoft Corporation. All rights reserved.</copyright>
    <tags>semver semantic versioning</tags>
    <serviceable>true</serviceable>
    <repository type="git" url="https://github.com/NuGet/NuGet.Client" commit="aa7eb9987d28e7169cfabfa484f2fdd22d2b91d2" />
    <dependencies>
      <group targetFramework=".NETFramework4.7.2" />
      <group targetFramework=".NETStandard2.0" />
    </dependencies>
  </metadata>
</package>

How to handle target framework?

• Newest supported target framework given the PowerShell version (and underlying dotnet framework) running PSResourceGet?
  • What if user installed a NuGet dependency with PowerShell 7.5, but expects the dependency to work with Windows PowerShell 5.1 too?
• Choose newest target framework that supports Windows PowerShell on Windows, but newer target framework for Mac and Linux?
• Just always go netstandard2.0, else fail to install it?