We have a visual studio project to produce a DLL file, and we've now refactored all the sources out into 3 separate projects which produce static libs. This leaves behind the .def file, and some pre and post-build actions related to the dll itself in this project. We'd like to keep the generation of the DLL and all the additional behavior separate from the other projects if we can.
Unfortunately, now when we try to "build" this project, it does not produce a DLL anymore (presumably because there are no sources that reference any of the libs).
I've added /WHOLEARCHIVE:themainstaticlib, but that doesn't seem to be enough.
If it's possible to have a Visual Studio project that JUST creates a DLL from static libs and a def file (and a /wholearchive directive), can someone please let me know how?
Related
I have a legacy project that used to be build in Visual C++ 2005 Express, and it depends on a certain third party DLL. As far as I can tell it doesn't come with a lib or header file.
The project compiles fine in Visual C++ 2005, here is a screenshot showing the DLL visible and browsable in the object explorer. The code can also use it without #include or anything like that, which is pretty weird.
Importing the project into Visual Studio 2019 works as well, the code can still use the DLL and it is listed under both the dependencies and the references:
I now want to achieve the same thing in a new project, but I cannot figure out how to register the DLL as a dependency. Things I found online and tried:
"Just include the header or lib file" doesn't work, I don't have one
LoadLibrary() and GetProcAddress() are awfully contrived and don't seem necessary because it's clearly possible without.
Create your own lib file doesn't work either, dumpbin doesn't show any symbols for my DLL: image
How do I register the DLL as a dependency? And where does Visual C++ 2005 get the list of methods in the DLL from is the first place?
My Visual Studio 2013 SLN looks like this:
Startup.EXE (Refs Core.DLL)
Core.DLL
MyPlugin.DLL (Refs Core.DLL)
MyOtherPlugin.DLL (Refs Core.DLL)
The problem is that it won't compile the two plugin DLLs because there's no link to them from the EXE project. I could include the plugins as references but then the SLN would have to include all plugins rather than just the one or two I'm interested in.
Is there a way to configure the SLN to compile all of the listed DLLs, even when there is no link from the EXE project?
(Update and clarification from comments.)
This means that I could modify the plugin code and press F5, then the plugin DLL will be recompiled. This question is not about getting the DLL loader to see the updated DLLs but just triggering the compiler into action. (Maybe use a post-build=event to copy the DLLs over.)
Visual Studio has historically always included the MFC library as source so you can build it yourself with the supplied makefile. But in Visual Studio 2010 there is no makefile for MFC. So, how can you rebuild it?
There is documentation on MS implying the makefile should be there:
http://msdn.microsoft.com/en-us/library/bs046sh0.aspx
.. so perhaps its an oversight, or perhaps they migrated it to msbuild but forgot to include the mfc msbuild project file.
If anyone has succesfully built a custom MFC based on that in VS2010 how did you build it?
Can the makefile from VS2008 be used with minimal tweaks? Or does anyone have an msbuild script for it?
I'm only interested in a statically linked library to be used with a specific app.
since in the end MFC is a library as any other, you can just create a new project in visual studio and add all MFC source files to it. Set the options to create a static library, set compilation/linker options as desired (eventually based on the 2008 makefile) and you're ready to go.
In VS 2010 express there are a few library projects (dlls) attached to the application project. When building the solution the dlls output to bin/Release/. Is there a way to have the .exe output to bin/Release and the dlls to bin/Release/dll?
This requires either a .config file with the <probing> element or implementing AppDomain.AssemblyResolve so that the CLR can find these DLLs. You'll have a deployment problem too, you have to convince ClickOnce to publish these DLLs. Realistically should only attempt this with the retail edition of Visual Studio so you can create a Setup project.
Fwiw: your customer won't mind that the DLLs are in the same folder as the EXE. I think most actually strongly prefer this. I do.
You could always have a post build event on the application project that copies all .dll files to a dll directory.
However the assembly loader will not be able to find the dll file and you application will not start.
I have duplicate assemblies with different versions. I cannot recompile projects that use old versions of the assembly, so I manually copy the assemblies into a sub directory of my bin folder, then update the web.config with assemblybinding's.
This works fine, but now I am trying to add the old assemblies to the visual studio project so that they will be deployed to the build directory. But, visual studio keeps looking at these assemblies and telling me I have a version conflict! Therefore, I cant compile the project...
You cant have the same assembly referenced twice in one program, even if they are different version, it's just the way visual studio works. You need to reconstruct and recompile the code that references the older assemblies using the new versions of the assembly. This can be done via a reflector, and is relatively easy if you know what you are doing.