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
Related
I'm working on a PS Binary module and I developed it using PS 7.1. I tried importing the dll into PS 5.1 and I got the following error:
ipmo : Could not load file or assembly 'System.Management.Automation, Version=6.0.4.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
My .csproj file is as follows:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Library</OutputType>
<TargetFramework>netstandard2.0</TargetFramework>
<AssemblyName>assemblyName</AssemblyName>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="PowerShellStandard.Library" Version="5.1.0-preview-06">
<PrivateAssets>All</PrivateAssets>
</PackageReference>
<PackageReference Include="System.Management.Automation" Version="6.0.4" />
</ItemGroup>
</Project>
This project is created by using the PowerShell Module Template via dotnet cli: dotnet new psmodule.
You did it backwards. If you want a module to be compatible with both Windows PowerShell and PowerShell Core, you need to develop it against PowerShell 5.1, then use the Portability Analyzer to determine how portable your module is.
System.Management.Automation houses most, if not all, of the PowerShell specific constructs. If you build against PowerShell Core, PowerShell 5.1 is NOT going to have the same version of that assembly loaded into memory. Hence, it cannot find the assembly version it is looking for.
Here is some more information you may find useful on the subject.
Edit:
If your module is not compatible both ways, you can develop it for PowerShell 5.1 anyways and use the WindowsCompatibility module from PowerShell Core which should implicitly make use of constructs only available in Windows PowerShell. There are some caveats, the module must not use "live" objects (like CIM, remote connections, etc.) and the module will effectively remain "Windows-only" since you can't run PowerShell 5.1 on Linux or MacOS.
I just started writing scripts in PowerShell.
The desired script is supposed to create a local GroupPolicyObject (GPO) which will be specified afterwards. Research showed that it could be done with the New-GPO command within the GroupPolicy module for PowerShell. I tried to install the mentioned module but unfortunately nothing I found worked. May I ask for help?
I am using Windows 7 and Powershell 5.1.14409.1005
Error I receive when running example from Microsoft page (New-GPO -Name TestGPO -Comment "This is a test GPO."):
It is actually extremely simple, but the organization of the modules and features has changed many times in the past ten years, Microsoft Docs don't document the up-to-date way anywhere and all articles found online are very old.
Anyway, to install the Powershell Module called GroupPolicy, you need to install the Windows Feature called GPMC (Group Policy Management Console) which includes the mentioned module.
Install-WindowsFeature GPMC
This feature was once a subfeature of the RSAT feature, which is the cause of confusion.
Step 1. Install RSAT from Microsoft site:
https://www.microsoft.com/en-in/download/details.aspx?id=7887
Step 2. Enable Group Policy from Windows Features.
Following link describes the steps in details:
https://www.powershellmagazine.com/2012/05/14/managing-group-policy-with-powershell
Have you installed the RSAT (Remote Server Administration Tools) Group Policy component?
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.
We have a PowerShell snapin that requires version 3.0 of PowerShell to function. So we used the following file element in a WiX (3.8) file:
<File Id="MySnapin.dll"
Name="MySnapin.dll"
Assembly=".net"
KeyPath="yes"
Vital="no"
Checksum="yes"
DiskId="1"
Source="$(var.FilesPath)\Bin\MySnapin.dll"
AssemblyApplication="MySnapin.dll">
<ps:SnapIn Id="MySnapin"
Description="This is a PowerShell snap-in"
Vendor="My Company Inc."
RequiredPowerShellVersion="3.0">
<ps:FormatsFile FileId="MySnapin.format.ps1xml" />
</ps:SnapIn>
</File>
However, when installing this the snapin cannot be found in powershell (Get-PSSnapIn -Registered). When examining the registry it turns out that the snapin has been registered in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\PowerShell\3\PowerShellSnapIns\MySnapin. But when running installutil.exe on the DLL, the registration ends up in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\PowerShell\1\PowerShellSnapIns\MySnapin, and powershell finds it properly. Is this a bug in WiX Toolset, or am I doing something wrong here?
Where are the registrations really supposed to go?
Yea this sounds like a bug, so you might want to report it to the WiX maintainers, but there is better way.
The recommended way to add cmdlets and functions is through PowerShell Modules. Snap-ins are the older way to extend PowerShell and while still supported are not recommended. If you do not need to support adding your cmdlets to older versions of PowerShell use a module.
Modules are somewhat easier to deploy than snap-ins. Basically you can put them anywhere, however if you want users to be able to load them by name they need to exist on the PSModulePath environment variable. Your installer would add your files and update the PSModulePath variable to include a Modules folder from your install folder. Then users will simply be able to call Import-Module MyModule to load them. Also, see the documentation on PSModulePath.
This blog post contains a detailed walkthrough of how to write a WiX installer to do this. It also has instructions on how to check that the required PowerShell version is installed. Basically, you are going to check the under both those registry keys you mentioned for the PowerShellEngine\PowerShellVersion value.
I was trying to use Nuget as a software deployment system (repository, versioning and delivery) - idea from Octopus. Previously I was packaging ASP.NET sites into a self-extracting RAR archives with a .CMD startup scripts embeded. Now I'm trying to use Nuget creating puckages during automated build. The issue is that the package installation scripts (tools\Install.ps1 or tools\Init.ps1) do not execute if the package is being installed using command line:
nuget.exe install <package_id> -OutputDirectory <install_folder> -source <local_repo>
Same scripts are able to execute when package installed from Visual Studio Package Manager or Console.
I do not see why this shouldn't be possible given omnipresence of PowerShell.
Am I missing something or this is behaviour by design? Will appreciate you help.
Yes, we did consider MSDeploy but we already have install scripts that do the same thing and give more control and we need some strong package management and repository for build artifacts (something that Java folks do with Maven).
As of today, the powershell scripts are not invoked from doing installations from command line.
One reason for this is that, in general, most of the install/init actions are tied to dte and the visual studio project and doesn't add much value to be able to run it from outside VS.
We have a backlog item for enabling support for exe based scripts too in addition to powershell.