I have a DLL (and associated station.config file for it's settings) that I wrote in c# and a test winform application to verify its functionality. It works perfect.
When I reference the dll and call it using LabVIEW, my LabVIEW application errors out staying it cannot find the station.config file in c:blah\blah\users\the User logged in ID\blah\someguid location (sorry I can't remember the exact location as its in work and i'm at home now).
I put station.config in the folder and it works fine.
I want it to reside in the same folder as the dll and not any folder to do with the user logged in.
It's compiled in debug mode. Whats going on ?
Your C# code is pointing to the location of the station.config file.
A simple way to fix the issue would be to add an argument to your dll to allow the caller to set the path. You could then place the config file anywhere, use LabVIEW to determine where the station.config file is located and pass the path to your dll.
Related
I am currently developing a program that uses the Ghost Script DLL, by importing it as so:
[DllImport("gsdll32.dll", EntryPoint = "gsapi_init_with_args")]
Now, when I set the project in my solution that uses this directly (located in the directory...\source\repos\uo_test_viewer\omr_scanner\omrmarkengine-master) as the startup project, everything works fine. However, when I change my startup project to a project located in ...\source\repos\uo_test_viewer\UOTestViewer, I get the following error:
The gsdll32.dll wasn't found in the default search path or is not in correct version
(doesn't expose required methods). Please download at least the version 8.64 from the original website.
The only thing that is being changed is that when I set the project that makes this work as the startup project, I am running it directly -- where as with the project that doesn't work, I am creating an object of the form that uses the Ghost Script implementation. Does anybody know what the issue is?
I believe that I have provided all the necessary information, but please let me know if anything more is required. Thank you in advance for your answers!
DllImport looks first in the current working directory, then in the search path (the $PATH) environment variable).
When you start your application in the folder which contains the Ghostscript DLL, then the Windows API call DllImport looks in the current working directory and finds the Ghostscript DLL, so it loads it.
When you start in a directory which does not contain the Ghostscript DLL, then DllImport looks in the Current Working Directory, and does not find the DLL. It then searches the search path, which presumably does not find a Ghostscript DLL, so you get an error.
You either need to be sure the current working directory has a copy of the Ghostscritp DLL, or the DLL is on the search path, or you need to supply a fully qualified path to the Ghostscript DLL in the first argument to DllImport.
In case you are considering distributing this application, please read the AGPL license to ensure that you comply with the terms for using Ghostscript.
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.
I am working on an application where users can develop their own plugins as dll files. They need to put these dll files to a specific path so my application(C++) can load them and run. The problem is, when user develops a dll file depends another dll file and put both files to my dll path, my application can't find second dll file.
Ex:
DllA(C++) depends DllB(C#)
my app loads DllA but can't find DllB and fails.
If user puts DllB into application binary path and DllA to specific dll path, I am able to execute plugin. I also tried to put DllB into various directories such as windows or system32 but it again fails. I also tried to add my dll path to PATH environment variable but no effect.
I am already executing SetDLLDirectory function to load DllA in the specific path. Since I've no control over user code, I can't make them to call this function in DllA code also. My question is that how can I force windows to search my specific dll path?
I am using a managed DLL that referencing an unmanaged dll.
I added the unmanaged dll under /External/foo/ directory, and i changed the "Copy To Output Directory" to always.
The problem is that the dlls are copied to the outputDir/External/foo dir and when the runtime tries to find it, it fails with this error: "Unable to load dll: Module cannot be found"
When i copy it directly to the output dir, everything works well.
How can i set the project runtime to search in the sub directories of the outut dir?
Thanks!
You don't want to do this, DLL Search Hell is something you want to avoid. Windows is pretty inflexible about where it looks for DLLs. Rightfully so, DLL Hell is nothing to mess with. The only good place for unmanaged DLLs is in the same directory as your EXE. If you don't want to store the DLLs in the project directory, so copying them is very easy, then you are going to need a post-build event that uses xcopy.exe to copy the DLL to the output directory.
The alternatives are not pretty. If this DLL is implicitly loaded then the only option is to use an installer to add the directory to the system's PATH environment variable. This is a Really Bad idea, way too easy for your program to break. If it is loaded explicitly, either with LoadLibrary or a pinvoke declaration then you have more attractive options since you can alter the search path in your Main() method before the DLL is needed. Either append the path to your local copy of the PATH environment variable by using Environment.SetEnvironmentVariable() or pinvoke SetDllDirectory(). Do beware that you have a deployment problem as well, somebody is going to have to create this subdirectory and copy the DLL there on the user's machine. All great reasons to not do this.
This is something we did in our last project. Write a batch file which copies this unmanaged dll to the output directory. Call the batch file every time the program compiles. You can control the calling of batch file also using a Config key. So it runs based on the config key value true/false. i hope this helps
Been searching high and low for this one and can't seem to figure it out.
So I'm making a web application in visual studio using c# project. There is another project in my solution, it's a c project that compiles to dll. I've gotten to the point where I can pass information between the two and it's working right.
In my application, the user uploads a file and it is saved to the file system in an "includes" folder. The dll (compiled from c code I got from an sdk) is supposed to read in that file and decode it. The dll project works fine when I compile it as an exe and send it a file path.
My question is, how can I get the DLL (now in the bin folder) to skip back a directory and grab this file? I've tried just hardcoding the file path into the c code but it doesn't work.
FILE *fp;
bool isWorking = false
if(fp = fopen("../Include/testFile.fit", "r"))
isWorking = true
I've also tried just writing to a text file from the DLL, hoping to find where it pops out and use that directory as a reference but the c code isn't creating and saving a file at all in that case.
The position of the DLL file in the file system is not important. The important part is where the resulting binary is run and what it sees as its current working directory.
If your C# program uses the DLL, the code in the DLL will be run with the same current working directory as the C# program (unless you change it in the code in your DLL).
So, you should try to load your file in the same way, with regards to path, as if you were to load it from your C# program.