When I run a console app in Visual Studio and open files on my workstation everything runs fine. When I run the same app in Visual Studio and open files on a network share I get an "Access to the path 'xxx' is denied".
I have access to the files in both locations. Does the console app not run as "me"?
As an admin you indeed have access to almost everything on the system. Applications and normal users do not however, especially over a network. This is a security feature of most modern operating systems.
For the sake of example, suppose you wanted to access a file in C:/Users/Vance/ (on the target machine). You can't access that or anything else remotely except C:/Users/Public/, until the necessary permissions are set.
See this to learn how to share folders over your local network.
Im not running the exe directly.
The networked machine still needs permission to execute programs remotely on the target machine.
If it's still not working after setting the correct permissions, your firewall is probably blocking the network traffic. In this case you'll need to add a rule to allow it through.
Related
I've written a c# application which is intended to be ran on multiple computers within a network. The problem im trying to figure out is how I can share some common files between all the computers within the network.
I was handling this before by installing the software on one computer, storing a path string as an application scope setting during install, and then creating exe shortcuts on all other computers in the network which point back to the original installs exe.
Application deployment to network drive
I read this link and they talked about how it would be better to use clickonce rather than using a network share. The network share was the only way I could think of to have a common files directory. Are there any other ways to accomplish this?
Part of the installation process should ask the user for the path where the shared files will go. As long as each user enters the same path your good. That's the trick...
One way to solve that is to provide a silent installer mode that can be run with a preset of values the installer will need. You can then push the installer via group policy to all of the machines in your network.
I'm not sure what installer tech you are using, but WIX will create MSI's that support silent installation.
I have an application which I deploy using a setup program in Visual Studio 2010 on Windows 7. The program deploys and runs fine on Windows 7 and XP, but when I deploy it on a Windows 8 system I get errors about access to a configuration file.
The program gets installed in c:\Program Files (x86)[Company Name][App Name]\ and the file being referenced is a temp file with a name that looks machine generated by Windows GetTempFile, e.g. x4q0toqw.tmp. which does not exist in this folder and then there is a reference to the exe config file (myapp.exe.config, which does exist)
If I build and run the code on the Windows 8 system it installs and runs fine, I don't get the error, but then if I deploy the Window 8 compiled app on Windows 7 I get the same errors about access to the configuration file. Both machines are 64-bit but generate a 32-bit application.
I don't plan on releasing two binaries. Can anyone tell me what is going on? I'm in the process of trying to setup JIT debugging to that I can attach to the exe when it throws exceptions, since debugging it natively doesn't help me as I don't get the exceptions.
This is on two different machines, but I login to the same domain as the same user on both, and am an administrator.
Maybe your application is rewriting your app config during the load and this will cause the system to question the access grants... if so, may be you can change the properties of your application (the installed one) to have administrator rights... This will give your application to automatically have the right to programatically edit the app config.
OR... you can just forget about the app config rewriting and put everything in the default app config script. but this will expose your application database security...
I had the same error. This is because the temp file gets created in C:\Program Files (x86)\[Company Name]\[App Name] folder and the normal Users (PC Name\Users) don't have the permission to modify this folder. As soon as I added modify permission, it started working fine.
I resolved a very similar problem in Visual Studio 2010 on Win 7 by elevating the account privileges that my service ran under. See step 9 here:
Set the Account property to LocalSystem.
When my serviceProcessInstaller1 ran under LocalService account I got an error like yours. But changing the account to LocalSystem fixed this issue. My installed service was then able to write to its C:\Program Files (x86)\[Company Name]\[App Name]\[App Name].exe.Config file. This was even though the install for Just me checkbox was checked when I ran the service's setup program.
Bear in mind the remarks here though:
The LocalSystem value defines a highly privileged account, but most
services do not require such an elevated privilege level.
I have a program that needs to create a text log. In XP, everything worked just fine, but when I tested it on Windows 7 - and was later Upgraded to Windows 7 for my Dev Computer - I get an error that "Access to the path 'C:\Program Files (x86)\Ludlum Measurements, Inc\LMI Universal Software\UniversalLog\' is denied". I get the a similar error if I have the installer create the folder and then try to create a text file in the folder.
I know this has something to do with permissions, but what should I give permission and how?
The programs that use the logging function?
The folder that the logs go into?
The folder the programs are in?
And how would this fix work under XP, Vista, Server 2005, and Server 2008 and as service (Part of the program runs as a Windows form, and part as a service)?
-Edit-
Emphasis added.
To reiterate: How will this work when installed and ran on an XP? A Server 2003? A Server 2008? Will this cause any problems for them?
And a new question: Can my program access files from the ApplicationData file? I just remembered the entire problem stemmed from me trying to create a config file that holds connection information for to an SQL database. Hitting your head against a brick wall for a day tends to make you forget why you started doing it in the first place. And again, this originally worked in XP, Server 2005, and Server 2008.
You should use Environment.GetFolderPath and pick a Environment.SpecialFolder folder that has write permissions when the UAC is on and write your log files there.
By default under UAC you donot have permissions to write to C:\Program Files or its subfolders.
Environment.ApplicationData is usually a good choice, it will be writable by default on XP , Vista , Server 2005 and Server 2008 unless the admin has locked stuff down too much
Teach Your Apps To Play Nicely With Windows Vista User Account Control is a good resource on how to write an application that behaves nicely under UAC
You shouldn't write anything to the Program Files directory after installation unless you are actually patching your application. Day-to-day usage of files should go into the application data folder (LocalApplicationData for non-roaming data and ApplicationData for roaming data).
string path = Environment.GetFolderPath(
EnvironmentFolders.SpecialFolders.LocalApplicationData)
http://msdn.microsoft.com/en-us/library/system.environment.specialfolder.aspx
Duplicate:
Why does my .NET application crash when run from a network drive?
Can someone help me? For a school project, I wrote a C# windows application in Visual Studio 2005. It works just fine, no problems. I want to be able to share this program with others in my department at work. So, I copied the exe file to a network drive. When we attempt to run the exe from the network, it fails with "name of progrm...has encountered a problem and needs to close". If I have the co-worker copy the exe file to their c:\ drive then attempt to run, it works. Why won't my program run from the network drive?
Susan
.NET by default does not allow applications to be run off a network drive. Either copy it to a local drive or alter the security settings for .NET.
This discussion should give you what you need.
Microsoft has finally realised that the default behavior of preventing applications from running off a network drive is wrong. From The .NET 3.5 SP1 download page:
"Additionally, managed applications that are opened from network shares have the same behavior as native applications by running with full trust."
This change is long overdue: there is virtually no security benefit in preventing managed applications running from a network share, since a hacker could just as easily use an unmanaged application.
Our company uses Citrix to remote into a terminal server for remote users to launch smart client apps within a virtual window on their machine.
The problem is that smartclient apps are being downloaded each time the user launches them eventhough the version on the remote citrix server has not change. This is due to the user's profile being purged each time they close their Citrix session.
Is there any way to avoid this and still continue to purge the user's profile? Not purging the profile leads to wasted space on the citrix servers and corrupt profile issues.
I can't speak to details on Citrix servers. However, with ClickOnce you have no say over where an application is installed. It's installed under the user profile, no ifs, ands, or buts. One of the major goals with ClickOnce was improved security and installing apps to the profile makes that easier. So, if you're clearing the profile, you're stuck.
However, couldn't you just deploy the app to the Citrix server without ClickOnce? Most .Net apps can just be xcopy deployed, so it seems it would be pretty easy to write a few batch files to copy the latest deployment to your Citrix server and skip ClickOnce all together.
The way to do this in the Citrix environment is to use the Citrix URL Content redirection feature (in Feature Release 2) to redirect the ClickOnce URL to the local machine (http://xxx.xxx/myapplication.application). This will cause the browser window to open on the local machine and not on the Citrix machine. Once this happens, ClickOnce takes over and installs on the local user's machine, instead of inside Citrix. Executing locally will still give you all the normal ClickOnce benefits.
You don't want to install inside Citrix due to the problems in codeConcussion's answer. Plus, ClickOnce doesn't support mandatory or temporary profiles, which is probably what the user has inside Citrix.