I'm looking to convert a PS1 file to an .exe file so I can roll it out to less technical users.
I believe it'll be much easier for them if all they need to do is double-click it vs explaining how to run through PowerShell.
How can I achieve this?
Use PS2EXE instead of this online tool that forces you to upload your script and creates a security breach if you have confidential information inside your script.
There is a GUI mode available; to learn more, see the GitHub repository.
You have a few paid and unpaid solutions. I agree with last answer, do not use online tools unless you are sure they are not keeping your code and you trust them.
There are two free ones that come to mind:
PS2EXE-GUI
PS1 To EXE by F2KO (Make sure t it is the local install command line interface, not the web one)
The Paid ones are:
PowerShell Studio
ISE Steroids 2.0 Enterprise
Noted: I think the free ones should be fine for most uses. I do like PowerShell Studio though.
An update to PS2EXE tool (all versions are open-source):
The original script comes from Ingo Karstein, but the development seems to have halted in 2017. You can find his blog here, and his contribution on Microsoft Technet's forums here.
Markus Scholtes has continued the script's development, adding some useful features. You can find his post on Microsoft Technet here, and github repository here.
Powershelling's answer point you to a fork of Markus' project by Stuart Dootson (here and here), which is less maintained. The obvious difference would be the "Added support for scripts that require elevation. This inserts a suitable manifest into the executable produced by the tool. that .exe files built with his version of the script require elevation".
I'd recommend checking out Markus Scholtes' version, but beware (!) (README.md on 3rd Nov 2020):
Attention: Incorrect virus detection of PS2EXE
Some stupid idiot seems to have abused PS2EXE to compile his computer virus script. As a result, a rapidly growing number of virus scanners recognize programs created with PS2EXE as malicious programs and delete them.
There is only one hope to save the PS2EXE project: Please send your (harmless) programs created with PS2EXE via the web forms from the virus scanners' vendors for reporting false positives (I've already done it with some of them, please use only the false positive page)!
If this is not successful, then I will have to quit PS2EXE as nobody can use it anymore.
Thank you for your support
Related
How do I find out what silentArg I need to use for creating a Chocolatey package?
I know that each installer will have different silentArgs but I just don't know where I can find which one has which. Also, I am using strictly .exe files (embedded too).
You'll have to work with the documentation/support provided by the software maintainer, but I'll provide some suggestions here.
Typically, MSI installers support the same silent installation parameters (many will simply work with /qn), but sometimes an installer might support additional variables or an input file you must provide.
EXE installers are a free-for-all, unfortunately. It depends on what parameters are coded into the setup program to support, even for the setup.exe installers that call another MSI. Depending on what built the EXE installer, you might be able to try some common options. The following techniques are suggestions to get you started on de-mystifying different common EXE installers:
A setup.exe that extracts and runs MSIs might be able to have the MSIs extracted and run on their own, but this is likely unsupported by the software maintainer. You will need to test this on your own per package to know if this approach will work.
Nullsoft Installers typically support a common array of options that can be used to deploy your application.
InstallShield Installers typically support the /S parameter along with an answer file, but you would still need to work with the software maintainer or read the software documentation to know what to put in the answer file.
As I've mentioned in other answers, the best thing you can do here is reach out to the vendor or software maintainer and ask for a deployment guide for that software, or at least documentation on how to silently install.
I'm looking to convert a PS1 file to an .exe file so I can roll it out to less technical users.
I believe it'll be much easier for them if all they need to do is double-click it vs explaining how to run through PowerShell.
How can I achieve this?
Use PS2EXE instead of this online tool that forces you to upload your script and creates a security breach if you have confidential information inside your script.
There is a GUI mode available; to learn more, see the GitHub repository.
You have a few paid and unpaid solutions. I agree with last answer, do not use online tools unless you are sure they are not keeping your code and you trust them.
There are two free ones that come to mind:
PS2EXE-GUI
PS1 To EXE by F2KO (Make sure t it is the local install command line interface, not the web one)
The Paid ones are:
PowerShell Studio
ISE Steroids 2.0 Enterprise
Noted: I think the free ones should be fine for most uses. I do like PowerShell Studio though.
An update to PS2EXE tool (all versions are open-source):
The original script comes from Ingo Karstein, but the development seems to have halted in 2017. You can find his blog here, and his contribution on Microsoft Technet's forums here.
Markus Scholtes has continued the script's development, adding some useful features. You can find his post on Microsoft Technet here, and github repository here.
Powershelling's answer point you to a fork of Markus' project by Stuart Dootson (here and here), which is less maintained. The obvious difference would be the "Added support for scripts that require elevation. This inserts a suitable manifest into the executable produced by the tool. that .exe files built with his version of the script require elevation".
I'd recommend checking out Markus Scholtes' version, but beware (!) (README.md on 3rd Nov 2020):
Attention: Incorrect virus detection of PS2EXE
Some stupid idiot seems to have abused PS2EXE to compile his computer virus script. As a result, a rapidly growing number of virus scanners recognize programs created with PS2EXE as malicious programs and delete them.
There is only one hope to save the PS2EXE project: Please send your (harmless) programs created with PS2EXE via the web forms from the virus scanners' vendors for reporting false positives (I've already done it with some of them, please use only the false positive page)!
If this is not successful, then I will have to quit PS2EXE as nobody can use it anymore.
Thank you for your support
Our VB6 application relies heavily on the use of scrrun.dll (Windows Scripting Host). Until a year ago we used to deploy this dll with our installer. Since the Windows Scripitng Host is supposed to be part of Windows we removed the dll from the installation package. However, now and then surface customers who have a non functional scrrun.dll on their system and we have to help them reinstall or reregister it.
So, should we put the scrrun.dll back in the installation package? Should we perform some check on installation? Or should we just live with the fact that we have to provide hands on support to some of our customers to set their systems right?
Don't try to deploy these libraries as part of a normal setup.
Microsoft Scripting Runtime must be installed through the use of a
self-extracting .exe file. For versions of Scripting Runtime mentioned
at the beginning of this article, the only way to distribute it is to
use the complete self extracting .exe file located at the following
locations...
It is possible that some users employ an older anti-malware suite, many of which tried to disable scripting. It is more likely though that some users have managed to break their Windows installation, either themselves or by using applications improperly packaged to try to include these libraries - and blindly remove them from the system on uninstall (cough, cough - Inno).
The libraries involved have been tailored code for some time. This is why the ancient .CAB file was "recalled" long ago. There is no single copy of them intended to run on any random version of Windows, and there are no redist packs for any modern version of Windows. The correct fix is a system restore or repair install.
While this can't be blamed directly on InnoSetup because it is the result of poorly authored scripts it is frustrating enough and common enough that I won't cry when its signature is added to anti-malware suites. There are just too many poorly written examples loose in the wild copy/pasted by too many people.
I spend plenty of time undoing the damage caused by uninstalls of these applications and have grown quite weary of it. Where possible I use isolated assemblies now in self-defense, which helps a lot. Windows File Protection is getting better about preventing abusive action for system files too.
But in general you are much better off avoiding any dependency on scripting tools in an application. There isn't very much that they can do as well as straight code anyway, though it may take some time to write alternative logic.
I have been tasked with looking into our deployments, and seeing where they can be streamlined. Right now we have 4 different configurations (Debug/Dev, Test, Staging, Release) and 4 *.config files. We have a task that will overwrite app/web.config with the appropriate *.config pre-build time based on the active configuration. An MSI is created, and we do a full deployment of the component on release night.
This is not entirely ideal because if we change something in a config file, or fix the spelling in a specific view we have to re-deploy the entire thing. Not to metion that the MSI will occasionally require a reboot. One other option that has been brought up is instead of creating MSIs we could create custom deployment/rollback scripts and have the ability to do incremental release.
Has anyone here tried deployments both ways? What are some of the pros/cons you have found? Is there a third way we haven't thought of?
edit: Just to clarify a few things...We don't deploy to customers. All software is deployed to our servers. (a few sites, and a lot of windows services). We never change things in production. We actually use the built in system within VS to create the MSI, so that part isn't the terrible part. To me it just doesn't make sense to redeploy an entire website if you had to change 1 view. We also have to deploy to multiple servers. Right now that is done by running the MSI on each one.
MSI pros:
Application/service/site gets installed and registered like most other Windows apps, and shows up in Add/Remove programs
Some built-in support for re-installing, upgrading
Has some built-in support for installing Windows services/IIS sites/lower-level Windows features
MSI cons:
Seems really cryptic once you get "under the hood"
Seems more difficult to customize than using a custom script
Script pros:
Easier to customize, although certain steps might require lots of/cryptic scripting (working with IIS, lower-level computer administration)
Don't have to deal with low-level weirdness of MSI
Script cons:
.bat scripting is not the most readable or writable language. (Powershell is better, but then you have to worry about whether Powershell is installed on the target machine).
Low-level operations require a lot of administrative scripting for commit/rollback behavior
No built in support for installing or rolling-back (MSI has some support built-in)
One thing I've come across that helps with MSIs is WiX (http://wix.sourceforge.net/), but even WiX seems pretty cryptic in a lot of ways. We use a combination of MSBuild and WiX to do automated builds and deployment/installs, and it works okay for us.
Overall, I'd probably lean more towards doing MSI/WiX (or other installer toolkit) deployments over scripts. MSIs are the standard way of doing installs on Windows, and once you get it working, you usually don't have to change too much. MSBuild or some other build framework (NAnt, etc.), can be useful for setting up the deployment (renaming files, doing string replacements, etc.), before putting together the final MSI package.
Running a dev company that build web apps for five years we struggled with this and tried a bunch of solutions. Here are a couple tips:
Always replace the entire web directory with your code (except if you have content generated by the web site, like a CMS). It's pretty fast to do this and incremental deployments can introduce phantom bugs if files are left around.
Have your build process (Nant, MSBuild, whatever) mod the .config files for each environment and build for what you push for. Alternately you can use registry settings so that the .config files are the same but that means a dedicated machine for each environment. May or may not be an issue.
Don't make changes in production. If you need to make changes (spelling errors on site) make those top priority to get changed in dev so that you don't overwrite them with the next push.
If you aren't using MSI's then make sure you have a rollback process. Keeping a copy of the site just before you changed it really helps when something unexplained goes sideways during a roll-out.
I don't know that these tips point to MSI or script. I think it's a matter of which you are most comfortable with. MSI's can be hard to customize, but easy to run and manage. Microsoft has lots of tools for managing roll-outs of MSI's across an organization or farm. Scripts may require custom tools and custom tooling or lots of manual work on the production end.
We ran scripts with Nant and a custom deployment harness. These days (VS2008) building deployment packages is much easier.
Your best option is to get a decent MSI builder to do the job with - i'm talking about InstallShield etc (there are a couple, so do look around). While these invariably cost, they can save you a huge amount of time/money/pain further down the track. Having said that, the pain is not totally eliminated, just reduced :)
Anything tricky you need to do can be done as a custom task within the msi - and you can even do this with the setup builder that comes with Visual Studio (if you are using VS).
I have a suggestion for your config files - include all four in the msi, and then have a public property which can be set from the command line. You can then modify that public property to install the appropriate config file (and have the default value of that property set so that the release config gets installed). That way, your customers just use the msi and get the correct config file, but your test team can get their config file by changing the value of the public property; the command line they would use to do the install is this:
msiexec /i "MyInstaller.msi" CONFIG=test
You can do install scripts quite easily, but as already mentioned you also need to script the uninstall. Using install scripts precludes you from getting Windows certification for your product should you look at getting that done. But that doesn't mean you shouldn't use install scripts, they may be the perfect fit for your needs. Alternatively you may look at using a combined script/msi approach by having your scripts run as custom actions from within the msi.
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?