I have a (native C++) visual studio solution with several projects in it, some of them being DLLs. The dependencies of the projects on each other is fed into "Project dependencies". Whenever a DLL is being changed and re-built, regardless of wether this change affects other projects or not (that is, only the implementation and not the declarations are changed), The entire dependency tree from that DLL and up is being re-linked (not recompiled, however) whenever a dependent project is being built or tested as a build candidate, while this is completely unnecessary. If I would run the dependent project from outside VS prior to the whole re-linking proccess, it would run just fine as is.
Since the project is large this whole unnecesarry process takes a significant amount of time. Any way to fix this behavior?
If I understand what you are saying then you've rebuilt a DLL and are complaining that it is relinking anything that uses that DLL?
This sounds correct to me, if you've changed a DLL then you have to relink anything that uses it as it depends on it. I'm aware that you can change the implementation inside a DLL and if you are careful to keep the interface identical then you won't have to relink it, but VC++ like most build tools only goes on change times and the time of the LIB file for it surely has changed so the only safe thing to do is relink.
If you don't want this to happen then you probably need project A to link to fixed copy of the library for the DLL and not the one from the project
Well this is a typical VS behavior, when you "re-build a solution"... to overcome this "Build" the changed component rather than "Rebuilding" it and u should be fine. Or you can unload the projects/DLLs that you know they wont get changed and when rebuilding VS will only build the loaded projs and ignores the unloaded ones.
I'm not sure what you mean when you say "VS re-link and not re-compile", when you rebuild a solution, all projects are compiled and linked according to the dependency tree...
Related
I'm a unix backend dev that has a small roll in maintaining a visual studio project. The vast majority of my code runs on Linux, with a small Windows footprint. There is a proprietary project-specific rule in play here that states all system dependencies must be dynamically linked, but all other dependencies not already installed on the systems, which I thankfully don't control, must be static. In other words, I can use boost, poco, mysql++, zeromq, etc, but those have to be linked statically. I also can't create my own DLLs. My Linux brain is guessing that rule is my Windows problem.
I have a large static library as part of the projects with lots of common code linked into other programs. That static library is compiled /MD, which appears to be what I have to do on Windows to dynamically link system libraries. However, I need that library linked into other programs statically. When I add a reference to the library in VS 2017 to other projects, nothing happens and the symbols aren't resolved and I get lots of link errors. To fix that, I hard-coded my library into the various other projects via Linker->Input->Additional Dependencies and that "works" after a fashion, the code links and runs but VS doesn't resolve the static library dependency. While I can go forward with this solution, it's hardly ideal. Rebuilding the solution always results in failure (or links in old code into a new build) because the big static library always takes the longest and none of the other projects know to wait for that build to complete. The workaround is to build the static library first, then build the entire project.
Does anyone better versed in Visual Studio know the best way to proceed?
Can someone help me understand why this got down-voted? This isn't a troll and I'm hardly a student trying to get someone to do my homework, it's a real problem I'm trying to figure out in a professional setting. I thought that was the whole point to stackoverflow?
So this was something simple. When I went to add the reference I didn't actually click on the check box. Robert Andrzejuk's second comment helped, I had read that before but didn't notice the little check box the first time.
On the add a reference page (right click project in solution browser, Add->References...), the check box next to the item has to be selected.
Add reference widget
I've done some searching and seen questions similar in nature to mine, but none that quite hit the nail on the head of the issue I'm having.
I'm making C++ game in Visual Studio (with the Allegro 5 library) and encountering difficulty running it on other computers. I'm well aware of the 'MSVCR##.dll is missing from this computer' issue, but what I'm wondering is why I'm unable to run my Release build because I'm missing the MSVCR##'D'.dll on a certain computer, when I was under the impression that the 'D' suffixed .dll was exclusively required for running the debugger. I've checked in my configuration manager for release build settings and I have 'Generate Debug Info' set to No, which I thought was the only thing I needed to do. My question I guess is whether or not there are any other settings I need to configure to make sure my Release build isn't looking for the MSVCR##D.dll. Thanks in advance anyone who has any info!
You're a bit confused about the use of the *D libraries. They're indeed used for debug builds, but debug builds differ in multiple ways from release builds. For starters, debug builds by default come with a *.PDB file that contains all the function names (This is your "Generate Debug Info" option). A debugger looks into the .PDB file to find a readable name for a crash site.
Another debug option is to not inline code - this keeps your named functions intact. Inlining may put that single finction inside three other functions, which complicates debugging a bit.
Finally the Debug CRT includes functions that perform extra error checking against bad arguments. Many functions exhibit Undefined Behavior when passed a null pointer, for instance. The Debug libraries will catch quite a few of those, whereas the Release versions assume you pass valid pointers only.
Now DLL's can reference each other; there's a whoel dependency graph. That's why the Dependency Walker tool exists: it figures out which DLL's rqeuire which other DLL's, and this will tell you why you need the *D version.
Thank you very much for all your inputs, I was able to learn a fair bit from this. It turns out the issue was (of course) entirely my fault, as when setting up the Allegro 5 dependencies in the project settings (under General->Linker) I was accidentally including a dependency for the debug version of the Allegro monolith-md.dll as well as the non-debug version in my Release build, and that .dll was in turn referencing the *D version of the MSVCR .dll. The issue has been resolved by removing that dependency from the Release build of my game.
Install dependency walker on that machine. Load the exe. Check if any of the dependent dlls are missing.
I have a C/C++ solution comprised of several projects in VS2010. The start-up project is where main() locates and it will generate .exe file, while the others are core algorithms which will generate .dll files. When I debug the whole solution, sometimes it cannot go into the .dll projects but after rebuilding the whole solution, the problem can be temporarily solved; However after building one or more times, the problem returns.
Currently I have to rebuild the whole solution every time I modify the code, but it's so bothering. Is there any way that I can avoid such a problem?
It is happening only in the case when some project in your solution is changed or the .exe present in release or debug directory is different from the code. So, make sure like you are building each project successfully after modifying it.
And it is always good to debug in DEBUG mode to get exact result.
Everal things you could try: Make sure all projects which need to be rebuilt after a change indeed are. So make sure the project dependencies are set correctly and that the startup project is the exe project.
As second option, you could allow the debugger to show source even if it does not match the code exactly (look for something named "source files must match original exactly" or similar in Options->Debugging->General). Be aware that it might indeed happen that your changes are not reflected in the program if this is needed.
I am starting to learn DX11 and running into trouble with the effects framework. I know it was released as source and I have to build it, but the output from the build is not what I expected.
According to the research I've done on this question, the output from the build should be
D3DX11EffectsD.lib for debug
D3DX11Effects.lib for release
However, when I look into the 'Effects11\Debug' directory after building the project, I only see a file Effects11.lib (well, an Effects11 Object Library file which I assume is a .lib, I'm new to c++), and the exact same file in 'Effects11\Release'. Whats going on here? I've never used VS 2010 for c++ before now but I think I am building the solution correctly.
Is this a matter of renaming the files or have I done something wrong without realizing it? There really isn't much documentation on building and linking libraries in vs 2010 that I could find. Anybody have any suggestions?
Thanks
If you compiled exactly what you got off the web, then I think it would be just a naming convention problem.
You should try compiling it into your end application and see if it yells about debugging symbols missing.
You can also go into the build settings (it has been a while since I have used visual studio for anything other than C# so I don't know exactly where that menu option would be (I assume right clicking on the project should yield some useful results)...I generally do my C++ stuff on linux) and check to see what the built targets are for debug and release. If it turns out that the names are the same for both, but the build targets (i.e. the folder and a few other options, like including debugging symbols) are different then you should be good and it is just a naming problem.
Also, if the files are the exact same size it is likely that they are the same since the debug file should be at least a bit larger than the release one.
If it turns out that they are the same file, try re-downloading or re-extracting the source and just compiling the project again without any changes and see if that gets any results.
In one Solution, I have two VC++ projects. Project A has linker inputs that are .obj files compiled by project B.
Visual Studio (2008) always tells me that project A is "out of date," and prompts me to ask if I want to rebuild it, every time I want to run/debug/build/etc. Even immediately after building the entire Solution: I do a successful full build, and then click Build again, and it wants to re-link Project A.
How can I prevent this from happening? Anyone understand what's going on here?
I think that the solution is to stop using .obj files from the other project. Instead, factor the code that is common to both A and B projects into own static library C and link both A and B to it.
I just had this problem with Visual Studio 2010 (both with and without SP1) and thanks to Ted Nugent I was able to fix it. The trick is to check whether all C++ header files listed in the project still exist, and remove the non-existing ones. Apparently this is a bug in the compiler.
Had something similar occur. I was working with code that used the system time and during the debug I was twiddling with it quite a lot. Somehow the files got some bad timestamps. In the build, it shows which files are getting recompiled, so I just opened each, forced a change (add space, delete a space) and then re-saved.
Similar to the old unix "touch".
In one project I had to do the same to its include files. But after 'touching' the files like that, the problem went away.