[.net] VB.Net File i/o
Author
Hi, I'm creating a program at work in VB.NET 2003. I've got the program on a shared drive on the server so everyone can see it. I'm loading a connection string from a text file one directory level above the executable. It works fine when its on the local hard drive but the File.Exists check I do fails when I run it off the mapped network drive.
Does VB.NET i/o work on mapped drives?
EDIT: An acquaintance of mine who works in MS DevDiv popped online and I asked your question to him--he told me not to quote him on this, but he says it sounds like a permissions issue of some kind, as that will cause it to always return false. Might want to check that. .NET apps tend to be notoriously annoying to run off a network drive, in my own experience.
[Edited by - EdR on May 13, 2008 12:26:23 AM]
[Edited by - EdR on May 13, 2008 12:26:23 AM]
Couple of questions:
Why is the connection string in a text file one directory above the app?!?
By "I've got the program on a shared drive" do you mean the actual .exe or did you publish it to the drive? If the former, why not do the latter?
Ideally you wouldn't use a mapped drive since you can't necessarily ensure that it's the same for everyone. Use the actual server name instead. It does sound like it could be a permissions thing though.
Why is the connection string in a text file one directory above the app?!?
By "I've got the program on a shared drive" do you mean the actual .exe or did you publish it to the drive? If the former, why not do the latter?
Ideally you wouldn't use a mapped drive since you can't necessarily ensure that it's the same for everyone. Use the actual server name instead. It does sound like it could be a permissions thing though.
Author
Thanks for the help. I have the whole solution on the mapped drive. The connection string is one directory above because it's shared by multiple programs. I have been having permission issues with my account. I had to add myself to the Administrator group just to get Visual Studio to build the project. I'll do some tinkering around here and see if I can get it working.
Hi,
IMHO it's clearly a permission problem you're facing. When running a .NET application from a server drive, the framework forbids by default some methods to be executed (File I/O are one of those). However, you can configure your clients to allow for all or some of those to be executed when called from a shared drive.
Check out the .NET Framewok configuration panel under Control Panel --> Administrative Tools --> .NET Framework configuration x.y (There is a separate one for each version of the framework).
When right clicking on the Runtime Security Policy Node, you can choose "Evaluate Assembly...". This will give you for a given assembly (dll or exe) the permissions currently set for it.
Now you need to tell the framework to trust your assembly. Either you select under the same node "Trust Assembly...". This will trust only the specified assembly and allow it to run (although I'm not 100% sure if it will give all permissions to the assembly).
The best way to do it is to do the following:
Create a new permission set and specify in the permission set the permissions which it should grant.
Create a new Code group and associate it with the new permission set.
In the code group you can specify different options to define to which assemblies it will apply. (e.g. assemblies with a given Hash value, in a specifiy directory etc.) The best way to do it however, is to sign your assembly with a strong name (check google for signing a .NET assembly) and then associate the code group with that strong name. Thus, every assembly you compile with that strong name will be granted to run with your permission set.
In an enterprise, this is probably the best way to do it. You will only have to configure every workstation once. Once your assemblies are signed with your strong name, the clients will always be able to run them.
For easy deployment of the configuration, you can create an MSI from within the .NET configuration panel which will automatically apply specified configurations to the clients (Create deployment package).
I had to do some testing to get it working correctly back when I had pretty much the same problem you have, but once it is all set up, it works like a charm.
For security reasons however, I'd recommand placing the connection string somewhere else. Not sure what the best place is for WinForms applications (as I haven't done a lot of them), but for example in ASP.NET applications, the most secure location is the web.config file. (So my guess is for Winforms that the app.config file would be a place to put it)
Hope I could help you
IMHO it's clearly a permission problem you're facing. When running a .NET application from a server drive, the framework forbids by default some methods to be executed (File I/O are one of those). However, you can configure your clients to allow for all or some of those to be executed when called from a shared drive.
Check out the .NET Framewok configuration panel under Control Panel --> Administrative Tools --> .NET Framework configuration x.y (There is a separate one for each version of the framework).
When right clicking on the Runtime Security Policy Node, you can choose "Evaluate Assembly...". This will give you for a given assembly (dll or exe) the permissions currently set for it.
Now you need to tell the framework to trust your assembly. Either you select under the same node "Trust Assembly...". This will trust only the specified assembly and allow it to run (although I'm not 100% sure if it will give all permissions to the assembly).
The best way to do it is to do the following:
Create a new permission set and specify in the permission set the permissions which it should grant.
Create a new Code group and associate it with the new permission set.
In the code group you can specify different options to define to which assemblies it will apply. (e.g. assemblies with a given Hash value, in a specifiy directory etc.) The best way to do it however, is to sign your assembly with a strong name (check google for signing a .NET assembly) and then associate the code group with that strong name. Thus, every assembly you compile with that strong name will be granted to run with your permission set.
In an enterprise, this is probably the best way to do it. You will only have to configure every workstation once. Once your assemblies are signed with your strong name, the clients will always be able to run them.
For easy deployment of the configuration, you can create an MSI from within the .NET configuration panel which will automatically apply specified configurations to the clients (Create deployment package).
I had to do some testing to get it working correctly back when I had pretty much the same problem you have, but once it is all set up, it works like a charm.
For security reasons however, I'd recommand placing the connection string somewhere else. Not sure what the best place is for WinForms applications (as I haven't done a lot of them), but for example in ASP.NET applications, the most secure location is the web.config file. (So my guess is for Winforms that the app.config file would be a place to put it)
Hope I could help you
The problem is permissions with your LocalIntranet zone. You can either set FullTrust to an individual share as shown here, or you can just grant full trust to the entire zone by executing this:
By the way, caspol.exe is located in the %windir%\Microsoft.NET\Framework\v2.0.50727 directory.
caspol.exe -m -chggroup 1.2 FullTrustBy the way, caspol.exe is located in the %windir%\Microsoft.NET\Framework\v2.0.50727 directory.
@DaWanderer:
Yeah, that works too. I'd guess that the .NET configuration tool uses caspol to make its changes.
Though I wouldn't recommend giving FullTrust to a share. Imagine someone in your company puts a malicious .NET assembly on the share and others execute it by mistake. That could have bad sideffects to say the least.
I'd still recommend signing assemblies with a strong name and trust only those.
Of course, you'll need to keep your key file on a safe location, otherwise it's pretty useless.
Yeah, that works too. I'd guess that the .NET configuration tool uses caspol to make its changes.
Though I wouldn't recommend giving FullTrust to a share. Imagine someone in your company puts a malicious .NET assembly on the share and others execute it by mistake. That could have bad sideffects to say the least.
I'd still recommend signing assemblies with a strong name and trust only those.
Of course, you'll need to keep your key file on a safe location, otherwise it's pretty useless.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
