I have created a ContextMenu DLL (to dispaly icon overlay and other shell context menus) and register it in my system.
Acutally, since it is a context menu dll, I wish only explorer exe should load my dll. But in my case, applications like 'Thunderbird', 'Process Explorer', 'Visual studio', ... etc are all using my dll.
Is there any way to avoid other applications using my dll. I only want explorer exe to load my dll. Is there a way to check this in my dll ???
Thanks in Advance.
In DllMain you can test the name of exe file which loaded your dll with respoct of GetModuleFileName with NULL as the firts parameter. If a wrong exe try to load your dll the DllMain can return FALSE.
Related
The process executed with the extension does not find the path to the referenced dll.
It was normally used when it was executed with ".exe".
However, after running with the extension registered in the registry, trying to use the dll results in an error that the dll file cannot be found.
If you look at the content of the exception that occurred, the dll in the path of "C:\myfolder\myDll.dll" try to find to "c:\Windows\system32\myDll.dll".
How do I do anything other than put it in the System folder to ensure that the extension-enabled process recognizes the path in the dll ?
It is not possible to put it in the system folder, so another method is needed.
p.s ) When i open a process by right-clicking an icon in the taskbar while the process is floating, the newly opened process also generates the same invalid dll path error.
I fixed it.
it cause that "System.Environment.CurrentDirectory" and "AppDomain.CurrentDomain.BaseDirectory" were different.
so when Application start, Check each directory and change it if it is different.
my case in WPF, System.Environment.CurrentDirectory was Windows System folder.
We are working on a validation script for Kofax Capture 9.0 / 10.0 in VB.NET 3.5.
We know how to create a script using the Admin Module, and how to get it operational.
The problem is that we need to reference a dll, located on a remote machine. (GAC is no option) This dll holds abstract classes we need in each validation script.
Even when putting the dlls locally (copy local), the Validation Module (index.exe) immediately throws the "cannot find reference" exception, even though the project compiled perfectly.
I guess the basic question comes down to: where do we put the dlls, in order for the Validation Module to find them?
The simple answer is to put the dll in the same folder as the application because this is one of the places which .NET will probe when trying to find it. The Validation module is run from the Capture bin directory which will be something like "C:\Program Files (x86)\Kofax\CaptureSS\ServLib\Bin\". This would need to be done on each client using Validation.
If you have a more complicated scenario, you could look implementing the AppDomain.AssemblyResolve Event and using Assembly.LoadFile to get the assembly from a custom location, but the using the bin path is less complicated.
If you end up having further trouble, you can troubleshoot by using the Assembly Binding Log Viewer (Fuslogvw.exe) which can tell you more details about why the assembly failed to load and where .NET tried to search for it. Assembly loading can fail for reasons other than just the path.
For more detail on how .NET loads assemblies, see the following:
How the Runtime Locates Assemblies
Locating the Assembly through Codebases or Probing
We found a solution: add all library files as "links" to the project. (Add --> Existing File --> small arrow next to "Add" --> Add as Link)
This ensures the files are compiled when you build the project. The Kofax Validation Module can now find the files, whereas when referencing the file, it could not. Why it could not, remains a mystery...
I found that:
the dll was detached(process) when I close the window(opend shell namespace externsion), but sometime didn't.
There are some global object in my dll. so, I want to find out when the dll be detached(process).
If you export the DllCanUnload function from your DLL you will be called when Explorer wants to unload your DLL. You can block it if you want, or perform some clean-up before allowing the unload.
I've tried Dependency Walker, but when I run the exe in profile, Dependency Walker froze.
Process Explorer shows all DLLs loaded by application.
Loaded dll in an exe are located in the Data Directory-Import Table section.
Loading the executable in studPE and looking at the "functions" tab will give you the list of dlls.
You could also load the program in OllyDbg and press Alt+E (or menu view->executable modules) to see a list of dll's
I have a COM DLL (say, xyz.dll) coded in VC++. I want to create a calling EXE application (calling.exe) which will call the functions of the COM DLL (xyz.dll).
I followed the steps in the link http://www.codeproject.com/kb/DLL/XDllPt1.aspx.
But I am not able to connect the DLL and EXE and hence not able to call the functions of the COM DLL. I am totally new to COM and VC++ programming. Can anyone kindly help me with.
I am using Visual Studio 2005.
These are the exact steps I followed--------
STEP 1: Created a solution having the DLL project (xyz.dll) project and a caller application Project (calling.exe) of template MFC Application (Dialog based). Made this calling.exe as the startup project..
STEP 2: Went to the properties by right clicking on the calling.exe Project in solution explorer. Configuration properties --> C/C++ --> General--> Additional Include Directives and added the path to the DLL Project..
Step 3: Again Right Click on the calling.exe application Project went to Properties--> Configuration properties --> Linker --> Input --> Additional Dependencies and added the path to the .Lib file for the built DLL Project.
STEP 4: Right click on calling.exe application Project, Properties --> Common Properties --> References --> Added reference to the DLL.
STEP 5: Copied the xyz.dll file to the application project directory.
STEP 6: My DLL has many header files and its corresponding source files. So, Added all the header files present in the DLL Project to my calling.exe application program. Within the OnInitDialog() function present in one of the .CPP program of the calling.exe application, I called the functions of DLL.
Just the statements
Cx objname;
objname.func();
Here Cx is the name of the class in the DLL.
I did not do any changes with the configuration settings of the EXISTING DLL project because it is The DLL which is already prepared by an expert and I am writing just the calling applaction to call the functions present in this DLL.
THANKS IN ADVANCE.
The instructions you've followed are for calling functions in an ordinary DLL, not a COM DLL. To access a COM DLL you need to go through COM.
You don't link to the DLL's lib file or include any headers, and you don't need to move the DLL.
First, make sure the DLL is registered by running regsvr32 on it.
regsvr32 "c:\..\..\xyz.dll" ; insert the correct path
Then add an #import directive to your project's stdafx.h, containing the path to the DLL.
#import "c:\..\..\xyz.dll" // insert the correct path
Right click stdafx.cpp in the file view and choose compile.
This will generate the wrapper "smart pointer" classes you need to access your DLL.
The smart pointer classes have the same names as the interfaces in your DLL, but with "Ptr" on the end.
Look at the file with a .tlh extension and the same name as your DLL in your Debug directory. It begins with a C++ namespace declaration.
This is the namespace in which the objects you are going to create from the DLL reside.
Say the namespace is XYZ and you want to instantiate a Cx object, which exposes the Ix interface.
You would do:
try {
XYZ::IxPtr obj;
obj.CreateInstance(__uuidof(XYZ::Cx));
obj->func();
} catch (_com_error e) {
printf("Error: %S\n", e.Description());
printf("Error: %S\n", e.ErrorMessage());
}
You can then continue to use it just like an ordinary pointer.
You don't delete it when you have finished with it though, it will be destroyed automatically when it goes out of scope.