I like having a high level of warnings (usually W4). However, with a warning level of 4 or higher, I get a lot of warnings from Windows headers and from third party headers, which makes it very difficult to find the ones I can actually do something about.
Hence my question: Can I tell Visual Studio to show warnings only for those files which belong to my current project?
This would be especially useful when running code analysis. Why show all those warnings for code that I don't own?
I found one thing that might help:
Right click anywhere on one of the rows in the Error List and click Grouping->Path. The path to the file will show up on the left. Now you can collapse all the paths to code that you want to ignore.
It's not ideal, but it's better than nothing.
Related
I am trying to profile my c++ dll, but the profiler is not working with me. I would like to see the call tree an so on, but only the stl functions show up, and not all disjoint - when i click on any function, their caller is "[broken]".
I don't know if my google skills are just not sufficient, but i can not find any information on what [broken] means, and how to fix it.
This is a debug build. I cannot guarantee this is not due to some compiler settings, but i fell like i have tried everything.
It should be noted that breaking the code and adding breakpoints works fine, so the profiler just doesn't access this information
If it adds any information, profiling the specific DLL as specified here gives the exception "File contains no data buffers".
My guess is that something wrong with PDBs of your output (for instance, you may have /DEBUG:FASTLINK set in your linker's settings, which produces reference-only PDBs).
If it's not the case, you may try my profiler - it works as an extension to VisualStudio, is instrumenting (meaning it's function-accurate) and displays stats in realtime.
I can't seem to be able to suppress warnings in my solution in Visual Studio 2017 by going into Project Settings > Build > Suppress warnings:
Even when I clean - build, rebuild, etc... the solution, Visual Studio keeps bringing up these warnings for me.
I brought this up with a visualstudio.com report yesterday and it's "triaged" at the moment. Is there an alternative way to suppress warnings in the solution, without marking every single reference?
Version: 15.6.2
Update:
This is wierd.
Visual Studio 2017 uses a semicolon by default, but comma worked.
The way I do it solution-wide is to create a specific suppression file, for instance GlobalSuppressionsForTestProjects.cs, in a convenient solution-level location.
Then for each project of the solution where I want the suppression definitions applied, I add a link to the suppression file:
right-click on project -> Add -> Existing Item
in selection dialog, navigate to the suppression file
click on Add as Link
I learned this trick from this post where the same way was applied for AssemblyInfo.cs files.
I usually use pragma directives:
#pragma warning disable 1591
// whatever member is lacking xml comments, or even the whole file
#pragma warning restore 1591
Verbatim from the link above:
disable: Do not issue the specified warning message(s).
If you really want to disable warnings solution-wide, there's no way to do it.
All compilation options are specified on the project level. MSBuild exists below the level of solutions.
But it can be done project-wise, just like you were doing above; the only thing I would change is separating those codes using a comma and not a semicolon like in your picture (and without a comma in the end), e.g.:
1591,1701,1702,1705
That's because compiler options use a comma.
You may just need to restart Visual Studio. This worked for me, and FYI we do not need to include the CS part of the error in your textbox (it would still work as written though, but you only need the number for this.) You have certainly restarted VS in the years since first asking the question, but for anyone having this problem today, I hope this helps.
I had the same issue with the same warning (CS1591). So for "Suppress warnings" in the properties to actually work (rather than the #pragma solution which is a legitimate work-around but might be unnecessary keyboard time after a restart) you might just need to restart Visual Studio.
We have a web project with Angular, jquery and Telerik Kendo.
When searching for any text Ctrl+Shift+F that is then found in any of their *.min.js or *.js.map files, the VS (both 2013 and now 2015) will become unresponsive for 30-60s. Also when later I scroll the Find Result 1 window, it will momentarily become unresponsive when long line becomes visible. Everything becomes smooth again if I clear the search results from Find Result 1.
We have the *.min.js and *.js.map files included in project itself. Is this wrong approach?
This is a well known problem, the Connect feedback article is here. These files are poison pills to an IDE, compare to this Q+A.
Little to add, beyond not adding them to your project, the proposed workaround in the article is the obvious one. And as long as you need to search through these files you surely want to work with the non-minimized versions of them.
In the Find options, expand "Result options" (Alt+S) and enable "Display file names only". The contents of the files will not be displayed in the find results and everything will be a lot faster. You can still double click a file name in the find results to go to the exact location of the match in that file.
Does this problem happen for everyone, or only on particular machines? Are there any Visual Studio extensions that may be slowing down the search? You could try and temporarily disable all extensions and see if you have the same problem.
Otherwise, I would agree that including the .min.js and .map files in the solution / project is not ideal anyway.
My recommendation is to use Bower to manage your 3rd party client-side library dependencies. They say use the right tool for the job, and in this case, it's currently Bower.
Bower support is baked in to Visual Studio 2015. Here's some Microsoft docs on using Bower in Visual Studio 2015:
http://docs.asp.net/en/latest/client-side/bower.html
Docs for installing Kendo using Bower: http://docs.telerik.com/kendo-ui/install/bower
Now, this by default will put those vendor libraries in a bower_components folder under the project root. You would then not include this folder in your project, or in source control (but bower.json and optional .bowerrc would go into source control).
This should alleviate your problem in VS2013, but in 2015, Find in Files will still search bower_components. So your best bet is to try and narrow down the source of the slow-down.
Using Bower potentially impacts your development and build process, so you might want to avoid that if that's going to force your hand to make other changes you're not positioned for yet.
One thing you can check to try and help solve this issues, is in your gruntfile's minify task, make sure the mangle property is set to false. Mangle changes the variable names to really short names, so sometimes that can mess up your other files that use variables from those minified files, and other errors can occur. I'm not sure why visual studio crashes or wouldn't be able to handle searching for a string that doesn't exist, but it's something to consider.
I have issue with both "Go to definition" functionality on Visual Studio and "Go to Implementation" for Visual Assist plugin.
As I know, to perform jump to code I need to add additional include/source paths to the project property for MVS or sources paths for VAssist.
I have added them, but nothing changed. When I press go to definition I have following message:
Is recursive parsing of include path that was added to additional paths?
Or I need to add all paths separately to that need for? If so, what to do with a very big number of paths within include/sources files?
Thanks.
I found solution for my own question. Seems like MS VS bug.
To enable proper jump, just need to turn of "Colorize inactive code blocks in a different color" check-box:
I'm working on a large, inherited C++ (really, mostly C) project developed and maintained under Visual Studio 2008. Technically, in Visual Studio terms, it is a "solution" consisting of eight "projects", and therein appears to be the rub.
As I'm sure most of you know, Visual Studio grays out the code that it believes to be #ifdef'd out. What I'm finding, though, is that it doesn't seem to do this correctly for the different projects. To keep matters simple, let's just call them Proj1, Proj2, ... Proj8. When I'm working on the Win32 Debug configuration of Proj5, I'd expect that the macros defined in the C/C++ Preprocessor properties configuration of Proj5 would determine what is grayed (or at least that there would be some straightforward way to make it so). Instead, I seem to be seeing views based on properties of Proj1. That is, if Proj1 defines some preprocessor macros that eliminate part of the code, I'm seeing that part grayed even when I'm working on Proj5. And the macros for Proj5 have no effect at all on what I see.
Yes, I did a complete clean and build (several, actually, and even saved everything off to SVN and started in a new top-level folder), and so I'm pretty sure this is not because of some vestigial files produced by an old build. And I'm pretty sure that in other respects Visual Sourcesafe "understands" the context correctly, because (1) the Build menu contains options related to Proj5, not Proj1; (b) at the bottom of the Project menu is "Proj5 properties..." not "Proj1 properties..."; and (c) there is no question that the #ifdef's are working in the program that is built: there are major feature differences, and they are as I'd expect them to be.
ADDED 27 Sept 2010 I still don't have an answer, so let me try this a different way: Assuming I've already run successful builds (which I have) is there anything other than the preprocessor properties and configuration of the currently selected project (and, as noted below, those of individual files, but that is moot in this case) that should influence what code is grayed?
Please see if these preprocessor directives might be set for the individual files. You can do this by right-clicking on a source file and selecting "Properties" from the context menu. It's somewhat counterintuitive to think that the directives can be set for individual files, not just for projects.
If that doesn't help, your best bet might be to use a text editor to look for the problem preprocessor definitions in each of the project files to try to get a better idea of what might be happening.
VS2010 is supposed to help with this. In VS2008, the no-compile browse cache is done after preprocessing, so it can accommodate only one set of macro definitions.
I don't believe that "Build Clean" or "Rebuild" will delete the .ncb files, since they are not part of the build process at all. I do know that deleting these files by hand fixes all kinds of weird behavior, but I'm afraid that in your case it's not going to be a lasting solution (the .ncb files will still get filled in based on a single configuration.)
Make the project the Startup Project and Remove and Re-add the offending Preprocessor Definition
Details:
I found a process that that fixes my MFC projects when this happens (at least temporarily). First I set the project I am working on as the startup project. Do that by right-clicking the project in the solution explorer and selecting Set as Startup Project. Then I go into the preprocessor definitions for the project and deleting the one that is not triggering and clicking OK. You will see a little progress bar a few seconds later appear in the lower right. Once it finishes, go back into preprocessor definitions for the project and add it back in again and click OK. After the little progress bar finishes again, you should see the correct code active again.