I have a program that imports .reg file to registry on button click.
The program imports as well as I run it from code, but when I create an MSI installer and run it, the .reg file does not get imported.
The reason is probably the permissions of the MSI installer.
How can I set full permissions to the installer, so that it could access and import to registry?
Probably best if you make it a deferred Custom Action with Impersonate on No. (This means it will run elevated). But I have to warn you, running a .reg file is really not the way to go. Harvest the keys with Heat.exe for example.
There is a security problem that forbids a program that sits in Program Files, to import files to registry.
Therefore, I create an MSI installer that asks the user where to install the program, and then the import is done without security limits.
Related
I've been searching for a couple of hours and I'm coming up empty trying to find a solution. I'm using Dist::Zilla. I have a module that uses a simple config file in .ini format located in the module's share/ directory. When my module is installed, I'd like the install script to prompt the user for configuration options and save the user's options in the config file. Then, using File::UserConfig, it will copy the file over to the user's configuration directory where it can be loaded by the module when it runs.
Someone had suggested the Dist::Zilla::Plugin::MakeMaker::Custom module but I know next to nothing about MakeMaker and how I might write a custom one to kick off the configuration script.
I'm surprised I can't find anything that makes this easy to do. Perhaps I'm searching on the wrong keywords?
You had discussed this in IRC, and the gist is:
You cannot rely on the installation process allowing any interaction, as a large amount of installations are via cpanm which is non-interactive and hides output from Makefile.PL by default. This is because users don't like having to configure things, and as an example, a Carton deployment is frequently non-interactive by its nature. You can allow configuration via environment variables recognized by your Makefile.PL to get around this.
You can document to install using the --interactive option for cpanm in order to respond to prompts in your Makefile.PL, injected into the generated file using the [MakeMaker::Awesome] plugin.
You can include a script with the distribution that will set up the configuration so the user can do it themselves separate from the installation.
I'm installing a PowerShell module via Octopus Deploy onto a number of different servers. For testing purposes, I went with the guidance of Microsoft's documentation for installing PowerShell Modules.
This worked fine, but as the documentation stated, my changes would be visible only for the current session. That is, if I were to do the following:
$modulePath = [Environment]::GetEnvironmentVariable("PSModulePath", [EnvironmentVariableTarget]::Machine)
# More practically, this would be some logic to install only if not present
$modulePath += ";C:\CustomModules"
[Environment]::SetEnvironmentVariable("PSModulePath", $modulePath, [EnvironmentVariableTarget]::Machine)
When running this installer automatically on tentacle servers, future PowerShell sessions do not appear to see the newly installed modules.
How can I install a PowerShell module in a profile agnostic way so that every PowerShell session started can see it?
PowerShell can only "see" modules installed in one of the directories listed in $env:PSModulePath. Otherwise you'll have to import the module with its full path.
To make a new module visible to all users you basically have two options:
Install the module to the default system-wide module directory (C:\Windows\system32\WindowsPowerShell\v1.0\Modules).
Modify the system environment so that PSModulePath variable already contains your custom module directory (e.g. via a group policy preference).
The latter will only become effective for PowerShell sessions started after the modification was made, though.
This profile applies to all users and all shells.
%windir%\system32\WindowsPowerShell\v1.0\profile.ps1
After taking the steps you spelled out in your question (which I think is the general way to go), I found two ways to get the new module source recognized by Powershell:
Restart the machine. (Works every time.)
Reset the PSModulePath in each open session.
$env:PSModulePath=[Environment]::GetEnvironmentVariable("PSModulePath", "Machine")
I found this was necessary to run in both normal and elevated prompts to get this to work without restarting in each type of prompt. (See also the conversation # Topic: PSModulePath.)
When you install a package from NuGet, it can run some Powershell scripts to set things up (such as exporting commands to be used in the Package Manager console).
I'm trying (and failing) to find details of what these scripts can/can't do. Specifically - should we be worried about malicious code in these? Can they read the filesystem, send web requests, etc.?
When NuGet sets up the PowerShell host, it checks to see what the current ExecutionPolicy is. If it is not Unrestricted, RemoteSigned, or Bypass, it forces the ExcecutionPolicy to RemoteSigned for the current process (devenv.exe).
PowerShell does not see the embedded scripts init.ps1, install.ps1, etc. as being downloaded from the Internet, so there is nothing preventing a malicious script from doing anything on your machine that your account has permissions to do.
At this point, all NuGet package creators are pretty much on the "honor" system. I believe Ruby Gems have a similar situtation.
NuGet does have the ability to use private package sources, so if security is critical, I suggest you download and vet all packages, and only allow installing packages from these trusted sources.
I'll defer to someone from the NuGet team, but I'm almost certain they run under the current execution policy.
Here's a clip from my own nuget console:
PM> Get-ExecutionPolicy
RemoteSigned
If I open PowerShell as an admin and change the execution policy, nuget reports the change:
PM> Get-ExecutionPolicy
Restricted
In sum, whatever execution policy you've got on your default host also applies to the nuget console.
When you download a script from the internet, unless it is installed with a setup program where you have given it escalated permissions to install, the scripts are marked as blocked. You have to authorize (unblock) them by right clicking on the scripts and choosing the button Unblock.
I need to make installation file (.exe), but is that possible with batch script and how?
I made installation with some software (Deployment...) but I need to do that with script. I have all necessary files for my installation.
Is that possible?
Marko
Virtually every tool for building installation packages provides ability to include arbitrary sripts to the installation process. Just inspect your tool for this capability...
Here, we often include sripts in our WIX installations. Of course, user expirience is better when you building installation package nativelly, but in some cases this is acceptable practice (mostly when there is no non-tech users planned).
With a batch script, you will not be able to make a .exe (unless you call a .exe creator from within the batch script!). Why not try Inno Setup or NSIS? ISTool helps in creating Inno Setup scripts with ease and speed.
You can't make an .exe using nothing but a batch script. You can however use a batch script to create the installation specification file(s) and then run that file through an installer creator program like the ones mentioned in the other answers here. Perhaps you could be a bit clearer about what you actually need to do?
I have always wondered about this. So many application setups have a zip file that you unzip, and in it are a bunch of files, among other things an exe and an msi. What is the difference? They are often even about the same size. I am never really sure which one to execute, sometimes I do the exe and sometimes the msi, and it usually works with either one. But does one of them do anything that the other doesn't do? And if not, isn't it kind of a waste having two files that does the same thing? Especially when thinking about download size, etc...
Not sure if this should be here or on ServerFault, or maybe neither, but I figured since developers usually are the ones creating setup files, then developers might know why this is like it is =)
In the case where you have both exe and the msi the exe is just a loader for the msi. If you have an installation supporting multiple languages then the exe applies a language transform (mst) on the msi before installing.
You can consider the exe as a wrapper around the msi. The msi file may or may not be given separately. The reason why people give the msi file too is to facilitate a group policy installation (in a Windows Active Directory infrastructure) as you can only push down installations of msi files and not exes.
The setup.exe is a wrapper for the MSI, but it is not only a wrapper.
The setup.exe can rely on a setup.ini to define parameters
The setup.exe checks for the Windows Installer (a MSI cannot be installed otherwise)
The setup.exe can check for frameworks, like the .NET framework. The developer can pick one of those defined in C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages (for Visual Studio 2008). If it is lacking, it will try to download it from http://www.microsoft.com/
The setup.exe can be reconfigured with msistuff.exe
The actual installation is done in the MSI. As Prashast said, the exe is just a wrapper, but the reason for having the exe, is that an exe is allways possible to run. If the user do not have MS Installer installed on the computer, or his version of MS Installer is older than the version required by your installation, then the MSI file is not possible to run.
The exe provides automatic installation of MS Installer (including some question to the user if he/she wants to do this) before running the MSI file. In most cases, the install packages needed for Microsoft Installer is included inside the setup.exe, or sometimes it is just the prerequisites check with a link to download the installation from Microsoft.
In very basic words,
you can deliver just the .msi file and it will install. but .exe will not work without the .msi