I created a project in VS 2010. I want to convert it into VS 2013. When I build it, there is an error:
CA0053 Error Running Code Analysis CA0053 : Unable to load rule assembly 'c:\program files\microsoft visual studio 10.0\team tools\static analysis tools\fxcop\rules\globalizationrules.dll': Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
I disabled the "Enable Code Analysis in Build" and run, then it doesn't give me an error.
What is the importance of Enabling Code Analysis?
What will happen if disable the Code Analysis?
The CA0053 error you get is a known issue when converting from VS 2010 to VS 2012/13. I have listed up how to fix just that issue here: http://geekswithblogs.net/terje/archive/2012/08/18/how-to-fix-the-ca0053-error-in-code-analysis-in.aspx
The underlying cause is that your project is bound to the specific version, and should be version independent, caused by using an absolute path to the VS 2010 binaries.
You can change that in the project file, as described in the post.
If you want to do it manually, the basic steps are:
Open the project file (.csproj) in a text editor
Locate the lines for <CodeAnalysisRuleDirectories> and <CodeAnalysisRuleSetDirectories>
Replace them with the lines
shown here
<CodeAnalysisRuleDirectories>$(DevEnvDir)\..\..\Team Tools\Static Analysis Tools\FxCop\Rules</CodeAnalysisRuleDirectories>
and
<CodeAnalysisRuleSetDirectories>$(DevEnvDir)\..\..\Team Tools\Static Analysis Tools\Rule Sets</CodeAnalysisRuleSetDirectories>
As noted in the blog post, in many cases it seems you also can just delete the lines. You can try that first, if that doesn't work, do step 3 above.
What is the importance of Enabling Code Analysis?
So that your code gets analyzed.
What will happen if disable the Code Analysis?
Your code won't be analyzed.
Code analysis gives you hints about your code. It is a style and security check for the code you write.
See for more info MSDN: Code Analysis for Managed Code Overview and MSDN: Analyzing Managed Code Quality by Using Code Analysis.
Related
I am debugging a program, and see compilation error
cs8300 "merge conflict marker encountered"
What does this mean? Is there any Microsoft Documentation for this? We are working with Git Source control, and trying to compile Net Core program.
I believe this is if you have being doing a merge or a pull from either another branch or from the remote source control, there was a conflict i.e. someone has changed the same line as you have. This begins a "conflict resolution" in Visual Studio asking you to choose which lines you want.
However I suspect you have attempted to build the project without completing the conflict resolution.
The conflict will add little bits of text to your files indicating to Git where the conflicts are, if you open the files in a plain text editor like notepad you will see them.
For further background information here is the documentation regarding resolving merge conflicts in Visual Studio: https://learn.microsoft.com/en-us/azure/devops/repos/git/merging?view=azure-devops&tabs=visual-studio
Here is a screen shot taken from that documentation which you will likely see in Visual Studio.
Here's what I've tried:
Made a new Console App (.NET Framework) in Visual Studio 2017.
Added the following code:
static void Main(string[] args)
{
new Dictionary<int, int>().TryGetValue(3, out int x); //I want to step into TryGetValue() (this is just an example)
}
Configured the settings listed here:
https://blogs.msdn.microsoft.com/sburke/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code/
Confirmed symbols are loaded in the Modules window:
mscorlib.dll Symbols loaded. 4.6.1586.0 built by: NETFXREL2
Tried: "Step Into (F11)"
Tried: "Step into Specific" | "System.Collections.Generic.Dictionary.TryGetValue"
Both just step over the line.
I've tried configuring VS using the details here: http://www.symbolsource.org/Public/Home/VisualStudio
Same result, the debugger steps over the line.
I've looked at the answer here: https://stackoverflow.com/a/12432029/297451
But this version doesn't seem to be a security update, and a search for "site:support.microsoft.com/kb 4.6.1586.0" yields nothing.
What am I doing wrong?
Here is the answer, thanks to Hans Passant. Note that this solution raises additional questions.
Ensure https://referencesource.microsoft.com/ contains the exact version you're debugging.
How? Reference source specifies ".NET Framework 4.6.2" but a module version is something like: "4.6.1586.0"
You may need to uninstall security updates as explained here: How do you enable "Enable .NET Framework source stepping"?
Configure Visual Studio as specified here:
https://referencesource.microsoft.com/setup.html
Untick "Enable Just My Code"
Tick "Enable .NET Framework source stepping" (this should have been the only step needed)
Tick "Enable source server support"
Untick "Require source files to exactly match the original version"
Confirm symbols are loaded in the Modules window, with source indexing included.
How can you tell if source indexing is included? The modules window doesn't specify if a PDB has stripped source information.
Microsoft could make this process a lot more robust by giving helpful error messages instead of silently failing.
Use the Symbol Server feature in JetBrains dotPeek. Worked like a charm for me after struggling to get the standard functionality to work:
Run dotPeek and go to Tools > Options... > Symbol Server.
Ensure that "All assemblies" is selected and copy the local symbol server URL to the clipboard. Start the dotPeek symbol server by clicking it in the Tools menu.
In Visual Studio, go to Tools > Options... > Debugging > Symbols and add the dotPeek server URL to the list. Move the dotPeek symbol server as high up the list as possible, and uncheck all other symbol servers in the list (in particular, the "Microsoft Symbol Servers" and "NuGet.org Symbol Server" must not be selected).
Start debugging - when you attempt to step into Framework source code, you will see dotPeek doing some work decompiling the assembly for you, and then you will be into its source.
If this doesn't work, it's probably because Visual Studio has previously downloaded the "wrong" symbols for the assembly in question from Microsoft/NuGet, and is using them instead of asking dotPeek. To check this, start debugging and find the relevant assembly in the modules list (Debug > Windows > Modules) - delete the PDB file at the path displayed under "Symbol File" for that assembly, then restart debugging, and dotPeek should kick into action.
I'm tring to run analysis on SonarQube, using an FxCop custom Rule.
In SonarQube 4.5.7 I add the rule to the set of rules, I activate it and then run the analysis.
To run the analysis I use the sequence of following commands:
1) MSBuild.SonarQube.Runner.exe begin /k:my.project.C-Sharp-ConsoleApp /n:C-Sharp-ConsoleApp /v:1.1
2) "C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild" /T:Rebuild
3) MSBuild.SonarQube.Runner.exe end
I see that the rule is executed, because when I run the second command I read the following part of log:
...
(RunCodeAnalysis target) ->
MSBUILD : warning CR1000: MyRules : Field 'CSharpSortNames.m_variabile' is not in Hungarian notation. Field name should be prefixed with 's'. [C:\Users\Alessandro\Documents\Visual Studio 2015\Projects\C-Sharp-ConsoleApp\C-Sharp-ConsoleApp\C-Sharp-ConsoleApp.csproj]
My custom rule checkID is CR1000, and after the third command, I see that an error of this rule is founded, but the web app doesn't let me see where. For all other errors the web app let me see the precise line where is the error by a link to the .cs file. For my rule it doesn't.
Anyone can help me about this?
Further problem is in SonarQube 5.4 the same rule is activated but web app does not show the error.
The root cause here is that FxCop uses information from the PDB file for providing location information. However, the PDB only contains information that would be useful for debugging scenarios, which means that FxCop rule violations that are associated with non-executable code (e.g.: field declarations or interface definitions) will not have location information available. (FWIW, there is an open SonarQube issue for addressing this, but it would be non-trivial to accomplish unless SonarQube were to directly examine the source files to attempt to locate the field declaration. I rather suspect they might not bother given that it simpler to address via a Roslyn analyzer.)
Further problem is in SonarQube 5.4 the same rule is activated but web
app does not show the error.
That's because older versions of the C# plugin for SonarQube completely ignored FxCop violations without location information. This was addressed in version 5.2 of the plugin, which only became in early May 2016 (and is presumably what you used when you installed SonarQube 5.5). It is compatible with version 5.4 of SonarQube, so you should be able to use it with your older installs if you like.
By default, code analysis is only done for projects which are compiled. So when I run MSBuild from the command line, it runs code analysis only for the first time. On subsequent calls, code analysis is skipped.
Background: I want to evaluate CA rules and see how many warnings there would be in our code when turning on a rule. For that I don't want to recompile everything - which takes some time - but just re-run the code analysis. How can you achieve this?
I am using Visual Studio 2013 and MSBuild 12.0.
Even explicitely switching on code analysis does not help:
msbuild DesktopBuild.proj /p:RunCodeAnalysis=true
It seems that
del /s *.lastcodeanalysissucceeded
msbuild DesktopBuild.proj /p:RunCodeAnalysis=true
seems to work. The first step causes code analysis to "forget" about the previous runs and the second step forces it to run for every project, even if code analysis is not enabled in a project. If running this repeatedly, the already compiled projects won't be compiled again, only the code analysis is re-run.
Simply set CodeAnalysisGenerateSuccessFile to false in the project file.
<PropertyGroup>
<RunCodeAnalysis>true</RunCodeAnalysis>
<CodeAnalysisGenerateSuccessFile>false</CodeAnalysisGenerateSuccessFile>
</PropertyGroup>
I would try using FxCopCmd.exe, it can be usually found in C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\FxCop. It's used by CodeAnalysis in Visual Studio, you should be able to use it with proper parameters.
When is "Browse To Find source" enabled in Visual Studio 2010? (see below)
In addition, I want to have it enabled so that I could browse to already-downloaded source code
files from http://referencesource.microsoft.com/.
This would be useful since Microsoft doesn't always release PDB/source code at the same time with their latest patches. So if I want to step for example into DateTime, I really don't care about the latest patches which didn't involve DateTime. I just want to browse to its code which I downloaded from http://referencesource.microsoft.com/.
After some investigations I found dia2dump which is a useful tool to view PDB file contents. (It's in C:\Program Files (x86)\Microsoft Visual Studio 10.0\DIA SDK\Samples\DIA2Dump\)
It looks like when I can't see source code for something like DateTime, using .NET Framework stepping, a mscorlib.pdb file actually gets downloaded.
But if you look inside it with dia2dump it doesn't contain source file mappings. In other words useless, because even if you could browse to the source code like my initial idea, it wouldn't work because there are no source file mappings and no start addresses of the functions, and a lot of stuff missing :(
I think the solutions here are to use .NET Reflector Pro for or keep a virtual machine at hand, with releases of the framework which have source code and then disable updates.
Introduction
Whenever you do a build from Visual Studio, normally, you also get a PDB file besides your executable file. You can see this file in the ..bin\Debug or ..bin\Release directory.
This PDB file keeps a mapping to your source code lines and executable code in your assembly. Also, the original locations of the source code files from which a build was done is stored inside a PDB file.
This means that if you build a class library which had a single file located at G:\ClassLibrary\Class1.cs, this path will be stored inside ClassLibrary.pdb.
What is important to remember from all this is that without a PDB file it is impossible to do source code step-in debugging.
Real-life scenario
So, suppose I do a build on my drive G:\ClassLibrary1, for a class library.
I give you a ClassLibrary.dll and a ClassLibrary.pdb file, or you get them by checking them out from source control.
You reference the ClassLibrary.dll in your project and you use a class from the library.
If you now try to step into class code from the library the following will happen:
Visual Studio tries to locate a ClassLibrary.pdb file in a couple of locations
1.1 If it doesn't find it, you get a "Browse to find source" disabled
page. Remember, you can't debug without a valid PDB file.
1.2 If it does find a PDB file, it looks inside the PDB file and sees that you are trying to debug Class1.cs which was originally built from
G:\ClassLibrary1\Class1.cs
and looks on your computer for that file.
1.2.1 If it finds it, it steps into the code automatically.
1.2.2 If it doesn't find it, you get the following dialog:
If you press Cancel, you will be presented with the: "No source available" and you will have "Browse to find source" enabled in this case.
Why? Because you have a valid PDB file, but Visual Studio can't possibly know where you have the source code for ClassLibrary1 on your computer or if you even have it on your computer. That's why you got the dialog -> so that you can point Visual Studio to the exact location of the source code file.
Final notes
So what will you do when you get a browse to find source disabled?
In Visual Studio, you open menu Debug -> Windows -> Call stack.
You right click on the top call stak instruction and you choose "Symbol Load Information". It will show you the locations where Visual Studio has tried to find a valid PDB file.
1.a If you only see "Cannot find or open PDB file" messages put a valid PDB file at any of these locations. (You might have to scroll right to see the messages) Stop and start debugging again.
1.b If you see a "PDB does not match the image" message it means the following. Visual Studio has found a PDB file, but it is for another build. If I build ClassLibrary1.dll and give it to you, and then I build it again without changing a single line of code and then give you the PDB, and you try
to debug classLibrary1.dll you will get this message. The assembly and its PDB file must be exactly from the same build, otherwise you will get this message. (This check is done using some unique number put inside the assembly and PDB file every time you do a built)
1.c You see a "symbols loaded" message but still get a "Browse to find" disabled. It means that the PDB file you have is not good for step-in debugging. Some PDB files you try to use don't have all the information in them necessary for step-in debugging. I think you can control this from somewhere in the advanced build settings, but I haven't tried it though, because I want to have usable PDB files generated everytime I do a build. This situation often happens if you try to debug the source code of the .NET framework itself and Microsoft hasn't put usable PDB files for the source code, but instead Microsoft has put some PDB files which can't be used for step-in debug. This happens more often than you think, because often Microsoft makes updates (patches) to the .NET Framework source code. These updates silently install onto your computer via Windows Update, and you are surprised to see that yesterday you could debug .NET Framework source code and today you can't. It usually takes some time until they put a valid PDB file for the latest code. In this case you can use .NET Reflector Pro step-debug ability or a virtual machine which has a .NET framework version with usable PDB files and disable Windows Update on that machine.
Check out the article Step Into .NET Framework 4.0 Source Code.
If you encounter the “No Source Available” screen, try to press “Browse to Find Source” and find the file you need in the source directory. You should probably need to use files search to find it.
This is done only once, since from now on Visual Studio remembers this location and searches there for missing source files.
I hope it's about what you are looking for.
Similar issue in Visual Studio 2019 can be resolved by checking "Enable Just My Code".
Debug > Options... > Debugging > General > Enable Just My Code
More detail explanation can be found here How to fix debugger is looking for executioncontext.cs