How do I tell DSC that a resource/module from OneGet/Package Management needs installing, first?
Do I just use a Script Resource and configure PowerShellGet and then manually call Install-Module?
you could use powershell remoting and install the modules beforehand.
or
you could use a script resource
or
use this module from github
powershellmodule
if you have a pull server you can use the github module centrally otherwise when using push you will have to copy the github module referenced above to all target systems but then it is a one time process at least for installing modules from the gallery.
You can use the packagemanagement provider resource available here in order to install the required packages https://github.com/PowerShell/PackageManagementProviderResource
Related
Is there a way to install a module by using a url to a github gist? I think it used to be possible with PsGet, but now PowerShellGet supersedes it and doesn't have this option. I saw there's GistProvider, but that just downloads the files to a folder, so they are not really part of the module system.
I am using Azure DevOps to deploy PowerShell modules to a server. This release task deploys the modules to the directory C:\Windows\System32\WindowsPowerShell\v1.0\Modules\. I am able to use the modules once they are deployed to this folder successfully.
If I modify one of the modules and re-release it the file in C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ gets updated, however the old version of the module is still used when running from a batch file using pwsh.
I discovered that the module file also exists in the following paths:
C:\Program Files\PowerShell\Modules\
C:\Program Files\PowerShell\6\Modules\
When deploying the new version using Azure DevOps the old version in the above two directories are not updated. Manually updating the module in those locations fixes the problem.
Why is the module file being copied into those two additional paths?
Should those copies be overwritten when a new version of the module is deployed?
What is the correct way of deploying a module in this scenario?
Powershell uses different paths to load modules. Use $env:PSModulePath -split ";" to know which are the paths being used.
The difference between each path is user scope and usage scope (e.g. made for custom modules or windows official modules).
Now, by default, PS looks for the latest version of each module across all the paths. So maybe the old version is being run because at the time you re-deploy. You are not updating the module version in the Module Manifest, so if PS see they are the "same" version it gets the last one loaded on the PSModulePath.
Take a look at this awesome post for more details: Everything you wanted to know about PowerShell's Module Path
Now to your questions.
Why is the module file being copied into those two additional paths?
This could be a server configuration or the script that you are using to deploy.
Should those copies be overwritten when a new version of the module is deployed?
Not necessarily, if the versions are maintained correctly. On the post shared says how to check the versions of each module.
I want to know about how can we get to know what parameters we can pass during a package installation using chocolatey like can we pass username,password and port during postgres installation from chocolatey repository.
So when you create a package for something like postgresql, you can use both install arguments[1] and package parameters[2]. Note that the package parameters has you add those params to the description[3].
If you are talking about existing packages from the community package repository, then you can pass install arguments directly to the installer if it is an installer package. You need to know what native switches the underlying installer supports. Those are transparent to packaging as long as they are calling choco functions. If the package has package parameters, you will find those listed in the description on the package page[3].
The nature of software installers in the Windows ecosystem is such that each piece of software is a special snowflake. Installer packages (packages that manage to the native software installers and Programs and Features), you can only go so much further than the limitations of whatever installer was used.
If an existing package you find could support some certain package params, reach out to the maintainers and file a ticket on their package source code (likely on GitHub). If you have the ability, provide a pull request with the fixes as well. That will go quite far in getting to what you need. HTH
[1] https://chocolatey.org/docs/commands-reference, see install, upgrade, and uninstall.
[2] https://chocolatey.org/docs/how-to-parse-package-parameters-argument
[3] https://chocolatey.org/docs/how-to-parse-package-parameters-argument#step-2---add-package-parameters-to-the-description
Just open up chocolatey "repo" and find the package. It is usually describing how to install it properly.
Alternatively you can examine the powershell installer file that comes with the package. From the code you can derive what you can pass to the choco install
Working with the OneGet chocolatey provider, if I run the a command like the following...
Install-Package fooo
directly on a box the chocolatey package is cached in <%LocalAppData%>\Nuget\Cache. If I rerun the same command the package is read out of this cache.
However if I wrap up this command in a DSC resource and run it on a box I can not find where the package is cached. It is definitely cached somewhere. anyone know where? You would have thought it would be under the user that DSC was running as, although I am not sure what user it does run as and have also gone through all the user folders with no joy.
DSC does indeed run as the local system account, thanks briantist.
It is cached here: C:\Windows\system32\config\systemprofile\AppData\Local\NuGet
found with the help of the following link
https://serverfault.com/questions/9325/where-can-i-find-data-stored-by-a-windows-service-running-as-local-system-accou
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.