I have finished my .NET application but I could not figure out how to handle finishing it's setup as it seems a bit complicated to me.
So I was thinking of using InnoSetup, but unfortunately I don't know anything about it.
In brief I want to make a setup for doing these tasks:
Install .NET Framework 4.0, if not available
Install Crystal report runtime engine 13 according to your system 32-bit or 64-bit
Install MSSQL Server Express 2008 (32-bit or 64-bit depending on user's OS) with these settings
SQL Server instance name: SQLEXPRESS
Authentication mode: Mixed
Username: user1
Password: pass1
Ask about language selection (Arabic or English) for installing my app (MyApp.exe) and install accordingly the selected version.
Of course before installing my app there should be one windows about License Agreement
I think this is not very difficult except for SQL server part,
Please guys if anyone can help me and give me Inno code for doing this setup.
Thanks
It's not that hard to learn the Inno Setup scripting language, so you should definitely read the documentation.
For installing .NET dependencies, check out THIS CodeProject article. I used a slightly different approach. I added my dependencies as zip archives, thus I didn't need to list my files, and also added unzip.exe and used it to extract them to the temporary folder and launch the installer from there. HERE's an SO question explaining how to do it.
Some of the stuff you asked for are supported features of InnoSetup. E.g. use the [Languages] section for selecting language or the LicenseFile parameter for license agreement.
Related
So i have a scenario where i am using a ISS file to install an instance of oraclexe on windows systems.
It works for all machines with "Administrator"(localadmin) rights.
However it is failing on domain user logins(these logins are part of the Administrators group).
When i install the oracle separately on that machine we get the install fine.
My doubt is that the installer response file is old and was likely recorded on a Administrator login.
Can that be a possibility.
Application Repackaging: In corporate settings one often resorts to application repackaging to deal with legacy setup.exe
setups, and this is usually exactly because of their problematic
behavior in silent installation scenarios. I describe this process
here:
How to monitor and log manual installation
(section "Capture / Repackaging").
Technical Details: At a technical level Application Repackaging is shockingly simple in its approach. It involves scanning the system
before install and after the install and then capture the changes,
clean out a lot of junk settings and wrap the finished, new installer
in an MSI package (or some other format). Despite the technical
simplicity, the quality of such packages depend a lot on the knowledge
of its creator. Badly packaged MSI files can be loose cannons.
Package Format: Application Repackaging can be done in various formats, but the established MSI format (Windows Installer) has
a number of benefits for corporate use centering around reliable silent running and reliable remote management - arguably the
most important aspects of corporate deployment. Please see this answer
for some more details:
How to create windows installer.
Once you have an MSI you install it silently using standard
msiexec.exe command lines.
Tools: Commercial tools Advanced Installer and Installshield are the most well-known repackaging tools. They are
quite pricey. Sometimes people pay deployment consultants to do the
single package they have to convert. Very advisable in terms of the
knowledge needed to succeed as well. List of repackaging tools from
installsite.org.
Technical Limitations: Repackaging has limitations. Localization (support for different language versions) is one problem area - you capture the English version, so where are the
German files for the German version? That kind of stuff. These issues
are always different from setup to setup. It is reverse engineering to
be honest. Also, dynamically generated content that is
machine and user specific such as license keys, certificates, database connection strings with machine names and similar means you
might have to do a lot of work to get things to operate correctly, and
sometimes it is even technically impossible. It is a black art, but
when done right MSI files of excellent quality results that deploy
silently without much drama.
(Re)Packaging Team: Many corporations have whole teams dedicated to capturing and preparing legacy and modern setups for large scale
deployment. Many of them are offshore and unknown to most employees. I
would check if your company has such a team.
Logging?: What does the log files say? Is this a legacy setup.exe installer or does it install an MSI file under the hood? I would also check the system's event log for any clues - especially if you don't have a good log file. There should be a default Setup.log file created in the same directory and with the same name (except for the extension) as the response file.
The /f2 parameter can be used to specify a different log path:
setup.exe /s /f2"C:\Setup.log"
Here is a Flexera article on the subject of silent installation: https://resources.flexera.com/web/pdf/archive/silent_installs.pdf
And the most common silent install with logging command line:
setup.exe /s /f1"C:\sample\uninstall.iss" /f2"C:\sample\uninstall.log"
Response Files: The honest truth is that silent response files have never been reliable to achieve silent running. What often happens is that a special dialog pops up that was never recorded in the response file run, and then it all falls apart. This can be a "low disk space" warning or some other form of unexpected, random dialog that nobody predicted could show up.
Unexpected Dialog: Accordingly there could indeed be something different showing up when you install as domain users that are members of the admin group, although I can't really think of anything in particular that springs to mind as a likely candidate. I suppose the issue could also be one of privilege and access nonetheless. There could be certain NT privileges that are denied accounts in the standard user list for example. All just theories, I would go for the logging to get something concrete to start with.
Installshield Help File:
There are several relevant sections in the Installshield help file.
Please study these if you need more tweaking of the installation parameters. All switches are documented here - these links are for
the 2018 edition of Installshield:
Setup.exe and Update.exe Command-Line Parameters (Basic MSI, Installscript MSI)
Advanced UI and Suite/Advanced UI Setup.exe Command-Line Parameters (Suite Projects)
Some Links:
Uninstalling an InstallShield Installscript MSI program using C# silently
Create MSI from extracted setup files
Downloaded source package of DotnetNuke and I am new in dotnetNuke. Can anyone help me to clarify the process of installing DotnetNuke.
I am following this Install DNN
I've got a tutorial on installing DNN8 found here.
You can also follow this text tutorial
Setting up your development environment can vary based on what your
end goal is. If you are doing module development for your own use, and
within your own DNN environments, you can ignore a few of the settings
below. If you are doing module development with the idea that you
might turn around and give the modules away, or sell them, then you
will likely want to follow the guidelines set forth below to support
the widest array of DNN installation environments.
I recommend that each developer have their own local development
environment, with a local IIS website running DotNetNuke, and a SQL
Server 2008/2012 (not express, though you can use it) database for the
website. Having an individual development environment makes group
module development far easier than if you share
environments/databases.
Choosing a DotNetNuke Version Choosing a version of DotNetNuke is
important when you start your development for couple of reasons. For
modules that you are developing for yourself, you need to ask, what is
the minimum version of DotNetNuke that you have in production. Are you
running DNN 5.6.1? Are you running 6.2.6, 7.0.0, 7.0.6? Based on the
answer you can determine what version of DNN you should setup as your
development environment. You shouldn't be developing on a newer
version of DNN than what you have running in production. As with
everything there are ways around this, but I am not going to go into
the details on that in this tutorial.
As a developer working to create modules and release those, you might
have production sites that are running on the latest and greatest
version of DNN, but what about your customers? Or your potential
customers? You have to ask yourself, do you want to provide support
for really old versions of DotNetNuke? From a development perspective
you will probably say no, but from a business perspective, you might
say yes, and here’s why. Not everyone upgrades DotNetNuke websites as
they should, and often times you will find that some people never
upgrade. While I don’t advise taking that approach to managing a
DotNetNuke website, it is a fact of life that people don’t always
upgrade and there are thousands of people, if not tens of thousands,
that have sites that aren’t running on the latest version of DNN. You
should take that into account when you are doing your module
development, if you compile your module against an older version of
DNN then your module should run on newer versions of as well, for
example. If you compile your module against DotNetNuke 6.2.6 it will
likely run on every version of DNN released since then. Though there
are extended cases where this won’t always work, DNN strives to
maintain backwards compatibility, this isn't always possible.
You might also want to use features that are only available starting
with a specific version of DotNetNuke, such as the workflow
functionality found starting in DNN 5.1, in that case you may choose
not to support older versions of the platform out of necessity. This
will minimize the market in which you can sell your modules, but also
can make for less support and an easier development cycle due to the
features that DNN provides.
Choosing a Package Now here’s one that may baffle you a bit. I’m going
to recommend that you use the INSTALL package for whatever version of
DotNetNuke that you download. What? The INSTALL package? What about
the SOURCE package? Well you can use the source, but you don’t need
it. The module development that I’m setting you up for doesn't require
the DNN source, and using the INSTALL package makes your development
environment cleaner. We aren't going to be opening the DotNetNuke
project when we do our module development, so why have the files
sitting around for nothing? Also, if you've ever tried to use the
SOURCE package for anything, you'll know it isn't easy.
The steps for setting up your development environment will apply to
both the Community and Professional editions of DotNetNuke.
Installation Configuration Once you have the version selection out of
the way you can go through the installation process. While I’m not
going to walk you through the minutest of details of each step of
installing DotNetNuke in this post, I will at least try to point you
in the right direction for each step.
Download the INSTALL package of the version of DotNetNuke you want to
use in your development environment.
Extract the files in the INSTALL package to a location of your
choosing, this location is where you will point IIS (the web server)
when we can configure the website. In my environment I typically use
c:\websites\dnndev.me\ (One item of note: you may need to right click
on the ZIP file and choose Properties before extracting, on the
properties window if you have an UNBLOCK option, click that. Some
versions of Windows have started blocking files within the DotNetNuke
ZIP files, which will cause you problems later during the actual
install.)
Setup IIS IIS is the web server that comes with Windows computers. DNN
7 requires IIS 7 or later (7,7.5,8.0), so you will need at least
Windows Vista, Windows 7, Windows 8, or Windows Server 2008 R2,
Windows Server 2012.
In IIS you should create a new website (Note: If you use an existing
website in IIS be sure to add the HOST binding for DNNDEV.ME), and
point to the folder where you extracted the INSTALL package.
Note: With DotNetNuke 7.0+, .NET Framework 4.0 is required, so be sure
that your application pool is configured to run under 4.0, and not
2.0.
Set File Permissions Setting up the file permissions for your DNN
install is often the step that causes the most trouble. You should
right click on the FOLDER in which you extracted DNN
(c:\websites\dnndev.me) and choose properties. Choose the Security
tab. You need to add permissions for the account in which your
website's application pool is running under. You will want to setup
the permissions to give the account Full or Modify permissions for the
DNNDEV.ME folder. Which account you will use will vary based on your
version of IIS, here’s a simple list of some of the default accounts
based on the version of IIS.
IIS Version Operating System Account IIS 7 Windows Vista, Windows
Server 2008 localmachine\Network Service IIS 7.5 Windows 2008 R2,
Windows 7 IIS AppPool\APPPOOLNAME IIS 8 Windows 2012, Windows 8 IIS
AppPool\APPPOOLNAME
Note: If you are using IIS7.5/8.0 you’ll notice in the above table
that we have APPPOOLNAME in the identity, this is because when you
setup a new website in IIS a new application pool is created. In place
of you should type in the name of the application pool that was
created. You can also bypass this and configure your application pool
to use the Network Service account instead of a dynamic account if you
would like.
Database Configuration In SQL Server you should go through and create
a new database. I always create a database with the same name as the
website, so in this case DNNDEV.ME. Once you have created the
database, create a user that can access that database. I always use
SQL authentication, turn off the enforce password requirements, and
give the user DB Owner and Public access to the DNNDEV.ME database.
Remember the username and password you create here as you will need
them when you walk through the Installation screen for DotNetNuke.
DotNetNuke Installation Screen Populate the installation screen with
the standard DNN information, Host username, password, etc. For the
Database option, choose Custom and configure your database connection,
providing the Server IP/Name, the Database name (dnndev.me). For the
database authentication you'll want to choose the option that allows
you to enter the username/password for the database user that you
created previously.
Now there are two additional options you can configure, normally I
would tell you not to modify these, but from a development environment
perspective I do recommend that you change the objectQualifier
setting. It should be blank by default, you should type in “dnn”
(without quotes), this will prepend “dnn_” to all of the objects that
get created by DNN such as Tables and Stored Procedures. This is not
something I recommend from a production stand point, but if you are
developing modules for sale, then supporting objectQualifier in your
development is recommended. It will save you time down the road if you
have a customer who has an objectQualifier defined on their production
databases.
Follow the following video and it has total two parts one and two part links are givenbelow
Part one
Part two
I'm trying to release a program with a client/database approach.
The client and database can be installed on 2 different computers.
What I'm trying to do is an installer that at the beginning asks if you want to install the client, the database or both.
Is this possible? Which section should I modify?
I warn you, I've never wrote an Inno Setup script, I always used ISTools, but if there is no other way, I'm ready to get my hands dirty :P
Edit: a bit more info.
At the moment I have 3 installers, one for the client, one for the DB (which is postgreSQL) and one for PDFCreator.
What I'm doing is copy the files to a directory and then ask at the user what he wants to install: [Run] section, Post Installation.
Yes, it is possible. Take a look at the CodeDlg.iss example. It show how to create a dialog to ask which edition to install. In the case of CodeDlg, it is various editions of a program (light, sponsored, paid) but the concept is the same. I've done this before as well. In my case, during initialization, I read a registry setting and set some variables up to choose which version (client or server) I install. I don't have it here but will get it later and add to this answer.
I have a service installation that in order to get it to work on Win2k, I had to include instsrv.exe in the installer, since Win2k doesn't include sc.exe (which I use for XP and up) and instsrv.exe is not always installed...so I cannot count on it being there. (instsrv and sc are both used to create/install the service on the system).
I have not been able to find the license terms or distribution rights for instsrv however. Is there going to be a legal issue with me including this Microsoft exe in my own installer and therefore distributing it to the customers of the product? If you can point me to an actual license document for this exe it would be greatly appreciated.
The instsrv.exe program appears to come from the Windows 2003 Resource Kit, which you can download freely from Microsoft. The referenced page indicates that when you install it, you'll encounter the EULA (End User License Agreement), which would be where you'd read about the license terms regarding things like redistribution.
You should read that agreement yourself. The way I read it, you can't bundle the Kit with your installer, though you could certainly arrange to have it downloaded automatically and have its own installer invoked by yours, with your end user having to click to accept the Microsoft EULA at that time.
What about using a different approach? I believe for a simple service installation there are probably only a few registry keys or something to tweak. Maybe a simple script (Python or such?) could do the job as well.
I'm no legal expert, but is the issue the use of instsrv.exe or that it's lying on the PC until you uninstall your product?
Would it be redistribution if you craft your installer in such a way that you merely package instsrv.exe, unpackage during the install process, run it via a custom action, then let the installer cleanup process delete it from the temporary location?
As a big sidestep, you could change installers to WiX v3. They have standard custom actions to install services. You get the added Msi easily active directory integrated bonus. You could go with something else entirely but I assume this is a very last resort.
In the end, services are nothing more than registry entries in a specific format so you are not entirely limited to using those programs. You just get the bonus of blaming Microsoft if either instsrv or sc happen to blow up the registry.
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.