when trying to export the release build of an application I get the following error:
"One or more warnings were found while building the release version. You may choose to ignore these warnings"
So, following the advice from another post, in the "Additional Compiler Arguments" part of the project properties, I included a "-warnings=false" statement. I also unchecked "Enable Warnings"
This not only doesn't this remove the warnings, but it also doesn't prevent the error upon release.
The actual warnings are related to:
"widgets.Search:SearchWidget is a module or application that is directly referenced. This will cause widgets.Search:SearchWidget and all of its dependencies to be linked in with widgets.TOC:TOCWidget. Using an interface is the recommended practice to avoid this."
The original application code comes from outside my organization and completely re-writing it is not an option. There are no references in the code I can see that would directly relate each of these to each other, and I am stumped.
After some time-consuming troubleshooting I was able to isolate where the warnings came from. Unsurprisingly, it was from an "import" statement that was left over from something I experimented with months ago, but never actually used. It doesn't cause a problem during debugging so I forgot all about it. The problem was fixed as soon as I commented out the offending line.
Related
I'm struggling to change the behaviour of auto-completion for my own project in Xcode11.
I selected an empty project and I have implement some C++ methods. Now I want Xcode to recognize these methods and show the auto-complete suggestions for them.
However, I am only getting completion suggestions for basic C++ code, e.g., if-else, switch case, etc.. How can I setup Xcode to recognize my own methods?
Besides, in an older Xcode version I got auto-complete suggestions for previously written text in the same file. This functionality is gone. Can I reactivate it somehow?
Cheers
Your project should index and make those methods available in auto-completions. I've had similar issues (currently Xcode 11.3.1), but I found that building the project once (even with just a boilerplate main function), quitting and restarting Xcode seemed to help, at least for the project-local classes & methods. However auto-complete is broken now for some parts of C++, as if the standard system search paths for C++ aren't getting indexed. For example, completions for standard C++ header #includes (e.g. ) don't appear, only various Apple C lib headers. It may be that manually adding these paths to the build settings could resolve them. It used to "just work" though.
I'd also recommend filing a bug report if you haven't already. I'm sure they're focused mostly on Swift these days but if enough reports come in they may fix it.
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'm porting a C++ .NET solution to MSVS 2012. I have a particular problem with an assembly built localy. In the "Common Properties" section, in the reference list, the assembly was added ("Add New Reference" by browsing). But often (not always), the link seems to be broken (with a vertical red bar on the small icon at left beside the assembly name) and the project won't compile.
I remove the reference then re-add it (the same one!) and it build. I would appreciate any hint about how to fix this problem because we have a lot of projects in the solution.
You have encountered this problem?
Feel free to ask for more info...
Thanks.
Are you adding an assembly which is built by that project or a different one?
If so then the problem is that it might not be there or might be occupied (held open exclusively by another process like VS2010).
If it is in the same project dont add it by browsing add it from the projects tab.
If not then try to copy the assembly to a different location and then point to it.
In general pointing to different assemblies which are in another project is a very bad idea.
A common reason for this is a referenced assembly that the added assembly needs. And your project has a .NET framework target that doesn't include that assembly. The IDE gets screwy when that happens. Everything looks normal, IntelliSense works for example. Until you compile and the discrepancy is discovered. There is a warning about it in the Error List window but it is easily missed by the usual raft of errors that excluded assembly generates.
System.Web is a common one that isn't available, for example. Change the Framework Target setting from the Client profile to the full version to fix the problem and try again.
Here is what solved my problem:
When adding a reference (at least in VS2012), you have 4 choices at your left:
Assemblies <- GOOD!
COM
Solution
Browse <- BAD
By reflex, I chose Browse because I wanted to browse for the DLL in my folders. I found it (the DLL) then I wrongly beleived that it was correct.
What I had to do was to choose Assemblies. Then I could select Browse at the bottom of the dialog to browse my folders.
At current time I don't know what the first Browse is useful for. Anyway, I hope my mistake will help someone!
And many thanks to those who gave me some hints!
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 experienced this problem in VS2010 before, and solved it looking at this SO question. However, now that I upgraded my VS to SP1, it appeared again. I tried to solve it the same way, enabling C++ projects logging and using DebugView. But I can't get to see any output in DebugView, no matter what I do. I also tried raising the Build output verbosity (Tools->Options->Projects and Solutions->Build And Run), but couldn't find any clue.
As in the original problem, the projects reported as out of date are always unmanaged C++ projects. The solution has C#, VB.NET, C++/CLI and C++ projects. What I'm trying to run is a VB.NET exe which uses some C++ projects through C++/CLI wrappers.
Any hint on how to troubleshoot this?
UPDATE: Solved it with a clean checkout. However, it's a shame that there is no longer a way to troubleshoot this kind of errors...
Is it possible you were testing with the date in the future and saved a source file in the future? While clean/rebuild all should fix this, VS seems to go batty and stay there until I resave the file in the present.
Another last-ditch thing that sometimes solves these problems that works 'like a reboot' if you have just the source-code in version control: Check everything in, close VS and anything using files in your project, move all your project folders to a backup folder, and do a force-get latest version of each. Sometimes 'clean project' doesn't cut it.
If that doesn't work and you can't find a missing .h ... You can always fire up Process Monitor, set a filter, and dig in there.
Admittely all just stabs in the dark. Hope one hits the burgler! ;-)
After a compiler upgrade you should do a rebuild-all, if you haven't done that already.
For native C++ projects you can get "project out of date", but still nothing to build, if you have some include files in your project that doesn't actually exits. Like if you have deleted some unused .h files, but they are still part of the project.