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.
Related
I have made an application running on Windows 10 1809. It needs to be run As Administrator and sometimes with command line parameters. One way to do this, would be to run cmd As Administrator, navigate to the folder and run the app with the corrent parameters. Upon starting it creates a logging folder under %APPDATA%\AppName using the built-in functionality of the logging library.
The app has been developed in C#, .Net 4.6 and uses log4net as the logging library, for which the configuration file states:
<file type="log4net.Util.PatternString" value="${AppData}\\AppName\\FileName.log" />
Now I have one user, claiming this wouldn't work for him. The app does neither create the subdirectory (AppName) nor does it create any log files. Since I can't take a direct look at their machine, I'd like to gather some possible reasons for that (also in order to mitigate such behaviour in the future).
On older Windows operating systems I know that running an app As Administrator would sometimes actually run the app with another user account, the admin account. Then the other user's APPDATA folder would be used. I don't know if this could happen on Windows 10 as well, though.
Could there be some kind of misconfiguration on their side?
Also I can't just add workarounds like a FallbackAppender, since it'd have to be discussed with the client.
What could be reasons for an app being able to write to the calling user's APPDATA folder on one Windows 10 machine, but not on another?
IMHO the cause is that the AppData used for logging is in the Administrator folder (you tell us it's run as administrator).
There's not much you can do other than refactoring the app to write the log in a shared folder (eg the app folder itself or "%systemdrive%\ProgramData\your-app-name" folder).
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.
I am working on a task, where I need to create a installer (.msi/exe) which can install my application as an Windows Service. Also, I need to deploy this service from a non-alterable medium (i.e from CDROM). But I have my configuration files in the CDROM which I want to copy them to a local folder on hard drive before hosting the service. I understand there are different ways for creating a installer
1) Using Install shield wizard in Visual Studio
2) Advanced Installers
Which option do you think is optimal for my problem? Also, I am not sure if it is possible to copy configuration files to Hard Drive and leave the dll's on the disk while installation.
Please guide me through the right direction.
I am not totally clear what your real problem is, however, I try an answer:
But I have my configuration files in the CDROM which I want to copy them to a local folder on hard drive before hosting the service
If these files can be integrated in the VS solution, they can be tagged as "Content" (Build Action) and copied to the install location during setup. If you need to be more flexible, you can write a setup extension.
and leave the dll's on the disk while installation
I do not understand this. Which DLLs ?
If you are interested in some tips for creating a sample service with a complete setup, you can check my SO answer: https://stackoverflow.com/a/28853490/4547223
Or look at: http://www.rsprog.de/samplewindowsservice/
You may probably comment you experiences with that and tell us which files do you want to copy to which location and more about the background. I will try to refine my answer then.
I have a program designed to work in XP, but with Windows dropping support for the OS, it's time to upgrade.
The location is in Program Files(x86), so when I run it without Admin privileges, it can't read/write library/assembly files within its folder.
What are my options?
Found this link helpful:
Allow access permission to write in Program Files of Windows 7
Since Vista was released in 2007, UAC has meant that users do not have rights to write to the program files directory, unless the program is run elevated. You need to locate the files that need to be modified somewhere else.
Exactly where those files should be located, I cannot say. Perhaps under the user profile, perhaps somewhere else. It would require some detailed knowledge of how your application operates to give more specific advise. And quite possible your application will need some re-design in order to work well with UAC.
On the other hand, you say that your application can't access library files within its folder. If all you are trying to do is read these library files, there will be no problem, even in modern versions of Windows. It seems plausible that you have not yet fully diagnosed the problem. It seems likely that your application is trying to write to a restricted location. But reading library or assembly files should be fine, even with restricted access under UAC.
So perhaps the problem is not the reading of these library files. Perhaps the problem is that your application is writing to the program files directory, or some other restricted location. You'll need to do a little debugging to diagnose exactly which parts of your application are failing.
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.