My .exe contain a lot dlls added through reference or as .CreateObject .
I wonder is there any way when i open some dll to find in processes or somewhere else which .dll is currently in use
Just use Process Explorer from sysinternals by truning on View->Lower Pane View->DLLs (Ctrl+D) and then clicking on your application process in processes list.
With Find->Find Handle or DLL (Ctrl+F) you can search for DLLs and other files being open by any system process, e.g. when you need to delete a data files but the OS refuses for file being in use reason and not telling you which one the culprit is.
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.
I am working on a application built in VB.Net that allows a document to be uploaded and saved into a database. I did not build this application, but I do maintain it, put enhancements in it here and there. The target framework is .Net4
One of the functionalities within this process when uploading and saving the document it uses the method File.Open() to access the file and run other methods to compress it. The method that uses File.Open takes in a parameter that passes just the filename, not the entire path of where it came from.
When this application is running on an x64 machine I receive an error (System.IO.FileNotFoundException) when the code hits the File.Open method, complaining that it cannot find the file to open. It is expecting the file to be in the programs executing directory, which does make sense because it is only given the filename to go off, not the entire directory that it came from.
What's getting to me, is that this exact same application (exact same built assemblies) will run fine when run on an x86 system. It does not fail on File.Open() It still passes just the filename, but somehow, it will know the directory information.
How is this possible?
It's worth noting, that the method that contains the File.Open() method is in a different project in the same solution. It's a referenced DLL. e.g. MyApp.exe (Windows Form Application) references MyUtil.dll (Class Library). I have built against x86, x64 and AnyCPU configurations.
I understand that the fix to this would be to just pass the entire directory to the method, but what I need to know is how this is even possible? I want to better understand why this would happen, and hopefully this would help someone else better understand how assemblies may differ between different system environments.
EDIT: Using an absolute path did fix the underlying issue. See the comments below for some good information on this scenario
Windows has special handling for certain folder names on 64bit systems depending on whether you have a 32bit or 64bit process. Notably, the Program Files folder and the System32 folders map differently depending on what kind of process you have.
Note that this is a difference in Windows itself. It's not a behavior that is unique to .Net or Visual Basic. Any program platform that uses Windows native file handling will give you these results.
This is why you should use appropriate relative paths or the SpecialFolders enumeration, rather than hard-coding full path names, and be careful about where you put things you expect to reference later; you might find they end up in a different location than you expected. Often, the AppData or ProgramData folders are the more correct location, instead of the Windows or Program Files folders.
I send a Racket executable(in a distribution package) to a few friends and they get the error:"Failure: can not load the DLL". On my computer it runs without problems. It's using the rsound package.
Yes, good point. Currently, rsound is hard-coded to look in the collection path for the DLL. That won't work for programs compiled into executables. I've just updated rsound to tell it to look in "standard locations" as well for Windows and Mac.
Try this: Using the DrRacket package manager, update your copy of portaudio. When you're done, it should be at version "b9403a6dfbfb5eadf824ed91731ec141bf363677".
After this, it should be possible to pass along the executable file and run it, as long as the two required dll's are in the same directory as the executable. These two dll's are:
portaudio.dll
callbacks.dll
For windows, you'll find both of these in a subdirectory of the portaudio package. Finding these is going to be a teensy bit of a hassle on Windows; I believe these get installed in your user directory\RoamingData\\portaudio\lib\win32\x86_84\3m\ . If the target computer is a 32-bit machine, you'd substitute 'i386' for 'x86_64' in that path.
I know that Windows can make it quite hard to find the files you're looking for; let me know if you have any trouble.
Whew!
I have two use cases: 1) loading a temporary DLL during a custom action and 2) executing a temporary EXE from a custom action. The custom action DLL is unmanaged C++. I cannot figure out how to get this working correctly. Including the DLL is easy enough but LoadLibrary is failing as it cannot find the DLL. I also cannot seem to get the physical path of the extracted DLL in order to specify full path in LoadLibrary. Any help is appreciated. I'm using WIX btw for this work.
If you have included the dll and the exe in the Binary Table of the msi, the files will be physically present in the %Temp% folder of the currently logged in user which gets mapped to SUPPORTDIR property of Windows Installer.
You need to use MsiGetProperty to get the SUPPORTDIR and use that in the LoadLibrary.
One thing to remember - Windows Installer usually extracts files from Binary table to %TEMP%, however - the current work directory is often set to c:\windows\installer.
My suggestion - extract the temporary .dll from Binary table yourself when you need it. This gives you the control of when it's saved to. Just remember that you need write permission to the location, so usually some subdir of %temp% is the best choice.
I just finished building my program, but I noticed that vb.net (2010) creates two dll files ( AxInterop.WMPLib.dll & Interop.WMPLib.dll ), when I tried to run the application without having those two files in the same directory, it crashed right away!!!
Is there a way, to have the WMV components running without using any additional libraries, so I can distribute the exe file only?!!!
Thanks
I used a program called smartassembly, to protect the source of my program.
The program itself asked me if I want to merge dependencies (resources), so I picked the two dll files, and it me out one executable file, with no dll files at all.