I have an executable application setup.exe for Windows that I realized with Launch4j/Inno Setup based on Java.
I often frequently release new versions and bug fixes.
I would like to know if there is a mechanism to install updates automatically?
Inno Setup does not have any built-in mechanism for implementing automatic updates.
You need to implement that yourself:
Make your application check for new versions (against your application webpage?). E.g. on startup (on a background thread?)
If the application detects a new version, make it download an installer to a temporary location.
Make the application execute the downloaded installer. You can make the installer run in silent mode (/silent switch). The application should close itself, to unlock any files it is using, to allow files update.
This approach will need the update installer to prompt for Administrator privileges. If you need the update to proceed completely seamlessly, you will have to implement a service. For that, see Deploying application with .NET framework without admin privileges.
Related
I am developing desktop database application. Using rdlc report and reportviewer. Everything was fine in developing process, reportviewer was showing all data smoothly. I deploy app with Inno Setup. But when I install the app, the reportviewer is not showing data. While data is correctly inserted in the tables.
For applications that work incorrectly or fail completely, when installed by Inno Setup to Program Files folder, the first thing to test, is to try to deploy the application manually to the same folder.
If the application fails even after a manual deployment, the most usual problem is that the application requires a user to have write permissions to application folder. As on modern versions of Windows a user typically does not have write permissions to the Program Files folder, the application does not work. So the problem usually has nothing to do with Inno Setup, but it's a problem of the application itself.
To solve the problem:
The best solution is to redesign the application so that it does not require write permissions to its folder. Windows applications should not require write permissions to their folder. That's against Windows guidelines. The application should write data to a user profile folder (C:\Users\username\AppData) or to a common data folder (C:\ProgramData).
A dirty workaround is have the installer grant a user(s) write permissions to the installation folder. Do that only, if you cannot get the application fixed (e.g. it's 3rd party application).
See Inno Setup - How to set permissions of installation folder.
Even more gross workaround is to configure the application to be executed with elevated (Administrator) privileges.
See Inno Setup desktop shortcut (link) which has "Run as administrator" advanced property set
or How to set 'Run as administrator' on a file using Inno Setup.
Another solution is enabling legacy compatibility mode that makes Windows redirect all application write attempts to a virtual store. See also Application installed with Inno Setup writes files to unknown location instead of its installation folder.
There are numerous other possible reasons, why the application might be failing when installed, including:
You omitted some dependency:
DLL library
.NET assembly
.NET Framework
Java Runtime Environment
other runtime
COM/ActiveX object, etc.
The application requires some configuration:
a file
a registry key [including COM/ActiveX object registration]
an environment variable, etc.
The application is not designed to be executed from a folder that has a space in its name (Program Files).
The application gets confused by Windows File virtualization (though it's unlikely). See Application installed with Inno Setup writes files to unknown location instead of its installation folder.
I am developing desktop database application. Using rdlc report and reportviewer. Everything was fine in developing process, reportviewer was showing all data smoothly. I deploy app with Inno Setup. But when I install the app, the reportviewer is not showing data. While data is correctly inserted in the tables.
For applications that work incorrectly or fail completely, when installed by Inno Setup to Program Files folder, the first thing to test, is to try to deploy the application manually to the same folder.
If the application fails even after a manual deployment, the most usual problem is that the application requires a user to have write permissions to application folder. As on modern versions of Windows a user typically does not have write permissions to the Program Files folder, the application does not work. So the problem usually has nothing to do with Inno Setup, but it's a problem of the application itself.
To solve the problem:
The best solution is to redesign the application so that it does not require write permissions to its folder. Windows applications should not require write permissions to their folder. That's against Windows guidelines. The application should write data to a user profile folder (C:\Users\username\AppData) or to a common data folder (C:\ProgramData).
A dirty workaround is have the installer grant a user(s) write permissions to the installation folder. Do that only, if you cannot get the application fixed (e.g. it's 3rd party application).
See Inno Setup - How to set permissions of installation folder.
Even more gross workaround is to configure the application to be executed with elevated (Administrator) privileges.
See Inno Setup desktop shortcut (link) which has "Run as administrator" advanced property set
or How to set 'Run as administrator' on a file using Inno Setup.
Another solution is enabling legacy compatibility mode that makes Windows redirect all application write attempts to a virtual store. See also Application installed with Inno Setup writes files to unknown location instead of its installation folder.
There are numerous other possible reasons, why the application might be failing when installed, including:
You omitted some dependency:
DLL library
.NET assembly
.NET Framework
Java Runtime Environment
other runtime
COM/ActiveX object, etc.
The application requires some configuration:
a file
a registry key [including COM/ActiveX object registration]
an environment variable, etc.
The application is not designed to be executed from a folder that has a space in its name (Program Files).
The application gets confused by Windows File virtualization (though it's unlikely). See Application installed with Inno Setup writes files to unknown location instead of its installation folder.
I am working on a VB6 application which has many executable and an Active X dlls.
And there are to be updated in c;lient machines to lates version once in a while which i am asking the user to update manually.
Can you please suggest me a way using which i can update it automatically from the files that can be available online.
Thanks.
Windows Installer has features supporting Patching and Upgrades. Using those techniques you can create various levels of "upgrade" packages.
Your application would need a separate "update" utility that is spawned when the user approves updating, perhaps in response to a prompt your program raises after checking for new versions.
This updater would check the current version and the remote site's catalog of updates to pick the appropriate package, download it to a temporary location, start Windows Installer to process the package (or packages, sometimes you might need to run several Installer runs), and clean up the temp location. Then you might offer to restrt the updated application or on some occasions need to reboot.
This updater would be a fancy form of the common "installation bootstrapper." As you can tell it needs some "smarts" in order to tell what package or packages to download and install in what sequence, when it needs to request rebooting, etc. This would probably be based on a downloaded "rules script" it obtains as part of selecting a valid update option.
After all, sometimes you can just apply a minor upgrade or patch upgrade, sometimes you need a more complete install or entire reinstall.
If your needs are extremely simple (just an EXE and maybe a few DLLs and OCXs - preferably using reg-free COM) you may not need to go to these lengths. However when you start adding in other considerations like multiple programs, data directory creation and security settings, possibly running a settings file conversion or even database conversion, DCOM, firewall, etc. configuration, database drivers or providers, etc. things get complicated quickly. Too complicated for simple snatch and grab updating.
And admin rights/UAC issues are a factor so you'll probably have to deal with privilege elevation.
None of this is trivial stuff. There are people who do little more than construct and test such deployment systems as their entire job.
If you use soemthing like Inno setup to install the application then an update is simple a matter of running that periodically.
You can either detect there is a new version available by checking a web site/local server, or just prompt to run the update after X days.
We have an ERP application which is built in VB6 and it was running just fine till a few of our customer upgraded all their systems to Win7.
This software is programmed in such a way that it registers a few plugins (found in plugin folder) which are COM based at runtime. Now when the software is run by user without setting Compatibility Mode and Run as Administrator setting it fails and crashes.
I know we can manually set both Compatibility Mode as well as Run a Administrator by right clicking on program executable and then going to its properties. But this looks very unprofessional.
I think there will be some way to tell Win 7 to automatically run a software in Compatibility Mode and Run as Administrator.
Please help me.
Compatibility is an administrative function, not a development or deployment function. It is better to fix the application where possible, especially to remove any requirement for elevation.
There are plenty of tools for investigating the issues so you can correct them. However globally registering "plug ins" at runtime is a nasty one. VB6 component self-registration is always global unless registry virtualization can redirect it. Why not create installers for the plug-ins that can run elevated once during installation?
There are ways to set compatibility less manually, even as part of installation - though Microsoft discourages this. Maybe take a look at:
Compatibility Fix Database Management Strategies and Deployment
However the effort required might be better spent on remediating the problem. Support costs will be less over time.
As the other answers have said, you shouldn't need to run all the time elevated.
If you want to register the plugins after its started (as a normal user), you can use ShellExecute() with the "runas" verb to run regsvr32.exe, or use COM elevation which has been discussed many times before.
You can indicate that an application must run as admin by specifying it in the Application Manifest, which in an xml file that you can either embed or deploy with your application.
Once your application is running with admin rights it should be able to register and load the plugins. You should not need to run in compatibility mode to access the COM plugins.
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.