Using VB 2008, building a standard forms exe.The app will beplaced on a UNC path and available to usersonly via this path, along with several supporting files (readonly).
If I do not intend to use the Publish feature, then canI ignore ClickOnce and all of the security settingson the Security tab?
The problem is that when the app is run on user's workstation using UNC path, I get a fatal error about not having sufficient privileges to read a necessary config text file also on the same UNC path. Only admin users (Windows XP sp3) can read the file, but almost all of the app users will not be admins.
I have some info that to get around restricted permissions, I'll need to use a 3rd party setup/install app to adjust machine access rights. Anyone know if that's correct? However, we do not want to install the app locally, just enable users to run it from the shared network location.
thanks, Bob. | | bob8900 Wednesday, November 12, 2008 9:23 PM | It appears that part of my problem (app on share unable to open text file also on share) was due to malfunctioning BITS service caused by faulty Windows Updates rollouts. As BITS is fixed on the serversthe problem seems to be going away. | | bob8900 Friday, November 21, 2008 4:39 PM | If you don't want to use ClickOnce, you will need to xcopy all of the necessary fields to a folder and run the app from there. You also have to make sure the user is running the right version of the .Net Framework, and any other prerequisites that you need.
I don't know if this will work for the user to run an online-only app in this way.
What happens if you map a network drive and run it without the UNC path, but with a drive letter? Does it work?
RobinS.
GoldMail.com
| | RobinDotNet Thursday, November 13, 2008 3:45 AM | We run our Windowsapps in a ClearCase snapshot view stored on a Unix server, accessible via a share. I don't think that we can't depend on a drive letter (although some users are able to map one), given our network config and security restrictions.
The problem could be the NET framework not beingavailable for the client execution but I'm not getting that expected error message, which is why I'm baffled. I will double-check client machines for the framwork. | | bob8900 Thursday, November 13, 2008 4:27 AM |
You are using a feature of the .NET Frameworks that was something in place before ClickOnce came into being, but I can't remember the name of it, it's been 4+ years since I've thought about it! (Touchless deployment, or somethign like that)
IIRC, the deal is that your app runs with Intranet permissions, since it wasn't launched from the local hard drive. That has limited and restricted security permissions. In order to change the permissions, you need to use the .NET Frameworks Configuration Tool, or something like that, to give full (or other) permissions to the assembly/exe.
That's what ClickOnce does for you. The security tab puts information into the ClickOnce manifest, and the ClickOnce runtime engine applies those permissions on the system for you.
So, it really is easier to publish via ClickOnce, you can publish to a UNC share and you don't need a web server. But, you can make this work, but you'll need to build/run a script on each machine under Admin privileges, or manually configure the permissions, on each machine to get it to work.
Hope that clarifies things a bit.
| | David Guyer MSFT Thursday, November 13, 2008 6:25 AM | Can someone point me to the specific setting on the Security tab that would allow remote users to read a file also located on the UNC path? I see entries like FileIOPermission, and I've experimented with both Full and Parital Trust, but so far no combination of settings allows my application's config file to be read on the UNC path.
Related question: do these Security Trust settings take effect only if the app is first Published then Installed, or can I just copy the app and its supporting files to the shared server location?
RE your final suggestion: exactly where do I need to reconfigure workstation privileges? MS Help for VS only says "have your admin change security policy" without giving any details. I'd appreciate any pointers to workstation policy settings that are relevant to the file IO permission problem I've having.
Thanks, Bob | | bob8900 Thursday, November 13, 2008 3:16 PM |
You can only do this if you are using ClickOnce. And, you need to install via ClickOnce to get the engine to make the CAS security settings for you.
I'm not sure what the right permission is, I would have thought it was a Network permission of some type, but I'm not sure...FileIO is a great place to start.
To set the policy, use caspol.exe, it's a command line tool, but there's quite a bit of documentation on it on MSDN.
Can you clarify how it's not working? If you set to full trust, publish to the UNC share, install via ClickOnce to your machine, run from your machine, then your app should have access to UNC shares. | | David Guyer MSFT Friday, November 14, 2008 5:42 AM | We are using a share mapper (TotalNet Advanced Server) to map our ClearCase Unix file storage to logical Windows file systems, so I'm not sure that we can "publish", since there is no actual Windows Server to publish to and configure.
To recap, the problem is that the Windows app as executed by the client, but stored on the UNC path, is not able to open a text file (same UNC path) required by the app. Framework returns debug msg that points to the function that attempts to open the file. Same app will work if located on local workstation.
I thank everyone for their answers, if I find a solution forthis issue I'll come back and post it.
~Bob | | bob8900 Friday, November 14, 2008 3:55 PM | Publishing to UNC is using file copy commands, and is not using the http protocols. If that's not working, you can use FTP... or you can build to your local machine, but with the address you'll be copying it to in your settings, and copy it there through whatever process works.
| | David Guyer MSFT Friday, November 14, 2008 9:48 PM | It appears that part of my problem (app on share unable to open text file also on share) was due to malfunctioning BITS service caused by faulty Windows Updates rollouts. As BITS is fixed on the serversthe problem seems to be going away. | | bob8900 Friday, November 21, 2008 4:39 PM |
|