Is it possible to recompile an MFC DLL while its "client" executable is running, and have the executable detect and pick up the new changes? If it's possible, is it foolish? Being able to recompile the DLL without restarting the exe would save some time in my coding workflow. I am using Visual Studio 2008, code is written in native C++/MFC. My code changes are entirely contained in the DLL, not the EXE.
Thanks!
Unfortunately, unless the executable has support for hot-swapping DLLs, you can't do it. The standard DLL loading mechanism in Windows will load it either at the start of the process or at first use of a function exported by the DLL and will not watch the file for changes in order to reload it. Also, depending on how the DLL is loaded, the file might be locked for changes.
You will have to stop your client executable before recompiling.
Yes, it's possible. You'll need to make sure the executable explicitly loads your DLL (via LoadLibrary). If your executable implicitly loads your DLL you'll have the issues that Franci described.
To update the library while the executable is running:
Define some convention for staging the new version of the DLL. It could be in a separate folder, or with a different file name/extension.
Have a means of checking for a new version of the DLL. This could be in response to some specific gesture in the user interface, or you could monitor the directory for changes from a background thread.
When you see a new version, unload the old version (FreeLibrary), then delete it and move the new version to the desired location and reload it (LoadLibrary).
If your DLL implements any COM objects, let me know and I'll give you some additional tips.
Related
I am trying to build an application file in release mode in Visual Studio 2015. The issue is that I need to use the Multi-threaded DLL run time library option. When I create the application and try to run it on a different computer I get various missing dll errors like msvcp140.dll and vcsruntime.dll. Is there a way to create an application file such that it has everything it needs and can independently run on any computer.
Under "Libraries" you should select
"Debug Multithreaded (/libs:static /threads /dbglibs)" for all your libraries. All the needed dll's will now be linked to your application. The executable will be somewhat bigger, but the application should work on any windows computer. You can use this option for both the debug and the release version. Keep in mind though that you may still run into problems if you're creating your own dll's that depends on other external dll's (which they often or always do). I.e. in order to be safe; do not create your own dll's.
You have to keep dependencies beside the exe(compiled) file. for this job, you can copy them in the exe directory, or set environment variable. Additionally, I suggest using cross platforms libraries, such as QT.
I've been making a program in Visual Studio 2012, what comes with it is that when I send my application to someone, they need the VS2012 Runtime, which sometimes they don't know where to download or what they need (for normal users "xxx.dll is missing" is very misleading).
I know exactly which dependencies my application requires (fantom.dll [Lego Mindstorms stuff] and the VC++ 2012 Redist).
I would like to show a dialog when these libraries are missing on application startup and provide the user with download links for these libraries.
Is this possible to accomplish?
Yeah you could do something like:
Move all of the code in your binary into a DLL.
Create an EXE which dynamically loads the DLL using LoadLibrary and unloads it with FreeLibrary.
If LoadLibrary fails, check if its due to missing DLLs, if so then display a MessageBox/your custom message and exit.
Of course this means your EXE project must NOT depend on the runtime itself - this shouldn't be an issue since you'll only need to call 3 win32 API's.
No it's not possible but you can create an installer for your program. The error is thrown during the loading of your program, before your code execution...
You can try with that : http://www.codeproject.com/Articles/24187/Creating-an-Installer
I can't speak for testing the VS2012 Runtime dynamically, but you can certainly validate fantom.dll dynamically. Instead of static-linking to the DLL directly, you can dynamically load it instead. You can configure your project to delay-load the DLL at run-time, and then provide a delay-load callback handler that the RTL will call if the delay-load fails. Or you can simply skip the delay-load feature and load the DLL yourself manually by calling LoadLibrary() and GetProcAddress() directly.
Sure, you can verify if a dependency exists on the deployed system. A few things come to mind...
You can see if the assembly is recognized on the running system by calling AppDomain.AssemblyResolve() . Further reading here
Another more primitive option is to call a File.Exists(your assembly path here) test, but I would advise against this as it's a bad practice to require hard-pathed installation locations.
That said, and as others have stated, it's still by far the best approach to create yourself an installation distribution.
Assume this scenario: An application (app.exe) is using multiple .dlls. I am debugging a function, bugged_function() from one of the .dlls used by the app: util.dll. While I am debugging bugged_function() from this I realize that something in the code is wrong and changes have to be made.
Steps to perform normally:
1. close app.exe
2. modify code in the function
3. recompile util.dll
4. rerun app.exe
What I want:
Bypass step 1 and 4. To do that I need to unload in some way, if possible, util.dll library so when compiling it can be overridden. The the application must somehow reload the library again.
EDIT 1:
I do not know how bugged_function() is called. Assume that I only have access to the source code of the library util.dll used by app.exe.
EDIT 2:
I am using Visual Studio 2010, and when I debug, I attach to app.exe process.
If the application is using the dll via run-time dynamic linking, it could be unloaded (FreeLibrary or similar), then reloaded (LoadLibrary or similar).
If the application is using the dll via load-time dynamic linking, I think you're out of luck.
Edit: I misread the question slightly. Since you can't modify app.exe, you'll have to rely on built-in functionality of that application for runtime loading and unloading, if it has it. That depends totally on the application.
Visual studio can edit and continue. So if you are at a breakpoint, you can make the changes you need to then continue your debugging. Visual studio will compile and apply the changes while maintaining state.
Edit: fixed edit and continue naming.
My application uses one version of library (a.dll), I am using another DLL(b.dll) which in-turn uses older version of the same library (a.dll) that i use. I am building the application by embedding a manifest file. The DLL i use is also using a embedded manifest file. I am having both the versions of the library in my WinSXS folder. My application is not able to load the appropriate versions of DLLs.
Will having a separate manifest file (not embedding into DLL) help resolving the problem? What is the work around?
Your situation is exactly the situation WinSxS is supposed to solve. It should be working.
Either: The manifest files are pointing to the same version, or one of the manifest files is not embedded properly, or
The shared assembly in WinSxS was installed with a configuration policy that automatically redirects requests for v1.0 to v1.1
Some clarifications are needed: App.exe and b.dll are implicitly linked against a.dll? Or do they load it via LoadLibrary.
If B.DLL loads A.DLL explicitly using LoadLibrary then you need to add ISOLATION_AWARE_ENABLED to your pre-processor definitions to ensure that LoadLibrary calls made by B.DLL look in the correct activation context. Otherwise they will be made in the context of the default activation context which was created by the EXE's manifest.
It will depend on what the duplicated DLLs do and if their versions are compatible. (e.g. Do they both access shared objects in memory? If so, there's a good chance something will blow up.)
It will also depend on how those two same-named DLLs are loaded. If it's anything other than an explicit LoadLibrary with a full path then things probably will not work. There's an ongoing discussion of this here: Determine the loaded path for DLLs
In general, it might work if you're lucky. The fact it may go catastrophically wrong is a good reason to avoid the issue entirely, if you can. (In the worst case, you could host one of the modules in another process and proxy all the calls to it. Ideally, just be able to use the same DLL version in both modules.)
I have a C++ Exe in an application directory which contains the DLLs used by it. Now, for some testing purpose I need to modify an existing DLL and use that instead of the original one. But in order to not modify the existing installation I cannot backup the existing DLL and replace it with the modified one or move the existing one elsewhere. I also cannot change the Exe. The 2 DLLs need to exist side by side. The only change should be that the Exe should transparently load the modified DLL which is in some other folder rather than the existing DLL which is in the same folder as the Exe. Is there some elegant way of doing it?
I looked at some MSDN articles but could not find a way of doing this. The solution should work on Windows XP and up.
Windows will load at most one version of each DLL name per process. If it loads a DLL listed in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs, it won't load a similarly-named DLL later. But in AppInit_DLLs you can list a DLL with an explicit path, overriding the normal LoadLibrary() order.
Hence, temporarily put your test DLL in AppInit_DLLs and it will override any other DLL with the same name.
According to MSDN, it will always start by the application directory (unless you modify it with the alternate search order method...) so it seems to be difficult. You can still copy the executable and its other dependencies elsewhere. It is not that elegant though.
Or you can launch the executable that you have copied elsewhere along with the new DLL, from the original directory. According to the search order it should work too, though I must admit I have never tried.
You can hook LoadLibrary() calls for your process from the beginning. When your patched version of LoadLibrary() sees your DLL's it calls original LoadLibrary() with modified DLL's path.Even if you don't use LoadLibrary() call to load your DLLs, Windows CRT does. So this technique must work.
The only way I know would use LoadLibrary API including the path, but you say you can not change the exe.