So the wizards of IT brilliantly put in to place new GPO that prevent access to the AppData folder structure in Windows for user PC's. However, when you publish an application the application when installed is defaulting to C:\user\roaming\appdata, well the application can no longer access that directory.
How do I create a custom install path for the application to use?
Thanks!
Does this link about changing the InstallLocation attribute help?
Also keep in mind that user settings are stored in an AppData folder so if you use that you may need a workaround for that too.
I would create a Setup and Deployment project to handle installation. It is very easy to add using the Setup Wizard project template. In this project you will be able to specify the default location of the application folder.
My Assumption if you are using ClickOnce Deployment you can't define the installation path.
The idea of ClickOnce is making sure it doesn't require admin privileges to install the update therefore it kept under user app profile. There was discussion here
if there is a reason to put you data and keep it safe from ClickOnce update.
refer to here Keep data safe from ClickOnce deployment
another option as #Kevin mentioned create standalone MSI installer would allow you to specific the application install path however it would be manual intervention.
Personally I don't know why there is a need to prevent access to user AppData folder (perhaps re-define GPO to allow certain app folders access) could resolve that given if you want to continue using ClickOnce deployment
Related
How do I add write and modify permissions to a text file that will be installed in the Application Folder in the File System on Target Machine?
Your post seems to indicate that you are using Visual Studio setup projects, the Installer add-on.
Two basic points:
There is no support for doing this in Visual Studio setup projects, so you would need to write custom action code that alters those permissions. The code to do that is about security APIs, so you probably won't get an explicit answer here.
The most common reason people do this is that the application needs to update the file, and it fails because updating ProgramFiles folder content requires administrator privilege. If this is the case then your application design should be improved by having the file in (say) the User's Application Data folder, which has that name for the obvious reason that's the preferred location for such data.
I created a setup project in VS2008. This setup copy some folders/files to the program files folder. Also, it adds some windows environment variables.
During the instalation, I am requested to confirm something in a UAC dialog.
This works fine, and all files are copied.
The problem begins when my program is running and I have to modify the a file´s content.
An exception is thrown, saying that I have no permission. Also, if I try to do the same operation in Windows Explorer => same problem.
My question is:
If I have the permission to install my software in program files folder, shouldn´t I be able to write in this folder as well?
Well, it seems that this is a general permission problem. By default normal users (and applications) cannot write to %PROGRAMFILES%. There are folders specially provided for application data storage such as ApplicationData
The reason the setup does install into program files is because this default behaviour of the Windows Installer. Check this link for more info on the Windows Installer and clickonce setup
Can I ask the user WHERE to install the application during install time?
Most setups prompt the user where to install the application, I'm sure you are familiar with it. How can I do this with the visual studio publisher? (If it cannot be done from the VS publisher could you reccommend a program that can do it? Or do I have to do it manually?
As per this MSDN post: "ClickOnce application are installed per user in the user application cache. These applications are managed by the ClickOnce service. If you want to install to a user specifed location such a Program Files... you should use MSI or some other installer technology."
The other deployment methodologies supported by Visual Studio are discussed here
No, you can't. ClickOnce install the application in a user's AppData folder it's not installed like a traditional application. If you want to have more control over stuff like this you need to write your own installer.
Not sure if it is changed, but ClickOnce applications are installed per user in the user application cache. You cant change that location. This means that if 2 different user share the same machine there are 2 different copies of your application.
When deploying a ClickOnce application, the installation folder URL, is there a way to make it relative to the web application directory hosting it?
For instance, for local testing I publish to http://localhost:54592. However, when this web application is deployed, it could be anything from http://www.foo.com to http://www.foo.com/MyVirtualDirectory
I would like the path to find the installer in its current location, and the application after installer has completed to reference the web app host, not the development URL.
Platform: Visual Studio 2010, .NET 4.0, and C#.
This works out of the box if you stick with *.application as your application source. You just need to pick a folder inside your web application to publish your ClickOnce application, and the application is available from this address under your application.
For example, if copy your site to C:\inetpub\wwwroot\mysite and copy the ClickOnce to C:\inetpub\wwwroot\mysite\myapp with MyClickOnce.application inside the ClickOnce folder.
Then you expose your website as http://example.com and the ClickOnce application is available under http://example.com/myapp/MyClickOnce.application.
In case of setup.exe you need to recreate the manifest after you publish it to the destination location. This is done with mage.exe.
In the Options dialog, the Manifests tab, you can check the box that says "Exclude deployment provider URL".
Then provide the URL to your user for the installation based on where you put it. When they run it, it will create and save the URL where they got it from, and always look there for updates.
I have found strange issue during execution of installatio file made by VS 2010. The installer should copy some files into App Data of current user. When I run installer on account with admin privileges, everything is ok. Problem appears while installing on guest account. For example I try to install app on guset account A. I must select run as option. I choose user B with admin privileges. After installation all files are copied into folder App Data of user B, not A as I expected... why? Is there any solution for this?
It is called deployment project and it is outdated and broken technology - I suggest using WIX. Those stupid proejcts should hnever have been in Visual Studio - they dont even adhere to the basics how MSI files should work.
One thing you can not nicely control is the elevation request needed for activating admin priviledges. WIX allows you full control over the MSI features.
I must select run as option. I choose user B with admin privileges. After installation all files
are copied into folder App Data of user B, not A as I expected... why?
Ah - logic? You install AS USER B - so surely the files go into User b's folder.
in general you need admin priviledges to install softawre. A gues can not do it. Point. Installation is a tricky high priviledge thing, not something for someone who has no rights on the computer.
The installer should copy some files into App Data of current user.
Invalid per definition. Point. A normal install run should not install anything into a user's app data - what is another user runs the software? The software can make copies when it starts (from shared app data), but a NORMAL install (not a per user install) should never put stuff into the users personal AppData folder. This is a violation of basic MSI principles.
Symantec has a good documentation on the only valid way to do that (and sorry, setup proejcts just dont support advanced features for MSI:
http://www.symantec.com/business/support/index?page=content&id=HOWTO4840
As it reads:
In order to install files to each user's profile, a self-repair of the application must occur.
WIX has similar answers in a post:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/installing-files-to-user-s-application-data-folder-td5377311.html
I assume you don'd o a per user install ;)
I also assume you don't set the registry key according to ICE38 (setup warning):
http://msdn.microsoft.com/en-us/library/aa368961%28VS.85%29.aspx
In general: DO NOT DO IT. User AppData can / should happen when the user starts the app.