I have a repository with a lot of solutions.
Sometimes I need to update one package to a newer version.
It is way to slow opening each solution and updating via visual studio.
What is the best way to update a single package to a newer version for many solutions in the same git repository all at once?
What I did is just find replace the version numbers needed to be updated with the help of sublime. This solution is risky but the only one I have found.
I updated the references in the solution files and the version
numbers in the package.config files.
For example: EntityFramework version 4.3.0 to version 6.0.0
Update the solution files
Find with regex: <Reference Include="EntityFramework((?s).*?)</Reference>
Where: *.csproj
Replace with: <Reference Include=\"EntityFramework, Version=6.0.0.0\">\n\t\t<HintPath>$\(SolutionDir\)\\packages\\EntityFramework.6.0.0\\lib\\net45\\EntityFramework.dll<\/HintPath>\n\t<\/Reference>
Update the package files
Find with regex: <package id="EntityFramework" version="((?s).*?)" targetFramework="net45" />
Where: packages.config
Replace with: <package id="EntityFramework" version="6.0.0" targetFramework="net45" />
NuGet comes with different frontends, one being a command line application (Download) that also allows to update package references. Thomas Ardal provided a nice PowerShell script that can be used to update packages across multiple solutions:
param(
[Parameter(Mandatory=$true)]
[string]$packageId
)
Get-ChildItem *.sln -recurse | %{.\\nuget.exe restore $_.fullname}
Get-ChildItem packages.config -Recurse `
| Where-Object {$_ | Select-String -Pattern $packageId} `
| %{.\\nuget.exe update -Id $packageId $_.FullName}
Please note that this method does not support to control the dependency behavior and will update dependencies to their highest available version.
You can't do that with NuGet since it relies on Visual Studio as you can see here.
However, you have an alternative to NuGet, called Paket, which works from the command line.
Working with Paket, you can either manage the packages of your whole repository globally (or per directory) or create a batch to update the package for each solution.
Managing the packages globally, or per directory, means you must have the same version of the packages across all solutions, or across all solutions below the directory paket is managing.
Related
In Visual Studio, I can right-click the solution, and follow the Manage NuGet Packages for Solution... option to view referenced packages that have updates.
What I'd like to be able to do is to obtain this same information, but from the CLI - either by running a NuGet CLI command or a NuGet PowerShell command. Just a list of packages with updates available, with the current and latest versions would be sufficient.
I've looked through the documentation for both the NuGet CLI and NuGet Powershell, but can't see any candidate commands.
Is this possible? How does the Visual Studio UI pull this information?
I guess Visual Studio is doing this by running two PowerShell commands. First Get-Package, that will list all packages in your project/solution, and then Get-Package -Updates that will list only packages with available updates. After that you can compare two lists, and you will have both current version and latest version. Link to documentation: Get-Package (Package Manager Console in Visual Studio)
I think you could use this command within the package manager console of your solution to get the output you need:
Get-Package -Updates | Select-Object Id, Version, #{Name="CurrentVersion"; Expression ={(Get-Package -filter $_.Id)[0].Versions.Version.ToString()}}
Should get only those packages needing updated and the current version installed.
Sometimes in my PowerShell scripts, I need access to a specific DLL, using Add-Type -AssemblyName. However, the DLLs I need aren't always on the machine or in the GAC. For instance, I might want a quick script that uses Dapper to query a database. In these cases, I have been literally copying the DLLs along with the ps1 file. I was wondering if this was common/a good idea and whether there was an existing extension that would load up NuGet packages, store then in a global or local folder and call Add-Type -AssemblyName automatically.
It'd be a lot like using npm or pip in Node.js or Python, respectively.
Update
I did some research and there's nothing built-in to older versions of PowerShell. I made some progress trying to write one from scratch using the nuget.exe
&"$(Get-Location)/nuget.exe" install $packageName -Version $version -OutputDirectory "$(Get-Location)/packages" -NoCache -NoInteractive
This will download a given package/version under a "packages" folder in the current folder, along with any of its dependencies. However, it looks like it downloads every framework version, with no obvious way to tell which one to use for your given environment.
Otherwise, you could just loop through the results and call Add-Type:
Get-ChildItem .\packages\ -Recurse -Filter "*.dll" | % {
try
{
Add-Type -Path $_.FullName
}
catch [System.Exception]
{
}
}
I tried using the restore command using a project.json file to see if I could control the framework version with no luck. This is just too hacky for me.
I'll check out #crownedjitter's suggestion of using PowerShell 5.
Update
Using #crownedjitter's suggestion, I was able to eventually register the PackageManagement module with NuGet (see comments below). With the following command, I was able to reproduce what the Nuget.exe command above was doing:
Install-Package Dapper -Destination packages
Obviously, this is a lot shorter. Problem is it has the same limitation; it brings down every framework version of a package. If this includes .NET core, it brings down a good deal of the .NET core framework with it! There doesn't appear to be a way to specify a target framework (a.k.a, .NET 4.5.1 or below).
I am wondering if there is a way to determine which NuGet package folder(s) to load the DLLs from based on PowerShell's current $PSVersionTable.CLRVersion field.
crownedjitter's helpful answer is a good starting point, and Travis himself has provided additional pointers in comments, but let me try to summarize as of Windows PowerShell v5.1 / PowerShell [Core] 7.1:
Update: The original answer, reprinted in the section after this one, contains some useful general pointers, plus a link to the feature suggestion on GitHub to integrate NuGet packages with Add-Type, but the Install-Package based method it shows ultimately falls short, because it doesn't account for dependencies of a package, as
BACON points out:
The one (not-so-trivial) step that's missing is loading any dependencies that may have been installed, too. Because the Dependencies property doesn't contain enough information, it seems that would involve extracting the .nuspec file from the .nupkg file in the Source directory, reading the <group> for the appropriate framework, and loading those packages' assemblies.
The following approach remedies this, but note that it first requires download and installation of the .NET SDK with its dotnet CLI:
Create a folder for an auxiliary project to which the package will be added and change to it; e.g.:
Set-Location (New-Item -Type Directory assemblies)
In that folder, create a dummy library project:
For PowerShell (Core), to target the latest installed .NET (Core) SDK by default:
dotnet new classlib
For Windows PowerShell or to target a .NET 5+ OS-specific framework:
To target the highest .NET Standard that is still .NET Framework-compatible:
dotnet new classlib -f netstandard2.0
To target a specific .NET Framework version only or a .NET 5+ OS-specific framework:
You'll have to manually edit the generated .csproj and update the <TargetFramework> element; e.g., to target the latest and last version, 4.8, use <TargetFramework>net48</TargetFramework>; to target .NET 6.0 with Windows-specific APIs, use <TargetFramework>net6.0-windows</TargetFramework>
Targeting .NET Framework may require downloading a developer pack first.
Add a reference to the package of interest; e.g.:
dotnet add package Dapper
To reference a specific version, add -v <version>
Publish the dummy project, which copies all required DLLs, including dependencies, into the publish folder:
dotnet publish -c Release
Important: The exact case (lower- vs. uppercase) of the -c argument determines the exact case of the corresponding output folder; to make sure your code works on case-sensitive filesystems too, notably on Linux, make sure that you use the exact same case in the file paths referring to the output binaries.
Test that the package's main assembly can be loaded; e.g.:
Add-Type -Path bin/Release/*/publish/Dapper.dll
Verify that the package's types can be used; e.g.: [Dapper.DbString]::new()
Now you can either reference the main DLL directly from the auxiliary project, or you can copy all bin/Release/*/publish/*.dll files to a folder of your choice and reference it from there.
The following sample script shows a script that downloads the Terminal.Gui package on demand, and creates the auxiliary project in an assemblies subfolder relative to the script's location.
$packageName = 'Terminal.Gui'
$assembly = "$packageName.dll"
# Set to #() to get the latest stable version.
$packageVersionArgs = '-v', '1.0.0-pre.4'
$projectFolder = 'assemblies' # Subfolder for the aux. project
$assemblyPath = "$PSScriptRoot/$projectFolder/bin/Release/*/publish/$assembly"
$literalAssemblyPath = Convert-Path -ErrorAction Ignore $assemblyPath
if ($literalAssemblyPath) {
Write-Verbose -vb "Package '$packageName' already installed. Loading main assembly: $literalAssemblyPath"
Add-Type -ErrorAction Stop -LiteralPath $literalAssemblyPath
}
else {
Write-Verbose -vb "Installing package '$packageName'..."
$null = Get-Command -ErrorAction Stop -CommandType Application dotnet
Push-Location (New-Item -ErrorAction Stop -Type Directory "$PSScriptRoot/$projectFolder")
$null = dotnet new classlib
$null = dotnet add package $packageName #packageVersionArgs
$null = dotnet publish -c Release
Pop-Location
Write-Verbose -vb "Loading main assembly: $assemblyPath"
Add-Type -ErrorAction Stop -Path $assemblyPath
}
# Instantiate a type from the package to verify that it was loaded.
"Listing property names of a [Terminal.Gui.Button] instance:"
[Terminal.Gui.Button]::new().psobject.Properties.Name
Caveat:
Some packages have dependencies on native libraries, which dotnet publish places in the runtimes subfolder tree of the publish folder, in platform-specific subfolders such as runtimes\win-x64\native.
In Windows PowerShell, Add-Type -LiteralPath (and its underlying .NET API method, [System.Reflection.Assembly]::LoadFrom()) does find the platform-appropriate native library, but, curiously, it does not work as of PowerShell (Core) 7.2.0-preview.9 - at least as observed with version 5.0.9 of the Microsoft.Data.Sqlite NuGet package.
The workaround is to find the platform-appropriate native library in the runtimes subfolder tree and copy it directly into the publish folder. The install-on-demand Add-NuGetType helper function, discussed in this answer, automates this process.
ORIGINAL ANSWER
As stated, PowerShell v5+ - including PowerShell Core - comes with the PackageManagement module that is a meta package manager providing access to multiple repositories via providers; on-demand installation of this module is may be possible in v3 and v4 (this download is labeled "March 2016 Preview", and it is the most recent I could find).
Find-PackageProvider lists all available providers.
Get-PackageProvider lists installed ones.
It is the nuget provider that enables installation of Nuget packages via Install-Package, and there are two potential hurdles:
The nuget provider may not be installed.
It may be installed with an incorrect API URL that prevents Find-Package from returning results.
Test if the nuget provider is installed:
# If this fails, the provider isn't installed
Get-PackageProvider nuget
If it is installed: Verify that the package source URI is correct:
Open an elevated PowerShell session.
Run Get-PackageSource:
If you find a Nugettest source, remove it:
Unregister-PackageSource Nugettest
If the Location column for source nuget.org shows https://api.nuget.org/v3/index.json (or something other than ttps://www.nuget.org/api/v2), update it:
Set-PackageSource nuget.org -NewLocation https://www.nuget.org/api/v2 -Trusted
Caveat: This may break the ability to browse NuGet packages in Visual Studio: see https://github.com/PowerShell/PowerShellGet/issues/107
If it is not installed: Install the provider from scratch:
Open an elevated PowerShell session.
Run the following commands:
Install-PackageProvider nuget
Register-PackageSource -ProviderName nuget -name nuget.org -Location https://www.nuget.org/api/v2 -Trusted
After completing the above steps, discovery (e.g., Find-Package Dapper) and installation (e.g., Install-Package Dapper) of NuGet packages should succeed.
By default, Install-Package installs in the AllUsers scope, which requires elevation, but you can opt into installing in the context of the current user only with -Scope CurrentUser.
Using a downloaded NuGet package:
Note: See this suggestion on GitHub for making the use of NuGet packages in PowerShell easier by extending Add-Type, which would obviate the need for all subsequent steps, which are still needed as of PowerShell Core 6.2.0.
As demonstrated in the question, you need to manually load the package's assemblies into your PowerShell session with Add-Type -Path <assembly-file-path>; however, in the era of .NET Core, packages may have DLLs for different .NET environments, so you cannot always blindly load all *.dll files in the package folder:
In order to discover the file-system location of a downloaded package, query the .Source property of the relevant object returned by Get-Package:
(Get-Package Dapper).Source
To see the full paths of all DLLs inside the package, run the following:
(Get-ChildItem -Filter *.dll -Recurse (Split-Path (Get-Package Dapper).Source)).FullName
Looking at the full DLL paths should tell you which DLL(s) are the right ones to load for your environment; using the example of the Dapper package:
C:\Program Files\PackageManagement\NuGet\Packages\Dapper.1.50.4\lib\net451\Dapper.dll
C:\Program Files\PackageManagement\NuGet\Packages\Dapper.1.50.4\lib\netstandard1.3\Dapper.dll
C:\Program Files\PackageManagement\NuGet\Packages\Dapper.1.50.4\lib\netstandard2.0\Dapper.dll
Given that .NET Standard DLLs run on all .NET platforms, however, you can programmatically look for the (latest) such DLLs and load them:
(Get-Item (Join-Path (Split-Path (Get-Package Dapper).Source) lib/netstandard*) |
Sort-Object { [version] ($_.Name -replace '^netstandard') })[-1] |
Get-ChildItem -Filter *.dll -Recurse |
ForEach-Object { Add-Type -LiteralPath $_.FullName }
The above looks for the highest available .NET Standard version DLLs; if you want to target a specific version, the command becomes easier; e.g., for .NET Standard 2.0:
Get-ChildItem -Recurse -Filter *.dll -LiteralPath (Join-Path (Split-Path (Get-Package Dapper).Source) lib/netstandard2.0) |
ForEach-Object { Add-Type -LiteralPath $_.FullName }
Are you using Powershell 5? Because if you are, it has a package management module:
It appears to be open source: https://github.com/OneGet
Sometimes in my PowerShell scripts, I need access to a specific DLL, using Add-Type -AssemblyName. However, the DLLs I need aren't always on the machine or in the GAC. For instance, I might want a quick script that uses Dapper to query a database. In these cases, I have been literally copying the DLLs along with the ps1 file. I was wondering if this was common/a good idea and whether there was an existing extension that would load up NuGet packages, store then in a global or local folder and call Add-Type -AssemblyName automatically.
It'd be a lot like using npm or pip in Node.js or Python, respectively.
Update
I did some research and there's nothing built-in to older versions of PowerShell. I made some progress trying to write one from scratch using the nuget.exe
&"$(Get-Location)/nuget.exe" install $packageName -Version $version -OutputDirectory "$(Get-Location)/packages" -NoCache -NoInteractive
This will download a given package/version under a "packages" folder in the current folder, along with any of its dependencies. However, it looks like it downloads every framework version, with no obvious way to tell which one to use for your given environment.
Otherwise, you could just loop through the results and call Add-Type:
Get-ChildItem .\packages\ -Recurse -Filter "*.dll" | % {
try
{
Add-Type -Path $_.FullName
}
catch [System.Exception]
{
}
}
I tried using the restore command using a project.json file to see if I could control the framework version with no luck. This is just too hacky for me.
I'll check out #crownedjitter's suggestion of using PowerShell 5.
Update
Using #crownedjitter's suggestion, I was able to eventually register the PackageManagement module with NuGet (see comments below). With the following command, I was able to reproduce what the Nuget.exe command above was doing:
Install-Package Dapper -Destination packages
Obviously, this is a lot shorter. Problem is it has the same limitation; it brings down every framework version of a package. If this includes .NET core, it brings down a good deal of the .NET core framework with it! There doesn't appear to be a way to specify a target framework (a.k.a, .NET 4.5.1 or below).
I am wondering if there is a way to determine which NuGet package folder(s) to load the DLLs from based on PowerShell's current $PSVersionTable.CLRVersion field.
crownedjitter's helpful answer is a good starting point, and Travis himself has provided additional pointers in comments, but let me try to summarize as of Windows PowerShell v5.1 / PowerShell (Core) 7.3.2:
Update: The original answer, reprinted in the section after this one, contains some useful general pointers, plus a link to the feature suggestion on GitHub to integrate NuGet packages with Add-Type, but the Install-Package based method it shows ultimately falls short, because it doesn't account for dependencies of a package, as
BACON points out:
The one (not-so-trivial) step that's missing is loading any dependencies that may have been installed, too. Because the Dependencies property doesn't contain enough information, it seems that would involve extracting the .nuspec file from the .nupkg file in the Source directory, reading the <group> for the appropriate framework, and loading those packages' assemblies.
The following approach remedies this, but note that it first requires download and installation of the .NET SDK with its dotnet CLI:
Create a folder for an auxiliary project to which the package will be added and change to it; e.g.:
Set-Location (New-Item -Type Directory assemblies)
In that folder, create a dummy library project:
For PowerShell (Core), to target the latest installed .NET (Core) SDK by default:
dotnet new classlib
For Windows PowerShell or to target a .NET 5+ OS-specific framework:
To target the highest .NET Standard that is still .NET Framework-compatible:
dotnet new classlib -f netstandard2.0
To target a specific .NET Framework version only or a .NET 5+ OS-specific framework:
You'll have to manually edit the generated .csproj and update the <TargetFramework> element; e.g., to target the latest and last version, 4.8, use <TargetFramework>net48</TargetFramework>; to target .NET 6.0 with Windows-specific APIs, use <TargetFramework>net6.0-windows</TargetFramework>
Targeting .NET Framework may require downloading a developer pack first.
Add a reference to the package of interest; e.g.:
dotnet add package Dapper
To reference a specific version, add -v <version>
Publish the dummy project, which copies all required DLLs, including dependencies, into the publish folder:
dotnet publish -c Release
Important: The exact case (lower- vs. uppercase) of the -c argument determines the exact case of the corresponding output folder; to make sure your code works on case-sensitive filesystems too, notably on Linux, make sure that you use the exact same case in the file paths referring to the output binaries.
Test that the package's main assembly can be loaded; e.g.:
Add-Type -Path bin/Release/*/publish/Dapper.dll
Verify that the package's types can be used; e.g.: [Dapper.DbString]::new()
Now you can either reference the main DLL directly from the auxiliary project, or you can copy all bin/Release/*/publish/*.dll files to a folder of your choice and reference it from there.
The following sample script shows a script that downloads the Terminal.Gui package on demand, and creates the auxiliary project in an assemblies subfolder relative to the script's location.
$packageName = 'Terminal.Gui'
$assembly = "$packageName.dll"
# Set to #() to get the latest stable version.
$packageVersionArgs = '-v', '1.0.0-pre.4'
$projectFolder = 'assemblies' # Subfolder for the aux. project
$assemblyPath = "$PSScriptRoot/$projectFolder/bin/Release/*/publish/$assembly"
$literalAssemblyPath = Convert-Path -ErrorAction Ignore $assemblyPath
if ($literalAssemblyPath) {
Write-Verbose -vb "Package '$packageName' already installed. Loading main assembly: $literalAssemblyPath"
Add-Type -ErrorAction Stop -LiteralPath $literalAssemblyPath
}
else {
Write-Verbose -vb "Installing package '$packageName'..."
$null = Get-Command -ErrorAction Stop -CommandType Application dotnet
Push-Location (New-Item -ErrorAction Stop -Type Directory "$PSScriptRoot/$projectFolder")
$null = dotnet new classlib
$null = dotnet add package $packageName #packageVersionArgs
$null = dotnet publish -c Release
Pop-Location
Write-Verbose -vb "Loading main assembly: $assemblyPath"
Add-Type -ErrorAction Stop -Path $assemblyPath
}
# Instantiate a type from the package to verify that it was loaded.
"Listing property names of a [Terminal.Gui.Button] instance:"
[Terminal.Gui.Button]::new().psobject.Properties.Name
Caveat:
Some packages have dependencies on native libraries, which dotnet publish places in the runtimes subfolder tree of the publish folder, in platform-specific subfolders such as runtimes\win-x64\native.
In Windows PowerShell, Add-Type -LiteralPath (and its underlying .NET API method, [System.Reflection.Assembly]::LoadFrom()) does find the platform-appropriate native library, but, curiously, it does not work as of PowerShell (Core) 7.2.0-preview.9 - at least as observed with version 5.0.9 of the Microsoft.Data.Sqlite NuGet package.
The workaround is to find the platform-appropriate native library in the runtimes subfolder tree and copy it directly into the publish folder. The install-on-demand Add-NuGetType helper function, discussed in this answer, automates this process.
ORIGINAL ANSWER
As stated, PowerShell v5+ - including PowerShell Core - comes with the PackageManagement module that is a meta package manager providing access to multiple repositories via providers; on-demand installation of this module is may be possible in v3 and v4 (this download is labeled "March 2016 Preview", and it is the most recent I could find).
Find-PackageProvider lists all available providers.
Get-PackageProvider lists installed ones.
It is the nuget provider that enables installation of Nuget packages via Install-Package, and there are two potential hurdles:
The nuget provider may not be installed.
It may be installed with an incorrect API URL that prevents Find-Package from returning results.
Test if the nuget provider is installed:
# If this fails, the provider isn't installed
Get-PackageProvider nuget
If it is installed: Verify that the package source URI is correct:
Open an elevated PowerShell session.
Run Get-PackageSource:
If you find a Nugettest source, remove it:
Unregister-PackageSource Nugettest
If the Location column for source nuget.org shows https://api.nuget.org/v3/index.json (or something other than ttps://www.nuget.org/api/v2), update it:
Set-PackageSource nuget.org -NewLocation https://www.nuget.org/api/v2 -Trusted
Caveat: This may break the ability to browse NuGet packages in Visual Studio: see https://github.com/PowerShell/PowerShellGet/issues/107
If it is not installed: Install the provider from scratch:
Open an elevated PowerShell session.
Run the following commands:
Install-PackageProvider nuget
Register-PackageSource -ProviderName nuget -name nuget.org -Location https://www.nuget.org/api/v2 -Trusted
After completing the above steps, discovery (e.g., Find-Package Dapper) and installation (e.g., Install-Package Dapper) of NuGet packages should succeed.
By default, Install-Package installs in the AllUsers scope, which requires elevation, but you can opt into installing in the context of the current user only with -Scope CurrentUser.
Using a downloaded NuGet package:
Note: See GitHub issue #6724, which suggests making the use of NuGet packages in PowerShell easier by extending Add-Type, which would obviate the need for all subsequent steps, which are still needed as of PowerShell Core 7.3.2.
As demonstrated in the question, you need to manually load the package's assemblies into your PowerShell session with Add-Type -Path <assembly-file-path>; however, in the era of .NET Core, packages may have DLLs for different .NET environments, so you cannot always blindly load all *.dll files in the package folder:
In order to discover the file-system location of a downloaded package, query the .Source property of the relevant object returned by Get-Package:
(Get-Package Dapper).Source
To see the full paths of all DLLs inside the package, run the following:
(Get-ChildItem -Filter *.dll -Recurse (Split-Path (Get-Package Dapper).Source)).FullName
Looking at the full DLL paths should tell you which DLL(s) are the right ones to load for your environment; using the example of the Dapper package:
C:\Program Files\PackageManagement\NuGet\Packages\Dapper.1.50.4\lib\net451\Dapper.dll
C:\Program Files\PackageManagement\NuGet\Packages\Dapper.1.50.4\lib\netstandard1.3\Dapper.dll
C:\Program Files\PackageManagement\NuGet\Packages\Dapper.1.50.4\lib\netstandard2.0\Dapper.dll
Given that .NET Standard DLLs run on all .NET platforms, however, you can programmatically look for the (latest) such DLLs and load them:
(Get-Item (Join-Path (Split-Path (Get-Package Dapper).Source) lib/netstandard*) |
Sort-Object { [version] ($_.Name -replace '^netstandard') })[-1] |
Get-ChildItem -Filter *.dll -Recurse |
ForEach-Object { Add-Type -LiteralPath $_.FullName }
The above looks for the highest available .NET Standard version DLLs; if you want to target a specific version, the command becomes easier; e.g., for .NET Standard 2.0:
Get-ChildItem -Recurse -Filter *.dll -LiteralPath (Join-Path (Split-Path (Get-Package Dapper).Source) lib/netstandard2.0) |
ForEach-Object { Add-Type -LiteralPath $_.FullName }
Are you using Powershell 5? Because if you are, it has a package management module:
It appears to be open source: https://github.com/OneGet
So I've been trying out OneGet for a while and wanted to create packages. The biggest problem I've run into is that OneGet does not seem to actually execute the uninstall script provided into the package.
This is the .nuspec file and the script files I've been testing with:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<id>notepadplusplus</id>
<version>6.8.5</version>
<title>Notepad++</title>
<authors>Notepad ppl</authors>
<owners>King Kong</owners>
<projectUrl>https://notepad-plus-plus.org/</projectUrl>
<iconUrl>http://i1-win.softpedia-static.com/screenshots/icon-60/Notepad-plus-plus.png</iconUrl>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Notepad++ is a free (as in "free speech" and also as in "free beer") source code editor and Notepad replacement that supports several languages. Running in the MS Windows environment, its use is governed by GPL License.</description>
<summary>Notepad++</summary>
<tags>notepad notepad++ texteditor text editor</tags>
</metadata>
<files>
<file src="tools\chocolateyInstall.ps1" target="tools\chocolateyInstall.ps1" />
<file src="tools\chocolateyUninstall.ps1" target="tools\chocolateyUninstall.ps1" />
</files>
</package>
chocolateyinstall.ps1:
Install-ChocolateyPackage 'notepadplusplus' 'exe' '/S' 'https://notepad-plus-plus.org/repository/6.x/6.8.5/npp.6.8.5.Installer.exe'
chocolateyuninstall.ps1:
Get-WmiObject -Class Win32_Product | Select-Object -Property Name > C:\foo.txt
I use the uninstall script just to test if the script is even run but it's not. When I do the same to the install script I can clearly see that it hit the script and actually create the text file.
So my question is does the oneget module in Windows 10 not use the script files at all? Since Doing an Uninstall-package seems to execute the uninstall file if the name provided is the exact same as in the registry. For example doing the command Uninstall-package notepad++ will uninstall notepad++ even though it was installed with the name notepadplusplus.
The current OneGet Chocolatey provider is a non-fully featured prototype from March 2014 (yes, 2014), written by Microsoft. The official provider is not done. Look for that to be finished sometime in 2017.
The Chocolatey team uses a prioritization schedule that allows for quickly reprioritizing when demands shift, so it is hard to provide better estimated dates on this. If anyone is interested in picking this up to finish, please comment below.
We'll make an official announcement in the mailing list and in the newsletter when it is ready.
Until it is announced, I would expect it to be an early preview and pretty much consider everything about it broken (including security fixes that have been added since 2014). It's based currently on Chocolatey from nearly two years ago and not even fully functional to the features available then.
HTH
This should return a list of all versions right?
Nuget.org, my package source, hosts a lot of versions for this package.
Here they are.
Can someone tell me what I am missing?
The -AllVersions parameter is part of the "Remote" parameter set which includes your parameters so it looks like the parameters are correct.
Looking at the request that is returned from https://nuget.org/api/v2/Search() it does not look like what you are trying to do is supported.
The raw data sent back does not include multiple versions for each NuGet package so, even though there is code in NuGet which does not collapse the versions down to the latest when -AllVersions is specified as it displays the results, you only get the one version for each NuGet package.
The -AllVersions parameter seems to only work when the -Updates parameter is used. This uses a different query https://nuget.org/api/v2/GetUpdates() which returns multiple package versions. So you can only see all NuGet package versions for the updated packages in your project.
Get-Package -AllVersions -Updates -Filter jquery