The following link provides two options to install PWSH on windows, MSI, and Zip:
https://github.com/PowerShell/PowerShell/releases/tag/v7.1.2
How to properly install the zip package? It includes all the required files, but it needs to be added to PATH and do some windows registry updates, to my understanding.
Is there a list of steps or instructions that explains how to deploy PowerShell core properly on windows using zip package?
Related
I am trying to install software using command prompt using below command
start /wait /d "C:\abc" C:\Users\abc.exe /silent /norestart
I want to install software in c:\abc folder but it is installing in the software default directory. Is there any way to install it into the custom directory using the start command or are there any other alternatives to install the software on the target directory.
SHORT VERSION:
This may be the most "accessible" and "quick" explanation for your particular case: http://unattended.sourceforge.net/installers.php
If you are dealing with an MSI file, you should use the admin install feature to extract all the installation files first and then customize your install by setting public properties or utilizing a transform to configure the install. Details here: How to make better use of MSI files.
See the link towards the bottom to find a list of different parameters you can use for different types of setup.exe files.
DETAILS:
A setup.exe file can be "anything". It can be an old, legacy Installshield or Wise installer, a modern Windows Installer file (MSI) embedded in a setup.exe launcher, an Inno setup file (non MSI), an embedded Advanced Installer MSI setup, a compressed and self-extracting zip file, a unique and custom made installer (proprietary), or any number of other technologies, the list goes on and on and on - it is impossible to tell what tool or technology was used to create your setup.exe from the information supplied.
Just for reference, let's link to installsite.org's information on different setup technologies and available tools. Most likely your setup.exe is made using one of these tools:
Non-MSI installer tools: http://www.installsite.org/pages/en/tt_nonmsi.htm
Windows installer tools: http://www.installsite.org/pages/en/msi/authoring.htm
This may also be of help: Wix - How to run/install application without UI.
The point is, naturally, that every, different technology has its own way to enable silent installation and to customize installation parameters. So the first step for you is to determine what this file really is. Right click the file, select properties and check the details tab for any clues. Or just run the setup.exe interactively and see what the window title is (top window title bar). It will generally indicate what tool was used to create the setup.exe.
Rather than rewriting it all, and since it is a stackoverflow link (unlikely to be removed), I will just link to a similar answer on how to install setup.exe files silently: How can I use powershell to run through an installer?. See the "some links" section for links to documentation for various tools.
In order to make install scripts and understanding existing ones, I would like to know what happens behind the scenes of the typical:
choco install notepadplusplus
I found the following here:
Installation
Chocolatey uses Nuget.Core to retrieve the package from the source.
Choco determines if it self-contained or has automation scripts - PowerShell scripts (*.ps1 files), and soon to be open to Scriptcs files in the 0.9.10.x timeframe (I know, right?!).
Choco takes a registry snapshot for later comparison.
If there are automation scripts, choco will run those. They can contain whatever you need to do, if they are PowerShell you have the full power of Posh (PowerShell), but you should try to ensure they are compatible with Posh v2+.
Choco compares the snapshot and determines uninstaller information and saves that to a .registry file.
Choco snapshots the folder based on all files that are currently in the package directory.
Choco looks for executable files in the package folder and generates shims into the $env:ChocolateyInstall\bin folder so those items are available on the path. Those could have been embedded into the package or brought down from somewhere (internet, ftp, file folder share, etc) and placed there.
That given,
How can I get the .nupkg package URL? In general it seems like this:
https://chocolatey.org/api/v2/package/package-name
Which is the .nupkg package download directory?
Where is the content of the .nupkg package extracted by default? This is important since chocolateyInstall.ps1 sometime uses Split-Path -Parent $MyInvocation.MyCommand.Definition.
"Scriptcs files in the 0.9.10.x timeframe" is rather cryptic. Can you give some references?
Is Posh v2+ simply short for Powershell or is a specific technology?
There are several executable files in $env:ChocolateyInstall\lib without a link in $env:ChocolateyInstall\bin. For example, the mpv.exe of the mpv player is not linked.
Yes, that download URL seems correct. The download directory is always into the Chocolatey installation folder, then lib\packageName, and this is where contents are extracted to.
Right now, installation scripts are only written in PowerShell. This comment is referring to the ability to write in installation scripts in C#, using the ScriptCS run time. Currently, this isn't yet supported.
Yes, this is just a short way of referring to PowerShell.
In the case of the mpv package, you will notice that there is an mpv.exe.ignore file. The presence of this file in the package prevents a shim being created.
I have completed a project on VisualStudio and I have built the .exe file of this project. I wanted to make an installer that will include this .exe file as well as the postgreSQL and perl executable installers because my VB application relies on them to work. So I assume that if I want it to work properly on every windows-based PC I have to include those as well.
Is there a way I can include those 3 .exe(s) in a single setup (let's say .MSI file) and if yes what are the steps required to do so?
Thanks in advance!
Regards,
George.
An MSI shouldn't ever run an EXE installer. For that scenario you need what's called a bootstrapper / chainer. The two are similar except that boostrapper is things that must be installed before your MSI ( like Windows Installer itself ) and chainer are things that get installed along with your MSI.
InstallShield has two features for this. Setup / Feature Prerequisites and Suite Installers. Both can be used to chain together any number of EXE and MSI installers.
For more information see:
Using InstallShield 12 to Install .NET Framework 3.0
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.
PowerCLI with .NET has some dependencies on dll's that you get only when you install PowerCLI on each machine you want to run.
I have a console app with command line arguments, which when deployed using the usual method doesn't work because of the unmet dependencies...these assemblies are part of the GAC.
Clickonce deployment proved to be useless..it didnt recognize my arguments although I passed them as query params.
Finally, I installed VMware PowerCLI on this remote machine. Then ran the .exe and it worked. Is there a way to avoid installing PowerCLI and be able to include all the dependencies with my exe during deployment?
Depending on where exactly you want to deploy your console application, you may be out of luck. According to this page and the most relevant forum post I could find, the PowerCLI assemblies are not redistributable. Your best bet if you want to distribute this application outside your company is to use the Web Services SDK - a huge pain since you've already developed the app.
Assuming your application is for internal use only and you just want to deploy it on its destination server, you can do the following to reference the assemblies locally:
On the development machine, copy whichever PowerCLI .dlls you reference from the GAC (in %WINDIR%\assembly) to your solutions local directory.
Change your references in the project to point to the local versions of the .dlls.
Open the 'Properties' view for each of the references, and make sure 'Copy Local' is set to True.
Compile and deploy your console application (and it's coresident .dlls) to the target machine, it should reference them in the local directory and run without external dependencies.
Hope that helps!
You could also automate PowerCLI installation with a silent installation one-line Powershell script, if the problem is hiding the installation from the users.
Invoke-Expression ("cmd /c '$powerCLIexeFilePath'/S /VADDLOCAL=ALL /V/qn")