Search Results

Search found 4 results on 1 pages for 'setdlldirectory'.

Page 1/1 | 1 

• How might one cope with the ambiguous value produced by GetDllDirectory?

  - by Integer Poet

  GetDllDirectory produces an ambiguous value. When the string this call produces is empty, it means one of the following: nobody has called SetDllDirectory somebody passed NULL to SetDllDirectory somebody passed an empty string to SetDllDirectory The first two cases are equivalent for my purposes, but the third case is a problem. If I want to write save/restore code (call GetDllDirectory to save the "old" value, SetDllDirectory to set a "new" value temporarily, and later SetDllDirectory again to restore the "old" value), I run the risk of reversing some other programmer's intent. If the other programmer intended for the current working directory to be in the DLL search order (in other words, one of the first two bullets is true), and I pass an empty string to SetDllDirectory, I will be taking the current working directory out of the DLL search order, reversing the other programmer's intent. Can anyone suggest an approach to eliminate or work around this ambiguity? P.S. I know having the current working directory in the DLL search order could be interpreted as a security hole. Nevertheless, it is the default behavior, and my code is not in a position to undo that; my code needs to be compatible with the expectations of all potential callers, many of which are large and old and beyond my control.

  Read the article

• Calling 32 bit unmanaged dlls from C# randomly failing

  - by Bert

  Hi, I'm having an issue when calling 32 bit delphi dll's from c# web site. The code generally runs fine, but occasionally I get an error Unable to load DLL '': The specified module could not be found. (Exception from HRESULT: 0x8007007E). This issue persists until I recycle the app pool for the site, and then it works fine again. On the same server, there is also a web service that is calling the same set of dlls. This web service doesn't seem to have the same issue that the web site has. Both applications are using .net framework 3.5, separate app pools on IIS. Here is the code I'm using to wrap the dlls: public sealed class Mapper { static Mapper instance = null; [DllImport("kernel32.dll")] private static extern bool SetDllDirectory(string lpPathName); private Mapper() { SetDllDirectory(ConfigManager.Path); } public static Mapper Instance { get { if (instance == null) { instance = new Mapper(); } return instance; } } public int Foo(string bar, ref double val) { return Loader.Foo(bar, ref val); } } public static class Loader { [DllImport("some.dll", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Unicode, EntryPoint = "foo")] public static extern int Foo(string bar, ref double val); } Then I call it like this: double val = 0.0; Mapper.Instance.Foo("bar", ref val); Any ideas as to why it would "randomly" Unable to load DLL '': The specified module could not be found. (Exception from HRESULT: 0x8007007E). The other problem is that I haven't been able to replicate the issue in the development environment. I thought that due to 2 applications calling the same dlls, that there could be some locks occurring. To replicate this, I created an app that spawned multiple threads and repeatedly called the 32bit dlls, and then used the web site to call these same dlls. I still couldn't replicate the issue. Some possible fixes that I can think of: Wrap the 32 bit dlls in web service (because the webservice doesn't seem to suffer from the same problem). But this may be worthless if it turns out that the web service also fails. Set up state server for the session state and periodically recycle the app pool for the site.This isn't fixing the problem, only avoiding it. Wrap the dll's in exe, and call that exe. Then I shouldn't get the same issue. But this also seems like a hacky solution. Implement the mapper class differently ? But how else should I be doing the call? The other draw back is that other applications are using this mapper, so I'd need to change there code too. Thanks

  Read the article

• Application Specific Paths for DLL Loading when DLL is loaded dynamically

  - by MartinHT

  Hi: I am building a program that uses a very simple plugin system. This is the code I'm using to load the possible plugins: public interface IPlugin { string Name { get; } string Description { get; } bool Execute(System.Windows.Forms.IWin32Window parent); } private void loadPlugins() { int idx = 0; string[] pluginFolders = getPluginFolders(); Array.ForEach(pluginFolders, folder => { string[] pluginFiles = getPluginFiles(folder); Array.ForEach(pluginFiles, file => { try { System.Reflection.Assembly assembly = System.Reflection.Assembly.LoadFile(file); Array.ForEach(assembly.GetTypes(), type => { if(type.GetInterface("PluginExecutor.IPlugin") != null) { IPlugin plugin = assembly.CreateInstance(type.ToString()) as IPlugin; if(plugin != null) lista.Add(new PluginItem(plugin.Name, plugin.Description, file, plugin)); } }); } catch(Exception) { } }); }); } When the user selects a particular plugin from the list, I launch the plugin's Execute method. So far, so good! As you can see the plugins are loaded from a folder, and within the folder are several dll's that are needed but the plugin. My problem is that I can't get the plugin to 'see' the dlls, it just searches the launching applications startup folder, but not the folder where the plugin was loaded from. I have tried several methods: 1. Changing the Current Directory to the plugins folder. 2. Using an inter-op call to SetDllDirectory 3. Adding an entry in the registry to point to a folder where I want it to look (see code below) None of these methods work. What am I missing? As I load the dll plugin dynamically, it does not seem to obey any of the above mentioned methods. What else can I try? Regards, MartinH. //HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths Microsoft.Win32.RegistryKey appPaths = Microsoft.Win32.Registry.LocalMachine.CreateSubKey( string.Format( @"SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\{0}", System.IO.Path.GetFileName(Application.ExecutablePath)), Microsoft.Win32.RegistryKeyPermissionCheck.ReadWriteSubTree); appPaths.SetValue(string.Empty, Application.ExecutablePath); object path = appPaths.GetValue("Path"); if(path == null) appPaths.SetValue("Path", System.IO.Path.GetDirectoryName(pluginItem.FileName)); else { string strPath = string.Format("{0};{1}", path, System.IO.Path.GetDirectoryName(pluginItem.FileName)); appPaths.SetValue("Path", strPath); } appPaths.Flush();

  Read the article

• Avoiding stack overflows in wrapper DLLs

  - by peachykeen

  I have a program to which I'm adding fullscreen post-processing effects. I do not have the source for the program (it's proprietary, although a developer did send me a copy of the debug symbols, .map format). I have the code for the effects written and working, no problems. My issue now is linking the two. I've tried two methods so far: Use Detours to modify the original program's import table. This works great and is guaranteed to be stable, but the user's I've talked to aren't comfortable with it, it requires installation (beyond extracting an archive), and there's some question if patching the program with Detours is valid under the terms of the EULA. So, that option is out. The other option is the traditional DLL-replacement. I've wrapped OpenGL (opengl32.dll), and I need the program to load my DLL instead of the system copy (just drop it in the program folder with the right name, that's easy). I then need my DLL to load the Cg framework and runtime (which relies on OpenGL) and a few other things. When Cg loads, it calls some of my functions, which call Cg functions, and I tend to get stack overflows and infinite loops. I need to be able to either include the Cg DLLs in a subdirectory and still use their functions (not sure if it's possible to have my DLLs import table point to a DLL in a subdirectory) or I need to dynamically link them (which I'd rather not do, just to simplify the build process), something to force them to refer to the system's file (not my custom replacement). The entire chain is: Program loads DLL A (named opengl32.dll). DLL A loads Cg.dll and dynamically links (GetProcAddress) to sysdir/opengl32.dll. I now need Cg.dll to also refer to sysdir/opengl32.dll, not DLL A. How would this be done? Edit: How would this be done easily without using GetProcAddress? If nothing else works, I'm willing to fall back to that, but I'd rather not if at all possible. Edit2: I just stumbled across the function SetDllDirectory in the MSDN docs (on a totally unrelated search). At first glance, that looks like what I need. Is that right, or am I misjudging? (off to test it now) Edit3: I've solved this problem by doing thing a bit differently. Instead of dropping an OpenGL32.dll, I've renamed my DLL to DInput.dll. Not only does it have the advantage of having to export one function instead of well over 120 (for the program, Cg, and GLEW), I don't have to worry about functions running back in (I can link to OpenGL as usual). To get into the calls I need to intercept, I'm using Detours. All in all, it works much better. This question, though, is still an interesting problem (and hopefully will be useful for anyone else trying to do crazy things in the future). Both the answers are good, so I'm not sure yet which to pick...

  Read the article

1