I made the msi package to allow the user to choose installation directory for the application.
I want the user to only download the application where it doesn't need read write permissions from the user, like %APP_DATA%/Roaming/my_app_example_name.
The reason being that the application has a self update mechanism and updates itself when it detects a new version on the server. The update itself doesn't use an msi launcher, it just downloads the new version of the app from the server using a http request, and replaces the old files.
.
.
For example, in the popular game spiral knights, they implemented this mechanism like this:
Here, you can see that the default installtation directory is the Appdata folder
If i change the installation directory to ProgramFiles, and try to install, I get this error :
It effectively blocks installation to the directory simply because it doesn't have permissions to create a folder from the installer itself, there.
I would like to implement the same mechanism, or something similar, because I think this is a very elegant solution to my problem. So any ideas on how to do this?
(By the way, I'm using jpackage to create the msi launchers)
You can use --win-per-user-install option with jpackage.
On Windows, the default is c:\Program Files\application-name; if the
--win-per-user-install option is used, the default is C:\Users\user-name\AppData\Local\application-name
More details on options at jpackage docs
Related
I'm building a setup executable using Visual Studio 2015 Setup Project template.
I added an external executable in the file system of my package that the user needs to install to be able to run my program. Then, I added this package as a custom action on Commit.
I want my install package to recognize if this external executable is already installed on the user computer by looking at the registry of looking at a certain folder structure on the computer (the method to check is not defined yet).
How can I set up this kind of check for the custom actions ? I've seen that there is a Condition property when clicking on the .EXE in the Custom Actions window, but all I can find about this property is that, which does not really answers my problem.
VS setups offer a registry search, and that search will set a property name that you define (in uppercase). If the registry entry exists, meaning that you don't need to run the program, then you give the custom action a condition of NOT FOUNDREGISTRY assuming FOUNDREGISTRY is the name of the property.
Having said that, if that program is a redistributable that installs something then:
They are typically smart enough to figure out if they need to do anything or not, and that includes seeing if what's already installed is an older version, so they should run anyway because it's a newer version. So it may be best to just run it anyway.
If the executable wraps a MSI-based setup then it will fail because you can't install an MSI-based setup with a custom action in a VS MSI setup.
I'm deploying a .NET application with VS2010. My application creates .txt file in the logs folder in the same directory with .exe:
app.exe
add.exe.config
logs (folder)
I used setup project to create a MSI installer. When I installed in the client machine C: drive or any drives I have no problem to create the .txt file, but when I installed in C:\Program File\myAppFolder or C:\Program File(x86)\myAppFolder I cannot to create the .txt file.
It is a poor design to write to install location for your application. It is better to write to the ApplicationDataFolder. The ApplicationDataFolder is under the user profile and the application will have access to write there when run as that user. #Ken White provided a very good pointer to an existing StackOverflow answer about this.
If this is a legacy application that must write to that folder, then you'll need to modify the permissions on the log folder such that all users can write to the folder. This is possible to do with the Windows Installer (aka: MSI) but I'm not sure that the Visual Studio setup projects expose it. The WiX toolset definitely supports doing such things.
An old post but I needed to do similar recently so I guess it is still valid! While I don't advocate bad design, in the real world sometimes we have to bend to requirement.
Writing to the application folder is possibly under Win7 and it is possible to set this up via an installer class in an MSI created by VS2010. You just need to give a relevant group (suggest either the "Users" group, or if you want to give more control over who gets what, supply a selection screen) Write-Data access.
Using DirectoryInfo on a path you can then get the security data from GetAccessControl.
When you have your Group known, get the SID for the group and AddAccessRule also supplying the required ControlType value.
Then set the access control on the DirectoryInfo object (SetAccessControl) using the security data object.
You can get the SID from the Groups principal object if you do a search with PrincipalSearcher.
Hope this helps
paul
This generally all depends on:
Whether your app requires to be run as administrator for other reasons and..
Whether your app is provided for limited users.
If the app requires elevation for a bunch of other reasons (and not just updating files in restricted locations) then the normal way is to have an elevation manifest embedded in your app. This isn't a good thing from the security point of view, but if you absolutely need admin privilege then this is the way to do it.
If the only operation requiring elevation is updating/creating data in the Program Files folder then don't put the file there. Every case of this that I've seen has been lazy programming where the code just refers to the file name and consequently it goes in the Program Files folder (more accurately in the same folder that the app runs in). The cure for this is to put the data file in the correct location (such as User's Application Data folder). As Rob Mensching says, you should alter the permissions on the install folder only if this is a legacy app that you cannot change.
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.)
My installer requires there be two files in the same directory in order for it to install.
The installer (.msi file)
An organization specific config file that the installer copies. (This file is customized by the organization and then distributed to it's end users).
Since there are two files, the file has to be distributed as a zip file. Which presents the issue of if a user tries running the .msi without actually extracting the zip... only the msi file gets extracted. I am able to detect the issue in the install process and tell the user they need to unzip the file... but you know how noone actually reads error messages.
So, I'd like to make it more foolproof and so i was wondering if there was a simple tool that i could let my customers (ie the organization) be able to make modifications to the config file and when finished create a .exe file which when clicked would extract to a temp folder and then run the msi. I know there are solutions for this which require commercial software. I'm wondering if a simple freeware tool exists that can do this.
Edit: Accepted Solution Notes:
The one issue i ran into is the iexpress wasn't designed to be used for .msi files. As a result on the step that asks you for the Install Program. It's a combo box which if you had added a .exe file in the previous step could just select the .exe file from. Instead you have to manually type in
msiexec /i yourinstaller.msi
I was very pleased to find such a simple solution that's built in to windows. The only way this could be better is if it allowed for wildcards so that your iexpress project would be able to handle changes in the msi file's name which occur with each version. And defaulting the Install Program to the .msi file. These minor inconveniences are offset by the fact that end user wouldn't need to install any new software to create the package so I have stopped looking for other tools.
You could try using iexpress.
It enables you to package up a set of files which can be extracted, with the option of running an installation command automatically after extraction. It also has options to enable you to prompt users about things, show a EULA, restart the computer, etc..
I believe it comes as part of Windows (part of IE?) - try running iexpress.exe from the run dialog to get the UI.
The Wix project has a bootstrapper and packager for dealing with this kind of thing.
I've used wix a lot but haven't really looked at the bootstrapper/packager much - last time I had a quick look it wasn't really usable but that was a long time ago so it may be better now.
I'm guessing that the config file is something like a properties file, and that you want users to set the values of the properties "foo" and "bar". You don't need a separate tool to update the file.
I would do this:
Put one or more dialogs in the install that ask the user what the values of foo and bar should be, and set a couple public properties accordingly.
Write a custom action that writes the config file out to whatever location you want, including whatever values you want for foo and bar. This would be pretty easy in vbscript.
Put the custom action somewhere in the execute sequence (ideally as a deferred execution action, since you're making changes to the system).
Add an entry to the RemoveFile table, so the config file is removed on uninstall (assuming you don't want it to be left behind.)
Add an entry to the LaunchCondition table, to prevent users from doing a silent install. Or if you want silent install to be allowed, make the names of the public properties that hold the config data known, and make them part of the LaunchCondition. You would block "msiexec /i myapp.msi", but you could choose to allow "msiexec /i myapp.msi FOO=Something BAR=SomethingElse".