So I have a compliled matlab code, 'Example.exe'...I want to create an installer package that does the following:
My exe file will reside on a network drive.
My installer will first ask the user for the installation path.
It will then copy the exe (along with some other supporting files) in the given path....IF the folder already exists, it will ask the user for overwrite confirmation.
After the copying is done, my installer will ask the user if they want to install the MCR and accordingly install it(or not).
After everything is done, a shortcut to the exe is created on the desktop.
My question is, is there some installer package generator that can do all this ?? I understand matlab can create an installer package, but I want my file to be copied from the network drive. I also don't have Visual Studio so, can't create an msi.
There's a simple way to do this, you'll need a software called IExpress, It can create a self-extracting executable (.EXE) or a compressed Cabinet (.CAB) file using the provided interface (IExpress Wizard). Its included in all versions of windows (I think..). To run the IExpress Wizard, go to your local drive then: Windows\System32, Search for "iexpress" then run the program.
then...
Follow these steps:
1. Run iexpress.exe
2. Create a new 'Self Extraction Directive' file
3. Extract files only
4. Specify the title, promt user options, license, etc
5. Start adding files to your package
7. Specify other options (window, message)
8. Enter the path where you want your package to be.
Then you're almost done, create your package (might take a few mins), distribute it, upload it and all.
For more details visit http://www.makeuseof.com/tag/how-to-make-an-exe-installation-file/
There is no simple way to do that. But if you tightly tied to Windows platform, you definitely can learn Windows Installer technology. It's NOT related to Visual Studio!
Just download WiX toolset (it is free and Open Source!) and learn MSDN docs about Windows Installer.
But it is complex way, remember. You can spent months learning how to make great Windows installers.
Ofcourse, you can use Inno Setup or NSIS, but I don't recommend that, because them re-engineer installer technology instead of native Windows Installer's.
If you want, I can learn you by Skype or something like. :-)
Or (isn't great offer?) I can write the installer for you and send you all code and describe which for what is.
Use iExpress! Available from win xoxo and over (xp)
With windows 8 pro you can make a package with your voice! Only with win 8 or 8.1 pro.
Related
I want to distribute a setup in a self extracting executable form. I want to pack versions for 32 bit and 64 windows. So I have a program which first checks the version of Windows OS running and then launches the correct program. SO I have a directory structure like this
DetermineOS.exe
Win32\Win32Setup.exe
Win32\supporting win32 files
Win64\Win64Setup.exe
Win64\Supporting win64 files
I want to pack them in a bundle called something like install.exe. When the user clicks install.exe it will extract this directory structure to the temp location and launch DetermineOS.exe which will then launch the correct setup.exe
Will NSIS be the easiest way to go? Would this be a compicated NSIS script? Thanks.
It sounds to me that the only thing you want to get out of it is to extract to the %TEMP% location and run a certain exe file. If that's the case, I'm not sure NSIS is the easiest way to go. Most of the archives support self-extraction and running a command on extraction-complete. For instance, WinRAR and 7z have such modules. And my gut feeling is this option seems to be easier than NSIS.
Different bootstrappers also support this scenario. For instance, Visual Studio bootstrapper or dotNetInstaller. I've recently blogged about this simplest case with dotNetInstaller.
Hope this helps.
You could put the different images (executables) in the "root" image and extract and run the appropriate image as needed (many Sysinternals tools do this - e.g. the "root" application embedds the drivers for 32 and 64 bit).
I'm looking for a solution to run multiple setup files (.exe and .msi) in sequence without any user input. The idea is to have everyone in my workgroup to have the same development tools (eclipse, python, cygwin, etc) by running one installer. Besides creating a batch script, is there a software out there that could create such a wrapper of installers?
Thanks!
From my knowledge there aren't any tools which create this type of wrappers, or if there are they are not MSI-based. This is because Windows Installer is very restrictive when it comes to running multiple installers simultaneously.
You can try using a setup authoring tool which supports package prerequisites. This way you can create a dummy package which installs nothing, but still handles all the applications you want installed.
If you want some suggestions don't hesitate to contact me.
I have an old legacy application around for which I only have the installer. it doesn't do anything more than uncompress and register itself and his library's.
As i don't have the source-code it gives me a lot of headaches in maintenance problems. In some particular computers (Acer Aspire One with Windows) just do not run.
I would like to extract the files and re-create this installer with NSIS. Is this possible or I'm nuts?
The original installer has been created with Ghost Installer Studio.
One option is to find a machine that it does run on, and then install some "install guard" software (often called things like Acme Uninstaller). Use this to track what actually gets installed and then copy the relevant files and write your own.
It looks like a lot of hassle to me, and you may be on thin ice with regards to the licence.
You could try using a program that monitors new files being installed and then get the files that were installed from their respective paths.
For instance, I found this in about 10 seconds with Google, there are more programs like it, but I am inexperienced with those available for Windows.
If it uses a MSI file, you can use Orca or SuperOrca to get at the stuff packed inside.
This is typically the job of Repackaging Software. There are a few ways such tools work but typically it is by taking a look at a system before and after you install it on a clean system and building a custom installer from the detected changes. This is normally done to generate a customized installation and/or one that can be automated in its deployment. I'm not aware of one that generates an NSIS package, the standard format today is MSI (Windows Installer).
If you have the original installer any repackager will do, but even without the original setup program you can do as some of the others here suggest and monitor the use of the application for its requirements. The two most popular repackaging tools are InstallShield AdminStudio and Wise Package Studio. The feature may also be part of a setup authoring solution, so check with your in-house developers if you can.
A full list of repackaging tools can be found here at AppDeploy.com
One free repackaging tool available for creating Windows Installer setups from another [legacy] setup tool (with which I must divulge I'm involved) is the AppDeploy Repackager. Another free repackager is WinINSTALL LE.
I read in this article:
http://technet.microsoft.com/en-us/library/cc709628.aspx
That Windows detects Installers through file names, following this tip, Is it better to include setup in the file name for the installer
I mean ProductSetup.msi is better than Product.msi???
It's hard to think that Windows does this kind of detection :-)
This only applies to EXE files. If you've got an MSI file, it's up to the MSI file to specify which parts of the MSI require elevation or not.
That's news to me, but it does seem like Windows Vista treats files differently when they have "setup" in their name. It will probably just prompt you for administrative rights up front if it detects that it's an installer, which is what you'd want.
Also worth reading is How User Account Control Affects Your Application, to ensure that your setup runs as administrator embed the correct manifest into the setup EXE. This way it doesn't matter (to Vista) what your installation is called.
That said however, if you expect the application to be installed on a terminal server then if your installer is called something like SETUP.EXE or INSTALL.EXE Terminal Server will automatically kick into "install mode". Should save you some headaches from those customers who don't know they should be in install mode first, or choose not to install via Add/Remove Programs (which also kicks install mode in automatically)
When creating a setup/MSI with Visual Studio is it possible to make a setup for a simple application that doesn't require administrator permissions to install? If its not possible under Windows XP is it possible under Vista?
For example a simple image manipulation application that allows you to paste photos on top of backgrounds. I believe installing to the Program Files folder requires administrator permissions? Can we install in the \AppData folder instead?
The objective is to create an application which will install for users who are not members of the administrators group on the local machine and will not show the UAC prompt on Vista.
I believe a limitation this method would be that if it installs under the app data folder for the current user other users couldn't run it.
Update:
Can you package a click once install in a normal setup.exe type installer? You may ask why we want this - the reason is we have an installer that does a prereq check and installs anything required (such as .NET) and we then downloads and executes the MSI. We would like to display a normal installer start screen too even if that's the only thing displayed. We don't mind if the app can only be seen by one user (the user it's installed for).
ClickOnce is a good solution to this problem. If you go to Project Properties > Publish, you can setup settings for this. In particular, "Install Mode and Settings" is good to look at:
The application is available online only -- this is effectively a "run once" application
The application is avaiable offline as well (launchable from Start Menu) -- this installs the app on the PC
You don't actually have to use the ClickOnce web deployment stuff. If you do a Build > Publish, and then zip up the contents of the publish\ folder, you can effectively distribute that as an installer. To make it even smoother, create a self-extracting archive from the folder that automatically runs the setup.exe file.
Even if you install this way, if you opt to use it, the online update will still work for the application. All you have to do is put the ClickOnce files online, and put the URL in the project's Publish properties page.
Vista is more restrictive about this kind of thing, so if you can't do it for XP you can bet Vista won't let you either.
You are right that installing to the program files folder using windows installer requires administrative permissions. In fact, all write access to that folder requires admin permsissions, which is why you should no longer store your data in the same folder as your executable.
Fortunately, if you're using .Net you can use ClickOnce deployment instead of an msi, which should allow you to install to a folder in each user's profile without requiring admin permissions.
The only way that I know of to do this is to build a ClickOnce application in .NET 2.0+
If the user of your application has the correct pre-requsits installed then the application can just be "launched".
Check out:
Microsoft Family.Show
IF UAC is enabled, you couldn't write to Program Files. Installing to \AppData will indeed only install the program for one user.
However, you must note that any configuration changes that require changes to the registry probably(I'd have to double check on that) administrator privilege. Off the top of my head modifications to the desktop background are ultimately stored in HKEY_CURRENT_USER.