views:

9049

answers:

12

Hello, fellow anthropoids and lily pads and paddlewheels!

I'm developing a Windows desktop app in C#/.NET/WPF, using VS 2008. The app is required to install and run on Vista and XP machines. I'm working on a Setup/Windows Installer Project to install the app.

My app requires read/modify/write access to a SQLCE database file (.sdf) and some other database-type files related to a third-party control I'm using. These files should be shared among all users/log-ins on the PC, none of which can be required to be an Administrator. This means, of course, that the files can't go in the program's own installation directory (as such things often did before the arrival of Vista, yes, yes!).

I had expected the solution to be simple. Vista and XP both have shared-application-data folders intended for this purpose. ("\ProgramData" in Vista, "\Documents and Settings\All Users\Application Data" in XP.) The .NET Environment.GetFolderPath(SpecialFolder.CommonApplicationData) call exists to find the paths to these folders on a given PC, yes, yes!

But I can't figure out how to specify the shared-application-data folder as a target in the Setup project.

The Setup project offers a "Common Files" folder, but that's intended for shared program components (not data files), is usually located under "\Program Files," and has the same security restrictions anything else in "\Program files" does, yes, yes!

The Setup project offers a "User's Application Data" folder, but that's a per-user folder, which is exactly what I'm trying to avoid, yes, yes!

Is it possible to add files to the shared-app-data folder in a robust, cross-Windows-version way from a VS 2008 setup project? Can anyone tell me how?

A: 

Add a Common Files Folder special folder to the File System for the setup. You can then add files to that entry in the File System hierarchy.

Peter Ritchie
A: 

Thanks for taking the time to answer Peter. Yes, yes! I could put the files in "Common Files," but as that's a sub-directory of "Program Files," it has all the same permissions issues as the app's own install folder. I have confirmed this by trying it, yes, yes!

There's really no question about where the files should go. The question is how to get them to go there with the tools I have at hand, yes, yes!

Lyman Enders Knowles
+10  A: 

I have learned the answer to my question through other sources, yes, yes! Sadly, it didn't fix my problem! What's that make me -- a fixer-upper? Yes, yes!

To put stuff in a sub-directory of the Common Application Data folder from a VS2008 Setup project, here's what you do:

  1. Right-click your setup project in the Solution Explorer and pick "View -> File System".

  2. Right-click "File system on target machine" and pick "Add Special Folder -> Custom Folder".

  3. Rename the custom folder to "Common Application Data Folder." (This isn't the name that will be used for the resulting folder, it's just to help you keep it straight.)

  4. Change the folder's DefaultLocation property to "[CommonAppDataFolder][Manufacturer]\[ProductName]". Note the similarity with the DefaultLocation property of the Application Folder, including the odd use of a single backslash.

  5. Marvel for a moment at the ridiculous (yet undeniable) fact that there is a folder property named "Property." Babies full of rabies, who comes up with this shit?

  6. Change the folder's Property property to "COMMONAPPDATAFOLDER".

Data files placed in the "Common Application Data" folder will be copied to "\ProgramData\Manufacturer\ProductName" (on Vista) or "\Documents and Settings\All Users\Application Data\Manufacturer\ProductName" (on XP) when the installer is run.

Now it turns out that under Vista, non-Administrators don't get modify/write access to the files in here. So all users get to read the files, but they get that in "\Program Files" as well. So what, I wonder, is the point of the Common Application Data folder?

This here's a re-search project. Re-search means "look again," don't it? Maybe this was something I found once and it got away again. Yes, yes!

Lyman Enders Knowles
nice write up, previously i had always been creating paths in code. much nicer to do in the installer.
Darren Kopp
Combination of installer variables should read [CommonAppDataFolder][Manufacturer]\[ProductName]\ ...
Matze
+1  A: 

I'm running into the same problem with non-administrators not having adequate permissions to those shared files intended for 'all users'. Have you figured out the answer to this problem yet? I've been posting this question in a few places, but no one is replying...

I found this:http://blogs.msdn.com/oldnewthing/archive/2004/11/22/267890.aspxSo, powerful forces within Microsoft don't think it should even be *possible* to write apps this way. I haven't found a practical answer yet.
Lyman Enders Knowles
A: 

I'm not sure if this will help in your case or not.

But if you add a private section to your app's config file

You can specify extra folders to check in your app.

If what you are saying is that you want to be able to install into other folders on the machine, then that is a problem. Essentially the whole reason that MS has restricted this stuff is to keep malicious code off machines where the user is unaware of what they are installing.

So, this won't work if you need another directory. What this fix does is allow you to specify where within your app to search for files......

A: 

I am using Visual Studio 2005. I set the Property property of the Custom Folder to be PROGRAMFILESFOLDER (see step 6 in answer 2 by Lyman Enders Knowles in this discussion thread). But the contents in this folder are still installed in a user selected TARGETDIR, not the c:\Program Files. Could someone tell why?

Thank you very much in advance!

A: 

This worked for me using VS2005 but I had to change the DefaultLocation, I added a '\' to seperate the CommonAppDataFolder.

[CommonAppDataFolder][Manufacturer][ProductName]

Don't know if this was a typo but Lyman did refer to the odd use of a single backslash but this does not seem correct.

+2  A: 

I solved it this way. I kept the database file (.sdf) in the same folder as where the application is installed (Application Folder). On the security tab in the properties window for the main project, i checked the "Enable ClickOnce Security Settings" and selected "This is a full trust application", rebuilt and ran the setup. After that no security problem

I am using Visual Studio 2008 and Windows Vista

+1  A: 

I had the same issue. The setup project gives the user the option to install the app "for the current user only" or "for all users:. Consequently, the database file would end up in either the current user's or the All Users application data folder. The setup would have to write this information somewhere so that the application can later retrieve it, when it comes to accessing the database. How else would it know which application data folder to look in?

To avoid this issue, I just want to install the database in the All Users/Application Data folder, regardless if the application was installed for one user or for all users. I realize, of course, that two users could not install the application on the same computer without overwriting each other's data. This is such a remote possibility, though, that I don't want to consider it.

The first piece of the puzzle I got here:

Form_Load(object sender, EventArgs e)
{
  // Set the db directory to the common app data folder
  AppDomain.CurrentDomain.SetData("DataDirectory", 
            System.Environment.GetFolderPath
           (System.Environment.SpecialFolder.CommonApplicationData));
}

Now we need to make sure that the data source contains the DataDirectory placeholder. This piece came from here. In the DataSet designer, find the DataSet's properties, open the Connection node and edit the ConnectionString property to look as follows:

Data Source=|DataDirectory|\YourDatabase.sdf

Then I followed Lyman Enders Knowles' instructions from above for how to add the Common Application Data Folder to the setup project and placed the database file in that folder.

I then followed Ove's suggestion from above, i.e. I checked the "Enable ClickOnce Security Settings" and selected "This is a full trust application.

After that, the application deployed fine on Vista and the database file was accessible for both reads and writes.

cdonner
A: 

Question for Lyman Enders Knowles

Did you ever get an answer to your question. Is there a way to have the Deployment project in VS 2008 create and install a file into C:\USERS\PUBLIC? Did this solve the write security problem?

I've been searching everywhere and stidll no clear simple answer.

Thanks Dweezil

Al Walton
A: 

Hello, Myabe someone can help me here...

First issue: I added the items from Lynn Knowles post regarding commonappdata folder in my setup project. I then changed the seucrity on the one click, but when I use one click, it doesn't pick up the setup project???

My project is -- Solution --Project (code) --Setup and deployment project

Not sure if it's set up incorrectly, or if there are some settings in the oneclick that i have to change. I was building the setup and deployment project, but that is not the same as oneclick.

Second Issue: When I use oneclick it launches the application. I'm trying to build an installer that can be zipped and installed on the users machine. I don't want to launch the app, i just want a deployment package to install on the users machine

ARGGGGHHHHH !!!! Please help. or direct me to a good oneclick tutorial

Mike
A: 

I built the setup and deployment project using both Lyman and Peters advice. When I install, there still aren't write permissions to the access database. As a matter of fact, when I go to that directory under ProgramData, and try to open the db in Access, it opens it as a 'ReadOnly' database.

Any suggestions

Mike