I have a windows desktop application which is currently available on a Linux server for download on user's machine. I want to automate the process of MSI packaging on the same Linux server using any EXE/DLL.
I have an App.exe and App.txt file. Some information should be read from text file and injected into exe before creating an MSI package. This entire process has to happen dynamically in the Linux server only after the user clicks on download.
Can anybody point me in the right direction as to how i can achieve my goal? I want to achieve the same by having minimum dependencies on any additional/3rd party tool. TIA for any time and effort.
p.s - I have done some R&D about various installers but none of them were matching the criteria as they have too many dependencies.
False Positive Risk: Creating a new binary for every user would seem to be very unwise because of malware scanners and their ability to recognize "known" versions of binaries (by hash).
If you create a new binary for each user, the malware suite might suddenly start to quarantine your setup without any warning or sense. This problem is not trivial anymore as malware control is hardened everywhere and setups that run with elevated rights are "prime suspects for risk management".
Digital signatures can help, but they are merely a guarantee that you made the setup, and not a guarantee that the setup doesn't contain anything harmful. Nothing worse than signed malware vectors. In fact it is proof positive that the malware came from you :-). Note: some people even manage to tamper with signed executables. The combination of the latter two fact is very troubling.
Application Setup: I like to eliminate such features and details from the setup and make the application itself responsible for it own configuration on first launch after installation. I find this more reliable and easier to debug.
Custom Configuration: You can apply custom configuration information at runtime via various mechanisms. You should add in a transform, or you can create a batch file next to the setup with this information embedded and pass to the MSI or the setup.exe.
Batch File?: The msiexec.exe command line supports passing parameters to the MSI. You can generate a batch file that will run the setup with such parameters if you design your setup to support these "incoming" parameters.
msiexec.exe /i myinstaller.msi ADDLOCAL="Program,Dictionaries" SERIALKEY="1234-1234" /qn
Transform: You can also create a transform to contain the parameters (a transform is a tiny MSI fragment with settings and changes to the original MSI):
msiexec.exe /i myinstaller.msi TRANSFORMS="mytransform.mst" /qn
A transform would be difficult to create on a Linux box, seeing as they are COM-structured storage files native to Windows only. I am not sure if it is even possible, but maybe.
Some Links:
Can the resulting command line be determined after running an .msi installer?
Change Program Name and Shortcut Title during installation
How to make better use of MSI files
We have had some success with wixl from msitools.
Also WiX will run under WINE.
However, in both cases we have not had EmbedCab="yes" work, which may or may not affect you.
Related
I created some custom modules and Visual Studio drops the build files directly into the Kofax Bin directory. It is important to note that I'm using the modules as Winforms applications and Windows services (at the same time). The generated files are
MyModule.exe
MyModule.exe.config
MyModule.InstallLog
MyModule.InstallState
MyModule.pdb
I think that I only need the .exe file here. Of course I also add the .aex file to the directory to install the module. I also created two batch files to register the module on the local machine
RegAscEx.exe MyModule.aex
pause
and to install the module as a Windows service
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\installutil.exe" "%~dp0MyModule.exe"
pause
after running them as administrator I can delete them from the directory of course. I would like to know if it should be always fine to provide the .exe file, .aex file and the two batch files (which will be deleted later) only?
Basically correct. Some thoughts:
Build your application using the Release configuration (vs Debug). See discussion here.
PDB files usually are not needed in production. Still, you may want to generate and keep them if you plan on debugging in production.
The app.config file should be kept. Maybe you want to use application settings later on, and the supportedRuntime element is useful if someone wants to run your CM on a machine without that version of .NET framework being present (Windows will show a nice error message)
Keep the AEX file. This is required if someone wants to register your CM on another machine (e.g. deploying from DEV > TEST > PROD).
Include a single batch file that allows registering your CM on a new machine as well as adding it to Kofax Capture. Here's an example:
rem "C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" SmartCAP.CM.Sample.dll /codebase /tlb:SmartCAP.CM.Sample.tlb
rem RegAscSc.exe /f Register.inf
Another thing I usually include is the ability to install my CM in a similar fashion to native KC modules, for example: SmartCAP.CM.Sample.exe -install and SmartCAP.CM.Sample.exe -uninstall. Take a look at the AssemblyInstaller class for details.
i have a .msi file . i want to add functionality in the installer.
i want to add
License Key Condition ,when someone try to install the application.
i don't want others to use this application. Only for those who have key for this software.Please help me if you can. Thanks
This question needs some improvement and clarification I think, but I will attempt an answer.
The application itself should be designed to allow license keys to only be accessible for certain users. Generally this involves storing the license in HKCU rather than HKLM. You cannot really change this in the setup, it is the application that will expect to read the license key from a predetermined source. Some applications are able to store license keys both per-user or per-machine - it all depends on its design. What application is this?
One way to "emulate" this for applications that only register the license key per-machine (for all users), is to remove the shortcuts to launch the application for users who do not have rights to use the application. This can involve installing the MSI "per-user", but it doesn't always work as intended.
It also depends on how you will distribute this software. Does it get installed remotely from a deployment system such as SCCM, or will you install interactively on every computer? If the latter is the case, you can install as the user who will use the application, and check if there is an option called "Install for current user" (or equivalent). If you deploy remotely you should create a transform to set the same option (install for current user) and invoke the install via SCCM whilst that user is logged in.
Where does Linux fit into this equation? Are you running Wine or some emulation software?
I have what might be a simple question and might be....a more complex one. We are preparing to add NSIS to our software, that is, we want people who use our software to be able to create installers using NSIS, but through our software. (We'll be creating functions using NSIS, acknowledging NSIS, etc.) What I am trying to figure out before we get started is how many/what files our customers will be required to have on their hard drive for NSIS to work. So, we just need to know if nsis can be used standalone or if it requires the user to install it into program files, or if it requires a lot of different files in AppData - If we have to bundle a few .dlls, that's not a problem and is expected. Ultimately, if we end up having to bundle NSIS as well, that's fine - We just want to make sure it'll work on other people's computers without telling them to go download it.
MakeNSIS does not read/write from/to the registry or anywhere else and only needs a handful of files for minimal operation.
To build a simple installer you need:
NSIS\MakeNSIS.exe (Just calls Bin\MakeNSIS.exe)
NSIS\Bin\MakeNSIS.exe
NSIS\Stubs\* (If you are only going to use a specific compression mode you only need one, and the uninstaller file if you want uninstall capability)
If you want to use the Modern UI you need its header files, some files from Contrib (Graphics and UI) and system.dll and nsDialogs.dll from the plugin folder.
Everything else is optional but I would recommend that you also bundle:
NSIS\Include
NSIS\Plugins (You can remove stuff you will never need; dialer, splash etc)
NSIS\Contrib (Language files, graphics and UI)
You can find license information here.
You could also just ask the user to install it and enter the path to it in your setup program...
I would just include all of the files. (It's only 5MB or so) NSIS has a zip archive as well as exe installer that includes the necessary files. (Or just zip up the installed directory from exe installer).
From my experience, NSIS does not need to be installed to work. I run a fleet of build servers that build NSIS-based installers, and they each just have the files extracted in a directory. The installer is never run on them. This should mean there are no DLLs to register or things like that.
Just make sure you are following whatever their licensing terms are - I have not reviewed redistribution/bundling of their files in another product, since that is not something I do.
We have a web application that we need to make easier to deploy for our clients.
The current workflow for a fresh install:
Ensure there is a JRE on machine (32 or 64bit)
Install Tomcat (32 or 64bit)
Create a database in Oracle or SQL Server (we provide SQL scripts for this)
Write some values into our settings table, like hostname. (Can get user to verify these, but dont want user to have to tap them in.
Create a connections properties file (we provide a mini JAR app to help with this) that will sit under Tomcat.
We have two WAR files for our actual web application. These can be split across two machines, but for now, lets assume they both get dumped under Tomcat.
Start Tomcat so that it deploys the WARs
This is a tedious process for our users
I want to encapsulate it into an installer and have been looking at doing this in NSIS which seems to have a large community, but then also stumbled across install4j, which although seems to be lesser known, is more specific to java based applications.
Just wanted to get some feedback from more experiennced users out there on the best choice for platform.
I do not want to get half way in, and then realise I have chosen the wrong installer platform.
Disclaimer: My company develops install4j.
First of all, install4j is a commercial tool, so that's a considerable difference to NSIS. Other major differences are:
install4j is a multi-platform installer builder for Windows, Mac OS X and all POSIX compatible Linux and Unix platforms.
install4j's main focus is for installing Java-based applications, for example it handles the creation of launchers and services and provides several strategies for bundling JREs. Many things that you need for a Java application will work out of the box.
install4j provides its own IDE which focuses on ease of use
Scripting is done in Java. The IDE provides a built-in editor with code-completion and error analysis. Actions, screens and form components have a wide range of "script properties" that allow you to customize the behavior of the installer.
For install4j, I can address your single requirements:
Ensure there is a JRE on machine (32 or 64bit)
In the media wizard, select a JRE bundle. If you select the "dynamic bundle" option, it will only be downloaded if no suitable JRE is found.
Install Tomcat (32 or 64bit)
I would recommend to simply add the root directory of an existing tomcat installation to your distribution tree.
As for the service, you can either use the Tomcat service launcher from the Tomcat distribution or create a service launcher in install4j. In both case you can use the "Install a service" action on order to install the service.
Generated services have the advantage that an update installer knows that they are running and automatically shuts them down before installing any new files.
Create a database in Oracle or SQL Server (we provide SQL scripts for this)
Use the "Run executable or batch file" action in order to run these scripts.
Write some values into our settings table, like hostname. (Can get user to verify these,
but dont want user to have to tap them in.
Any kind of user interaction is done with configurable forms. With a couple of text field form components you can query your settings.
This also works transparently in the console installer and the automatically generated response file will allow you to automate installations in unattended mode based on a single execution of the GUI installer.
Create a connections properties file (we provide a mini JAR app to help with this) that
will sit under Tomcat.
If you already have a JAR file which does that, just add it under Installer->Custom Code & Resources and add a "Run script" action to your installer to use the classes in your JAR file.
Any user input from form components that has been saved to installer variables can be accessed with calls like
context.getVariable("greetingOption")
in the script property of the "Run script" action (or any other script in install4j).
We have two WAR files for our actual web application. These can be split across two
machines, but for now, lets assume they both get dumped under Tomcat.
If you just add the Tomcat directory structure to your distribution tree, you can have these WAR file pre-deployed. Otherwise you can use "Copy file" actions to place the WAR files anywhere.
Start Tomcat so that it deploys the WARs
That's done with the "Start a service" action.
I'm looking for something that can copy (preferably only changed) files from a development machine to a staging machine and finally to a set of production machines.
A "what if" mode would be nice as would the capability to "rollback" the last deployment. Database migrations aren't a necessary feature.
UPDATE: A free/low-cost tool would be great, but cost isn't the only concern. A tool that could actually manage deployment from one environment to the next (dev->staging->production instead of from a development machine to each environment) would also be ideal.
The other big nice-to-have is the ability to only copy changed files - some of our older sites contain hundreds of .asp files.
#Sean Carpenter can you tell us a little more about your environment? Should the solution be free? simple?
I find robocopy to be pretty slick for this sort of thing. Wrap in up in a batch file and you are good to go. It's a glorified xcopy, but deploying my website isn't really hard. Just copy out the files.
As far as rollbacks... You are using source control right? Just pull the old source out of there. Or, in your batch file, ALSO copy the deployment to another folder called website yyyy.mm.dd so you have a lovely folder ready to go in an emergency.
look at the for command for details on how to get the parts of the date.
robocopy.exe
for /?
Yeah, it's a total "hack" but it moves the files nicely.
For some scenarios I used a freeware product called SyncBack (Download here).
It provides complex, multi-step file synchronization (filesystem or FTP etc., compression etc.). The program has a nice graphical user interface. You can define profiles and group/execute them together.
You can set filter on file types, names etc. and execute commands/programs after the job execution. There is also a job log provided as html report, which can be sent as email to you if you schedule the job.
There is also a professional version of the software, but for common tasks the freeware should do fine.
You don't specify if you are using Visual Studio .NET, but there are a few built-in tools in Visual Studio 2005 and 2008:
Copy Website tool -- basically a visual synchronization tool, it highlights files and lets you copy from one to the other. Manual, built into Visual Studio.
aspnet_compiler.exe -- lets you precompile websites.
Of course you can create a web deployment package and deploy as an MSI as well.
I have used a combination of Cruise Control.NET, nant and MSBuild to compile, and swap out configuration files for specific environments and copy the files to a build output directory. Then we had another nant script to do the file copying (and run database scripts if necessary).
For a rollback, we would save all prior deployments, so theoretically rolling back just involved redeploying the last working build (and restoring the database).
We used UnleashIt (unfortunate name I know) which was nicely customizable and allowed you to save profiles for deploying to different servers. It also has a "backup" feature which will backup your production files before deployment so rollback should be pretty easy.
I've given up trying to find a good free product that works.
I then found Microsoft's Sync Toy 2.0 which while lacking in options works well.
BUT I need to deploy to a remote server.
Since I connect with terminal services I realized I can select my local hard drive when I connect and then in explorer on the remote server i can open \\tsclient\S\MyWebsite on the remote server.
I then use synctoy with that path and synchronize it with my server. Seems to work pretty well and fast so far...
Maybe rsync plus some custom scripts will do the trick.
Try repliweb. It handles full rollback to previous versions of files. I've used it whilst working for a client who demanded its use and I;ve become a big fan of it, partiularily:
Rollback to previous versions of code
Authentication and rules for different user roles
Deploy to multiple environments
Full reporting to the user via email / logs statiing what has changed, what the current version is etc.