Help running a .NET 2005 executable on a network share? Trying to useClickOnce

[baydart99]

Hi I recently installed VS 2005 and have been awoken to the world of
it's security. Previously of course my users, all part of are
organizations network, could run executables from a Network Share.
When I tried running my new VS 2005 .Net version from the share I got
an exception on Exception on
System.Security.Permissions.FileIOPermission.

I read some forms, and they suggested ClickOnce, which is causing
problems that maybe you could help me with:

1) How I can pass a parameter to the executable? All I see is a Run
button. For different users I would want to pass a different
parameter.

2) I have an XML configuration file in the same directory as the
executable that the executable needs to read in. However when I try to
grab it in my code, e.g. Dim currExecutablePath As String =
Application.StartupPath it trys to read from the users path
information. Is there a way around this.

3) I also want to be able to run this program from a scheduled task on
the server, but I see no executable was deployed when I published from
VS 2005 to my share?

Thanks

 

[Jonas Nordlund]

Hi!

On this question, you may wish to try using this as a "replacement":
Dim exePath As String =
System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetEntryAssembly.Location)

I'm not sure what Application.StartupPath relies on internally actually, but
the code above should look at the starting assembly (which should be the exe
file) and get its location. I've found this method to be more robust as I've
run into similar problems as you when developing a .NET service. This always
returned the \Windows\System32 directory, because a service runs as user
SYSTEM, and not the service's home directory.

Another related call is:
Dim exePath =
System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location)

However, note the difference here with GetExecutingAssembly() instead of
GetEntryAssembly. If your code running would have been a .NET DLL here for
example, it would have returned the DLL's location, which may not
necessarily be the executable location. So the first example is probably
more reliable when trying to retrieve the EXE path.

I hope this helped somewhat.

/ Jonas