this may be a stupid question... but I have created a setup.exe using Installshield that installs my application. I cannot use an MSI because I want to include prerequisites, like for example .NET 4.0 framework web install.
So, I put this setup.exe on my web site somewhere, but when I try to download this I get 'The page you are requesting cannot be served because of the ISAPI and CGI Restriction list settings on the Web server.' Obviously a security is going on that makes it impossible to download executables.
So I zip it to setup.zip, and now it can be downloaded.
My question is: what is the best way to distribute such a setup via the web? Is it acceptable to make it a zip file for users to download (because then they have to unzip it first), or should I just allow an executable to be downloaded?
I've seen this practice for some products and it's always annoying. Why would you give me a ZIP file which contains a setup file? There are no advantages, but a lot of disadvantages:
I need to perform an extra step to extract the ZIP
I need twice the disk space (the ZIP plus what's inside it)
Most users don't see a ZIP file as an installer, they are used to "setup.exe" or "setup.msi"
The correct approaches are:
configure your website to allow EXE file downloads
or
distribute a ZIP which contains your application files (instead of using a setup file)
Related
I've an HTML5 application packaged into OpenFin environment. The complete package is inside an .Exe executable that we wish to ship to end users.
We tried to create a link to the executable that could be downloaded from a web link - but seems most of the company' security permissions environments/firewalls block .Exe file downloads.
Our requirement is to ship the .EXE file (we do not have certain files - so may not be able to effectively create a clickonce deployment package)
Is there a better way, even using ClickOnce to ship the .Exe via web url?
You can wrap exe into a zip and can ship..
I have an app that I am moving to another server. It is complaining that it is missing TABCTL32.OCX. I have located this file on another server and I want to copy and paste it across.
I have discovered that there is also a file called TABCTL32.DEP on the server I am moving from. Do I have to copy both files across or is the dependency file optional?
I have tried it with an without the DEP. The app works in both cases. It is a production server so I want to be sure.
Those .DEP (depdendency) files are instructions about a library meant to be used by packaging tools. These files have no run-time significance, containing only development metadata. They are text files.
They contain the preferred ("designed") location to install the library, sub-dependencies of the library including optional localization "satellite" resource DLLs, version information, etc.
See articles such as INFO: How Setup Wizard and PDW Use Dependency Files.
This is information a packager should use along with other "rules databases" such as VB6DEP.ini. Programmers are also supposed to create them if they expect other developers to use their libraries.
If you are using an "impaired" 3rd party packaging technology that is ignorant of .DEP files it is up to you to read them and incorporate the information they contain in your build process. You are also responsible as a developer to keep your dev machine's .DEP files and VB6DEP.ini file up to date, since they often are not updated by Microsoft anymore.
You can't just copy files willy-nilly from one machine to another. Go find this program's installer and run it on the new machine.
A .dep file is a file used by the Visual Basic Setup Wizard to determine what dependencies your ocx file have. You can open the file with Windows Notepad to view the contents.
Unless you are using the Visual Basic Package and Deploy Wizard, you can ignore this file.
For more info, see INFO: How Setup Wizard and PDW Use Dependency Files
I am creating a WIX installer project. During one managed customized action, I need to create a file (other than the deployed files specified in the components of WIX) in the installation folder, which by default is the Program Files folder. I am experiencing the "Access denied" problem in Windows 7. After some searching, I found out that people say it is not advisable to create files into Program Files folder. Instead, try to create files into for example AppData folder. For example, see this link:
C# Access denied to path in a Windows Application
But my question is, the generated file is crucial to our SW, so it must reside in the installation folder. Isn't it the target of SW installation, I mean, to create file in most of the cases Program Files folder? Does it mean the only files should be added into installation folder, during the installation, are the deployed files (basically the targets of XCopy)?
My file can't be made deploy-able in the WIX, i.e, it can't be made ready before the installation. So what's the proper way or best practice to handle such situation: a file must be generated during the installation, into the installation folder. It is not some log file that I can put somewhere else. I tried to create a Permission element in WIX for the INSTALLADIR, although it seems to be against the rule mentioned in the link, but it still failed. Thanks!
UPDATE:
Based one MichaelUrman's commen, some more information. The generated file is needed after the SW is installed and necessary during normal launch of the SW. And I think it needs to be modified during normal use after the installation. And as I mentioned my a comment to #caveman_dick answer, my CA is actually in commit phase, I don't know whether there is any difference between it and normal deferred CA
Set the custom action to Execute="deferred", that will run the command elevated and should give it the required permissions to create the file.
Since you need to update that file from the main application, and I'm assuming your application does not require elevated privileges, you have three options.
The first is the worst: without a manifest, your executable's attempts to write to the Program Files folder will typically result in it being redirected to the Virtual Store (see File Virtualization). It sounds like this isn't happening in your case, so you can't use it.
The second option is to modify the application to store this in an appropriate location such as the ProgramData folder, or Common Documents, or (if appropriate) a per-user location under LocalAppData. This is typically the best approach, but has the highest development costs.
Finally the third option is to create the file and change its permissions (or in some cases to change the permissions on the folder containing the file), allowing limited users to modify this file. See LockPermissions or MsiLockPermissionsEx for the Windows Installer way to approach this. Change the permissions on as few files or folders, as restricted as possible, to keep the system as safe as possible if you go with this option.
I would like to build a setup, or something like that (1 file), to deliver a single file to a target system. Plugin for an application, installable to users AppData folder.
After some research I'm still not sure in which direction to look. I can create the setup project with Visual Studio 2010, but all of the options so far seem to be way too heavy or have some flaws.
SetupProject stubbornly wants to create an application folder which I don't need, and complains about installation to user folder. Cab doesn't seem to offer automatic install, oneclick is not available for the project, etc.
Is there an easier setup technology I could use?
Requirements:
Install -> Copy 1 file to a folder
under %userprofile%\3rdpartyapp\ if
it exists (xcopy).
Uninstall -> Delete the file and also
one folder with custom settings
(rmdir \s).
Distribution -> Free for commercial
use.
Maybe I should just pack the file in self extracting c++ exe?
It may be overkill for one file, but I like InnoSetup for creating setup packages. Check it out, and see if it suits you. It is very easy to use and deploy.
Take a look at WiX toolset. It allows creating MSI-based installers, and the installer could be quite simple:
Search for %userprofile%\3rdpartyapp;
Copy the file into it, if it exists;
Fail install or maybe create it, if it does not exist.
Uninstall would be very simple: it would need to remove the installed file. To remove a subfolder of 3rdpartyapp, you can use RemoveFolderEx element.
MSI registers the installed app with Add/Remove Programs Control panel. Uninstall is handled by Windows Installer service, therefore you don't need to copy any additional files or programs to support uninstall.
I think any setup technology is too heavy for one file. I'd go with creating a simple application that would extract the file from its resources stream and copy it into %userprofile%\3rdpartyapp.
Uninstall is trickier: there should be something that can handle the uninstall process. It could be a batch or script (js, vbs) file stored somewhere in user's profile, another simple application or the same one. (Installation process can also be handled with a script.)
Suppose I have created an installation exe using NSIS. The exe is a compressed (7zip maybe) file that contains everything to install the application on a fresh machine, and that comprises big exe files (like .NET runtimes, mysql server installer, etc.). I have to send via the Internet the big exe file to another person.
To save time and bandwidth, I'd like to remove the contained big files; I can do that using 7zip to open and extract all the files in the original exe, delete the big ones, rezip using again 7zip. This works up now.
The other party will download the reduced zipped file, but then has to reintroduce the big files in some way, recreating the exe installer.
I don't know how to achieve that. I've tried with paquet builder with no success.
Is that possible?
I don't think it's possible. But I think I have another solution for you. Why don't you simply execute separate executables (like .NET runtime etc) from NSIS bundle? This way you don't need to include them into resulting bundle. Just tell the user to download them and put the into proper place. It would be easier than instructing them to assemble bundle from pieces, no?