Is it possible to attach a flat file to windows-service?
My windows-service uses few flat file (for data purposes). Usually, if it's a normal executable I would place those files in the same directory as exe. How can I achieve that with windows-service?
I've done some research on this, but all I found was:
1. Pass a path to those files as a parameter to windows-service.
2. Make a fixed path and just require those files there
But I don't like those solutions. I was wondering if it's possible to attach those files to the windows service while installing it?
How about adding these files inside the project as Embedded Resources? They won't show up on the disk, but you could still properly read them from inside the assembly itself.
Here's some reference: https://support.microsoft.com/en-ie/kb/319292
You can look up the directory that your application is installed in at runtime, using the Application.StartupPath property from System.Windows.Forms. This works for both applications and services. You should avoid hard-coding the path that you think your application is installed in, because the end user may have installed it somewhere else. You should also avoid using the current directory (i.e., opening the file by name only, without a specific path) because the user may be running your application with a different current directory.
Note that installutil does not make a copy of your service executable. So the service runs from the same directory that it was in when you installed it, and any files you place in that directory should still be there when the service is running.
Related
I want to update my website by extracting a zip file which contains whole files of the website itself. Apparently the system does not allow me to do this as such folders are protected:
Error while extrating: Access to the path
'C:\WebsiteFolder\Website\bin\' is denied.
I also think that changing the dlls will restart the server while extracting. Is there a way to do this? To extract all files then restarts the server after it finishes. Also the web.config might be overwritten while extracting the zip file.
Does putting offline.htm help?
This is because IIS is using files within the bin directory, and the AppPool is likely running as system, or an administrator account.
Stopping IIS (or the app pool) will enable you to replace the files.
I also think that changing the dlls will restart the server while extracting
Yes, it will restart the app pool when you change these files
Everything in Visual Studio seems to lead one to putting data files with the application.The app.config goes there, when I create an .XML data file, there is a Copy to Output property that will automatically copy that file to the exe folder. Howerver, it seems that under Vista and Win7 UAC doesn't want the application to be able to write data to any file in the application directory. So I'm changing my evil ways so that I use the LocalApplicationData folder for files I want to read and write. (I just read the app.config so I'm leaving it alone)
I'm using a VS2010 Visual Studio Installer project to create the installer for this app and I can't seem to find a way to target the folder for my .xml file to the LocalApplicationData folder. I can click on the file and see a Folder property but the dialog only has options for Application Folder, User's Desktop and User's Program Menu. Is there some way to do this in the installer or do I have to write code that checks for the file and copies it over from the .exe folder when it doesn't exist? I figure I'm late to this particular party and there must be a canonical way of handling this.
Also, I'm wondering about debugging, is there something similar to the copy if newer functionality in the build process that will now copy this .xml file automatically over to the LocalApplicationData folder whenever I update it?
The Setup project doesn't expose LocalApplicationData in the Special Folders list. You can use it anyway by doing this:
Add a Custom Folder and set the DefaultLocation property to [LocalAppDataFolder]
I've built a winforms app (C#) that will take a list of file paths, and copy those files (from a different VS solution) to a new location (In a folder the user specifies) in the same directory structure they currently exist on local file system.
I use the Path class, Directory class etc and everything works wonderfully...except when it reaches a file path that points to a DLL.
The DLLs I am trying to copy are a part of the other solution, and that solution is not currently open.
I have tried restarting computer to make sure visual studio isn't somehow hooking into that DLL even after the solution is closed.
The DLL in question can be copied by regular manual means (i.e. copy and paste shortcut).
So short of creating a batch file in the program, and running xcopy on that DLL path, I don't know of a way to get this to work.
From what I have found from google searches (which isn't much on this particular situation), File.Copy() should work..
Any help would be wonderful, even if it is a link to a duplicate question I may have over looked.
Thanks!
-The error message is: The process cannot access the file [insert file path] because it is being used by another process (The path is definitely correct also)
-Just downloaded and tried to search for the DLL name with Process Explorer.. I also ran a similar exe from command prompt to no avail. It claims nothing is using it. That's why I am utterly baffled by this. Also, I just checked the permissions and everything looks great (i.e. Full Control, owner effective permissions)
-It does not handle open files. It basically build the correct src and dest paths and does a File.Copy() on those. How would I go about handling open files? I'm sure I could figure out if it was open, but what would I do it it were open?
It is not complaining about the file you're trying to copy, it is complaining about the file that you're trying to overwrite with the copy. Lots of candidates for that, virus scanners always get very excited about new DLLs, for example. Or it is loaded into a process, the typical failure mode for trying to implement your own auto-updater.
You can rename the target file to make your copy succeed.
Are you in vista or win7? If so, Check your 'User Account Control Settings'. Sometimes this can interfere with .NET security options and prevent file operations that would otherwise work.
As well as Process Explorer, I would use Process Monitor also from Microsoft so you can see what is happening at the point of failure and allows you to see if anything else is accessing the dll.
Possible culprits are
the program you are running,
your antivirus package
a virus.
If the path it is complaining about is the destination path, then is is possible that the path is too long?
Also, when using Process Explorer, make sure you have enabled the option to show details for all processes and not just your own.
I just ran into this issue as well. I tried copying a .DLL from an FTP server to a local directory (replacing the existing one) and for the life of me I could not get it to work. Keeps giving me an 'Access Denied code: 5' Error.
I then realized that the .DLL on the FTP server was not marked as hidden while the .DLL I was trying to replace was marked as hidden.
Once I changed the local one to also be visible. I had no more issues.
So my solution is:
Make sure both files are visible.
Hope this helps someone
I included a text file as output in a WCF set up project.
The text file is correctly located in the same folder with the dll, exe, and config file after the project is installed (C:\Program Files\KLTesting\KLTestApp).
However when the program tries to read it, it looks under "C:\Windows\system32", what's the correct way to find & read it?
I have
string a = Directory.GetCurrentDirectory();
a += "/R0303.txt";
string content = File.ReadAllText(a);
Thanks.
You should use AppDomain.CurrentDomain.BaseDirectory or AppDomain.CurrentDomain.SetupInformation.ApplicationBase instead, to get the Directory of your .exe file.
First you should not call Directory.GetCurrentDirectory() and concatenate with the file name. The service is running within a web server like IIS or some other type of container, so GetCurrentDirectory will not give you what you are thinking as you found out. (On a quick tangent, as a recommendation in the future if you want to do path combining you should use Path.Combine method as it will handle all the corner cases and be cross platform.)
There are a few ways to do this:
Assembly myAssembly = Assembly.GetAssembly(SomeTypeInAssm.GetType());
string fullFileName = Path.Combine(myAssembly.Location, "MyFile.txt");
The fullFileName should be what you are looking for. Make sure you use a type that is actually in an assembly located and referenced from the directory in question. However be aware because this file in your question in the Program Files area this is a secure area on Vista and higher OS's and you may not have access to do anything but read the file.
Also you could have the installer of the application place in the registry the install path. Then your service if on the same box can pull this information.
Also you could make sure the file you want to load is within the web server environment that is accessable to the WCF service in question.
I have an application that contains a sub folder that contain xml file ,that is use as a database now i want take the path of the xml file at run time ,how can i achieve this in window application?
I know how it does in asp.net using Server.MapPath but i want this is same in windows application
please help
thanks in advance .
Use Aplication.ExecutablePath property when am XML document and executable are reside in the same directory.
I think the recommended way in Windows is to use the Application.StartupPath property.
And with Path.Combine you can have your xml file path Server.MapPath-style like this:
var appPath = Application.StartupPath;
var xmlPath = Path.Combine(appPath, "data/my_db.xml");
// xmlPath now points to app-relative data/my_db.xml file
...
A nuanced answer:
The best way to access data would be to put it in Application.CommonAppDataPath or Application.UserAppDataPath so that it does not depend on the application's installed path. However, there are many reasons why you might need to avoid this.
To answer your question:
If the application is a standard forms application deployed to the client's machine by an installer or XCopy deployment, then the path to the executable is Application.ExecutablePath
If the application is Click-Once deployed, then I would not recommend using the above since the app's path is obscured, shadow-copied and put in the sandbox. You can use ApplicationDeployment.IsNetworkDeployed to test for click-once deployment then ApplicationDeployment.CurrentDeployment.ActivationUri to get the URI that the application was launched from. Your app-relative file will be on that web server; you will always be able to download it.
of course in click-once deployent it would be better to tag the file as Data in which case it would be accessible through ApplicationDeployment.CurrentDeployment.DataDirectory
if the application is a web app, then the Application class is useless. In this case you should use Assembly.GetExecutingAssembly().Location This works because currently executing assembly for a web app is almost always in the web app's /bin directory.
For a "portable" assembly where you don't have an installer, and for rare cases where you don't want to use the Application class, use Assembly.GetEntryAssembly().Location This works because it figures out what the entry point assembly is (your application) and uses that location. This is reliable because assemblies that your entry assembly load don't have to be in the same directory as the entry assembly.
You can get the directory of the currently executing assembly using
System.Runtime.Reflection.Assembly.GetExecutingAssembly().Location
from there you can get to your subdirectory.