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.
Related
I'm on a BizTalk 2013 solution and I'm trying to grow into automated testing. However, when I try to run my tests after changing only the test project, or even just run the tests after changing nothing anywhere, I'm stuck building the same amount of projects that I build when I invoke a full rebuild on the project being tested. This eats up an enormous amount of time, and it's a death sentence for my ability to sell future investments into this type of thing.
Is this is a known deficiency with BizTalk, or with its interaction with MSBuild? Is it a known pitfall that I can repair on my end?
EDIT: After reviewing the "possible duplicate" thread, I believe this question to be similar, but distinct. The explanation from the thread highlights the mechanics by which MSBuild determines that a rebuild is necessary, but MSBuild is widely-used technology across all projects in Visual Studio and can differ significantly by project type based on that project type's specific targets import. I've edited the question title to reflect that I want to learn how to prevent this for BizTalk solutions rather than simply asking why it's happening (although knowing why is always helpful).
So, what you're seeing is not a problem with BizTalk (because BizTalk is perfect and wonderful and never has any problems ever...:).
It's actually a behavior of Visual Studio. To note, BizTalk Projects are just specialized c# Projects.
The best workaround, which I do all the time, is to uncheck the Build and Deploy options for Projects I'm not actively working with in the Solution Configuration. If the Project is not checked for Build, it will not build even when you choose Rebuild Solution.
One possible solution would be to reference not the projects, but the DLL files which are the result of the same - already compiled and built - projects.
This way, when building your test project, it would be built against these existing assemblies and hence would not take the time to rebuild those.
You have to make sure however that these DLLs are updated whenever the project behind them also updates. You could do this by rebuilding them, whenever necessary, in a separate Visual Studio instance.
It takes some practice and thinking to make sure you are building against the latest version, but it WILL save you a lot of time.
I've noticed this as well. Turning on diagnostic output on MSBuild, it turned out that the project settings .user files were being modified after the .pdb files. I've tried several ways of resolving this, including changing the modify date on the pdb file, setting the .user file to readonly, removing (renaming) the .user file, etc.
Unfortunately, the build task for BizTalk will overwrite/recreate/create new .user file after every build, and I haven't come up with a way to convince MSBuild that that it can just ignore the .user file being created as new. Due to that, I'd go with one of the other suggestions here.
Even creating an exclusive lock on the file so that MSBuild can't update it causes a rebuild, since then MSBuild thinks the build is dirty ("Project 'Schemas' is not up to date. Project dirty in MSBuild.")
What should I do?
Basically, I want to commit my Visual Studio 2012 project, but it has a Debug folder in it that we traditionally don't commit. Only problem is that the Debug folder has the project's dll in it, and if I move the dll to the folder's parent, the project no longer compiles.
So here's the structure:
Project Folder > MSVC_2012 > Debug folder, sln file, etc.
And in that Debug folder is the dll. How do I move that out of the Debug folder into MSVC_2012?
Your question isn't entirely clear on details, but here are some options (and ways you could improve the question):
Your question looks like an XY problem. You stated that "if I move the dll to the folder's parent, the project no longer compiles." in which case the real problem here is why it isn't compiling. We'd need more details to figure out why. You also need to be clearer what you mean by "if I move the dll" - you can't "move" a DLL before it is compiled, and if you move it afterwards, then by definition the compiling worked, so actually your statement as it stands doesn't make sense. In any case, you should probably focus on fixing your broken build rather than fiddling with it to meet the needs of your version controlling.
You haven't specified why it is a problem for the DLL file to be in the Debug folder. I assume it's because you want to commit it to your VCS (which you didn't explicitly state as your goal). In which case, are you aware that it is not normal practice to commit the binary output of your code? So one solution might be to reconsider why you are trying to commit the DLL in the first place.
You didn't specify which VCS you're using. In Git (and I assume in most other VCS') you can have finer grain control over what to exclude from commits than whole folders. So, another option is to configure your VCS to ignore the Debug folder with the exception of any DLL files contained inside it.
You can change where MSVC places your DLL file in the project property pages under Configuration Properties -> General -> Output Directory. Presumably this is what you meant when you referred to "moving" the DLL?
Finally, as per other people's comments on your question, if you want the DLL to be in both places you can use a post-build step to copy it to the relevant place. To achieve this go to the project property pages under Configuration Properties -> Build Events -> Post-Build Event then enter the relevant command (the same as you would type at a command prompt) to do the copying e.g. copy myfile.dll .., or as Alex Farber suggests, use VS macros to specify the locations in a more generalised way. See this page for a list of available macros that you can insert into the command. This should be considered a last resort solution for two reasons - (a) it is a hack, as you are redundantly copying a binary output to circumvent a shortcoming in your version controlling and/or build, when you should fix the problem at root, and (b) build events have a serious flaw in them in Visual Studio and that is that they don't allow values to be inherited. This makes them a maintenance nightmare in bigger projects.
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.
I'm having a weird problem with Visual Studio. Whenever I change my code and build, even though I get the notification that the built was successful (and if any, it also shows errors in code and doesn't build) the executable is actually the previous build. This is getting really annoying and frustrating.
If I put a breakpoint on the new lines, the breakpoint gets disabled and it says
The breakpoint will not currently be hit. No executable code is
associated with this line. Possible causes include: preprocessor
directive or compiler/linker optimization
If I put a breakpoint on old lines of code, it stops processing but shows me this message
The source is different from when the module was built. Would you like
the debugger to use it anyway?
I never had this problem before and the source code in on my laptop's hard drive. It saves right away. The only way to get around this to Clean the entire solution manually every time, instead of basically pressing F5.
Thanks everyone for their suggestions. My mistake was that I defined the classes inside .cpp files, this somehow caused the linker to do weird (caching probably) stuff and link the old objects. I renamed the file to .h and everything's working as expected.
Perhaps your code is not built, or is built in a way you don't expect.
You might check by inserting a #error foobar preprocessor directive somewhere. If no error shows when building, you know you are in trouble!
But I never used Visual Studio (I'm only using Linux) so I cannot help more.
It might be that you have set main project some other project and building that.
make your project that you want to work on as "Main Project " by set main project available in menu bar.
I think you are using source files from another project (ex: if you are using a dll say, my.dll (which was built using some source files say, mycpp.cpp ); in your current project).
When you debugged into the file (mycpp.cpp), maybe you modified it.
Hence you need to rebuild the dll (my.dll) first in the project in which you created my.dll .
Or
Maybe you have opened a instance of mycpp.cpp in a window & debugging in another window.
you should rebuild the dll.
If you are not using files from another project, then I cant guess the cause...but still I would recommend using rebuild rather than clean & build.
please clarify your Question a bit.
#David expecting a reply from you...
I was looking for an answer to this issue since I was also stuck with it. A colleague of mine just gave me a solution that works. Yes, it seems really stupid, but it did the trick for me.
Our solution has many projects. He told me to select the project that I wish to break into and set it as the startup project (right-click on the project name and pick "Set as startup project"). I was desperate, so I tried. To my amazement, it works.
Since I have this window opened, I thought I'd share it in case someone else is stuck with the problem.
I faced the same problem. But reason was not as yours.
Then I just restarted the visual studio and it ran as expected.
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...