I'm getting an error in Klocwork's Visual Studio integration stating that
On-The-Fly analysis did not start due to XX parser errors.
Is there a way to view On-The-Fly parser errors?
The Visual Studio solution is still building successfully, so I'm guessing it's something I need to make Klocwork aware of in the normal build process.
As of Klocwork Insight 10 the Visual Studio plugin will now display any parse errors in the Visual Studio Error List window.
In the previous versions, to view the parse errors you could look through the KWVS.log file which is written by the plugin to the user's temp folder, ie. the value of %TEMP%.
In general, the Klocwork parser is a bit more strict about things like missing semi-colons, etc. than the Visual Studio compiler is.
Related
I've had to rebuild my machine lately and lost all the Visual Studio extensions I had installed.
I did have one that displayed error messages inside the code block, but for the life of me I cannot find it on the marketplace.
It does very similar things to this extension:
https://marketplace.visualstudio.com/items?itemName=AlexanderGayko.ShowInlineErrors
But the trouble with the extension above, is it writes the error over existing code, which makes it difficult to read.
Okay I've found it myself it's at the following URL
https://marketplace.visualstudio.com/items?itemName=eberthold.SteroidsVS
There has been more than one occasion where I have mistakenly left a debugger keyword in a javascript file, and rather than finding these (or not) in code reviews, I'd quite like the Visual Studio build process to warn me about this so I remember to remove them - especially in a Release Mode build.
Likewise, maybe some warnings about console.log type of code.
How can I generate an MSBuild warning/error for this?
MSBuild compiler warning for javascript debugger statement
Just like as mentioned in the previously deleted answer, this issue should be more related to the Visual Studio extension rather than MSBuild.
You can use the Visual Studio extensions:
JSLint for Visual Studio
JSHint for Visual Studio
I'm currently using the JSLint from the link above and it works great.
Here are some screen shots of the settings / and my code with an
error. It won't prevent you from checking in, there would likely need
to be a check-in policy on the TFS server, but it will notify you of
the error when you build and save.
Here is the initial page where you can specify how to display the
JSLint validation messages. All of the options across the top you can
set to your liking. You can cancel the build and run the lint process
during save and / or build.
These are all of the specific JSLint rules that you can turn on or
off. I have highlighted the debugger rule that you asked about in your
question.
Certificate: Don't let check in with “debugger” in Visual Studio 2012
Hope this helps.
I have a C#/.Net 4.0 project in Visual Studio 2010. Parts of this project were originally from an old VB6 program that was converted to C#.
Sometimes I need to look at the old VB6 code side-by-side with the C# code, and so it's very convenient to just open and view the file in Visual Studio. V.S. even displays comments and keywords in appropriate colors for easy viewing. To open the VB6 file I'm doing a File>Open>File. The VB6 file has a .cls extension.
The problem is that when I do that it also tries to do background compilation of it, so as soon as I open it, it registers hundreds of errors because VB6 isn't a supported language and even if I do a Build Solution or Rebuild Solution it includes those results in the build so I can't build my C# project when the VB6 file is open.
1. Why does it do this, considering that the VB6 file is not part of the current solution or project?
2. How do I turn it off so I can view the file but not have Visual Studio try to compile it?
Why does it do this?
The cls extension is mapped to the Visual Basic language service. It will interpret any file with that extension as a VB.Net file and process it as such.
The Visual Basic Language service is always compiling files to a degree in the background. It doesn't actually produce EXE / DLL but will go far enough to provide semantic information to the front end. This is used in intellisense, code highlighting, error squiggles, etc ...
How do I turn it off?
Unfortunately you can't. Visual Basic background compilation is not configurable. Hence any file which it believes to be VB.Net code will be processed in the background and errors will be displayed.
The only way to view it without errors is to rename the file to an extension not thought to be VB.Net code (like txt)
When working in VS, the error messages in the bottom panel are compiler errors and warnings, right? Does this mean the app is being compiled all the time? I would expect those to appear only when trying to run the app.
This is probably a silly question, but I cannot find the answer.
Visual Studio continually parses the source code; this allows it to preemptively report some errors before you actually compile the source.
This is, of course, dependent upon which language you are using. C++ didn't get preemptive error reporting until Visual Studio 2010.
Visual Studio doesn't natively continuously compile code.
However, I just downloaded the 14 day trial of this little app called .Net Demon that's a plugin for Visual Studio. It costs $30, but definitely a nifty tool if you've got large solutions with many projects.
http://www.red-gate.com/products/dotnet-development/dotnet-demon/
I'll probably end up breaking down and buying it, it's pretty slick.
Each programming language is different (each provides a Visual Studio 'language service' specific to that language that provides the feedback), but for the most part, yes, it is being compiled over and over. In F#, for example, the compiler is divided into a few stages, main ones being lexer/parser, typechecker, and code generator, and the lexer/parser/typechecker are running inside VS, and every time you type a character into a file, that file is re-run through those stages of the compiler.
When you compile an application there might be errors and warnings which will be shown at the errors window. When you run the application errors will no longer be shown in Visual Studio but depending on how your application is organized it will either crash or handle them gracefully. Also notice that if you try to run the application with F5 or Ctrl+F5 Visual Studio will try to compile it first and if there are compile-time errors and warnings they will be shown.
I was looking around the net for a NUnit custom MSBuild task that would run on every build and also nicely play with Visual Studio UI (2008 is my version). I found MSBuild.Community.Tasks project that was great, but failed in Visual Studio integration part.
What I actually wanted to have is get failed tests displayed as warnings/errors in VS's error list window (and also FAILED project build when tests are not successful). So I wrote my own custom MSBuild task that does the job exactly how I wanted it to be.
BUT.
The only problem that I have is that normal VS UI error list behaviour is that when you click on an error it jumps to appropriate source file and highlights the problematic code. I was able to relate file and line number with failed test however I wasn't able in any way to persuade Visual Studio to HIGHLIGHT problematic code for me (when I double click the error). All I get is cursor in the right spot.
I tried all kinds of combinations of line, endLine, column, endColumn method parameters (Log.LogError()), but to no avail. And based on error output by compiler errors it looks like it also provides just line and column (no end values).
Anybody ran against this oddity and solved it?
Update 13 May 2009
You can get this project for free (without method selection) at
http://code.google.com/p/nunitmsbuildvsintegrated/
For this feature, you must create Visual Studio Integrated Package that display custom panel in Visual Studio. This custom panel will be called when your project is built.
Visual Studio Extensibility Developer Center
I have no solution to your exact problem, but have some thoughts.
Are you sure you want to run a full suite of unit tests at the end of each and every build? I personally find it to be a productivity killer. Rather, while working with code I tend to run a small subset tests which cover only the code in question, and this is where tools like ReSharper or TestDriven.NET come into play.
(source: jetbrains.com)