Is it correct that mydll.dll which is located in the GAC will read mydll.dll.config from the the same path that it is effectively called from? As an example, if myprogram.exe runs in c:\test, all I need do is copy mydll.dll.config into c:\test and all will work OK?
In replies to a similar question, mention is made of setting the location of the config file via code using AppDomainSetup.ConfigurationFile. Given the dll is not a standalone executable, it doesn't have a load event or an entry point so where are you supposed to enter that code. I to presume that I can/must create a public static method that sets the location and that method must be called by my executable before actually using the dll?
Related
I am trying to link a dll to a vba project and I am going nut 'cause it fails to find it even if I am 100% sure of the path (I pasted 100 times the path from the exact position).
I called
Private Declare Function IMB_connect _
Lib "C:\Users\Andrea.GIORDANO\Desktop\API\bin_dynamic\API.dll" _
(ByVal n As String) As Long
But it continues to return me an error 53: File not found.
I don't get what would be the problem that seems so silly...
I tried with all kind of slashes '\', '\', '/', '//': no success.
FYI I linked the same exact dll within a c++ project and in that case worked well so I believe the dll itself is fine...
Your dll is probably dependent on other dlls. You can use Dependency Walker to get the full list of the dependent dlls.
The dependent dlls must be in one of the following (from msdn):
The directory from which the application loaded.
The system directory. Use the GetSystemDirectory function to get the
path of this directory.
The 16-bit system directory. There is no function that obtains the
path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get
the path of this directory.
The current directory.
The directories that are listed in the PATH environment variable.
Note that this does not include the per-application path specified
by the App Paths registry key. The App Paths key is not used when
computing the DLL search path.
If you are running a VBA project, probably Excel.exe is loading your code. This means the dependent dlls of your API.dll must be in one of the directories in the quote above.
Please note that placing dlls in the system directory could affect the functionality of other applications in the system. (read about dll hell).
I have added zkemkeeper.dll reference in vb.net application. It is working in my computer but when i try to run in client computer it does not work. I copied and paste zkemkeeper.dll in system32 folder and also in same folder where exe file is located but still it is not working.
When i try to open the form of vb application which contain zkemkeeper class it gives error.
Sounds like zkemkeeper.dll is unmanaged, COM dll. You probably have to register it using regsvr32.dll. It doesn't matter where it resides, as long as you register it. Would be helpful if you would post the error you get.
And yes here is exactly what you asked for http://www.zktechnology.eu/index.php/faq-category/sdk/registering-sdk
How to use regsvr32.dll http://support.microsoft.com/kb/249873
We are using a really old Intel math library (nsp.dll and family) and it's location must be specified in the Windows PATH variable. Previously we installed these dll's in the Windows/System32 folder so everything was fine. Now we would like to install these dll's in another folder, the reason is we are migrating to Windows 7 and do not want to place dll's in the System32 folder. I found the SO answer as to how to change the PATH variable (thanks for that) and that does work. After installing I checked the PATH and our folder was NOT added to the PATH, I check the reg key and our folder WAS added. But....it appears that when we register our OCX that uses those dll's, the path is not changed yet. When I rebooted the PATH has our added path.
So, it seems I'm in a catch-22, I need to change the PATH and also use the new PATH during the install. Do I need to require a reboot and some how register that OCX after the reboot? Or is there another way?
After the reboot, running cmd as Administrator allowed me to register the OCX in the new folder. But I would like to have the installer do this automatically.
Thanks.
Make sure that you have the following setting in your script:
[Setup]
ChangesEnvironment=yes
This will allow the PATH change to take effect without a reboot.
However it will only affect new processes started by the shell. If you have an existing cmd window, or you try to start the application at the end of the install without using the shellexec flag, it will still see the old PATH.
And double-however: you cannot legally change the path where a COM DLL or OCX file is installed and registered. These must without exception be installed in the location specified by the vendor. Hence you must continue to install it in {sys} anyway. (At least if you're still using system-wide registration. There is an alternative that does let you move it, if you look up "registration-free COM", but it comes with a lot of caveats and is seldom worth the effort.)
Also note that "because Windows 7" is not a valid reason to move something anyway.
I am running Cincom VisualWorks version 7.9.1 in Windows 8. When I open the class browser and view a library class, it fails to display the source, instead displaying an error comment like this:
" ***This is decompiled code.***
This may reflect a problem with the configuration of your image and its sources and changes files.
Please refer to the documentation and the settings tool for help in setting up the proper source
code files."
I have confirmed that the home path is pointing to the correct directory. How can I fix this?
The answer to this question depends on what code you're looking at. In VisualWorks, source code can be stored in a number of different places. For classes that are present in a clean VisualWorks image with no other code loaded, the source is in a file called visual.sou found in the image directory of the installation directory. As you mentioned, you need to make sure the home path is pointing to the correct directory. It doesn't point at the image directory itself but the directory above - for example, it would be C:\Program Files (x86)\Cincom\vw7.9.1 not C:\Program Files (x86)\Cincom\vw7.9.1\image.
For parcels you loaded, the source code is in a .pst file associated with the parcel. For any code you load from Store or write yourself, the source is in a .cha file in the same directory as your .im file and with the same name. If your image is visual.im then your code is stored in visual.cha.
You need to be very careful about the versions of the files you use. The visual.im file is tightly coupled to the visual.sou file and contains offsets into the .sou file. If you're using a visual.im from another version of VisualWorks, those offsets into the .sou file may not be correct and may produce this problem.
I hope this helps.
I have an application that creates desktop shortcuts. To do this I have to reference the Windows Script Host Object Model. When I add it as a reference, it always creates the DLL, Interop.IWshRuntimeLibrary.dll, in the obj\x86\Debug directory, then references itself to it, rather than looking at wshom.ocx. Even if I add reference wshom.ocx it reverts to saving the file in the obj\x86\Debug directory. The problem is if I move my application to another computer without that DLL being present, the program fails to run.
What's the proper way of handling this situation?
Thank you
Your best bet would be to ditch the Windows Scripting Host completely. Here's a link to a method for creating shortcuts without relying on the WSH. It still uses COM though.
http://vbaccelerator.com/home/NET/Code/Libraries/Shell_Projects/Creating_and_Modifying_Shortcuts/article.asp
Here is a class that someone created that you can use:
http://www.msjogren.net/dotnet/eng/samples/dotnet_shelllink.asp