We Keep Coding

Does FxCop in C# cover MISRA?

For programs written in .net/C# does FxCop (and Roslyn equivalents) cover the relevant rules in MISRA? Has anybody gone through and ticked them off?
Or is there a compliance standard for .NET similar to MISRA?

No. By default FxCop (now Code Analysis in Visual Studio) only watches for spelling/casing corrections and Microsoft's own guidelines. You are free to come-up with your own rules, of course.
Note that most of the static-analysis tools only look at the compiled CIL - so you won't be able to watch for safety-critical style violations (such as non-braced if and unintentional switch-case fallthroughs).
Given that MISRA is specifically for C and C++ (and not C#/CIL) you won't find it under FxCop. Though I imagine if you did implement MISRA for C# you would make a tidy bit of money from it - I'd pay for it!

After some googleing I did find http://www.sonarlint.org/visualstudio/rules/index.html#sonarLintVersion=2.0.0&ruleId=S2291&tags=misra
This tool looks quite interesting taking the Roslyn analyzers to the next level. I will investigate this tool further.

Does Visual Studio for C# have these Eclipse for Java features?

So far I use to develop in Java. Java is multi-platform (now works on Android!), has a very powerfull VM and is open, well behaved, etc. But is also old and seems to be stopped on time in terms of language features. Scala and Gosu are nice replacements, but I don't like Scala syntax and Gosu is very immature and unlike to win from Scala. All this makes me think about moving to C# at least for web development! Phew!
One thing that is quite important to me is IDE support. Right now I use Eclipse for Java, and my favorite features are these (most important first, somewhat):
Full code navigation (call hierarchy, show variable reads & writes, inherited members).
Incremental compilation (which means fast compilation).
Many kinds of errors are detected and underlined before compilation.
Many intelligent quick-fixes (can fix/write many code for you and quickly rename elements and refactor references).
Intelligent and configurable code completion. Display hints even for unimported packages/classes.
Over 15 kinds of refactorings, all of them very useful.
Over 15 options of source generation (add unimplemented methods, generate getters and setter, generate delegates).
Configurable code formatter, even for code fragments (select code then format).
Debugger supports hot code replacement and "Drop to Frame" so I can go back an check other things without full program startup.
Code cleanups (remove unnecessary parenthesis, remove unnecessary "this" references, etc).
Very decent, autonomous and seamless CVS integration, with integrated file comparison and computer-aided merge.
Very nice tools for web development (server deployment, JavaScript and HTML editor with formatter).
Tons of plugins (code coverage analyser, memory dump analyser, eGIT).
Which of these features are available in Visual Studio for C#/ASP.NET? If I can get some by adding a cheap plugin, please tell.

Well, I like Visual Studio a lot more than Eclipse. I have only used Eclipse for minimal Java programming and Action Script. Visual Studio can do every thing you listed and if you combine it with a paid plugin like Resharper or CodeRush, you get a lot more. Why don't you download Visual Studio Express and play around with it? That would be much better than getting an answer from a very biased C# dev.

VS2010 with the addition of ReSharper has most of these things. I can't speak to CVS, but it does have fine SVN integration.
I started using VS about six months ago after a few years of Eclipse, and it works pretty well.
Nothing is cheap in the VS world compared to Eclipse.

How and which tool should I use for Source Control? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
A little bit of Background first:
I have been using Team Foundation Server for about few months and know pretty much how to use it. I have been using it for my project on Codeplex. They required TFS and it was in my Visual Studio Installations, so basically I never knew what all it took to get it to work as it seamlessly worked inside Visual Studio and I just had to do Check In and Check Out stuff...
But now I wanted to see what other Alternatives were available and first installed Mercurial command line (which I never used), then searched for a GUI alternative and installed TortoiseHg and followed instruction from documentation on its Website. Then it said to install a 3 way Diff tool... I searched for it and then Found TortoiseSVN; I thought it must be some plugin or something so I searched SO for questions related to my situation when I stumbled upon this SO Question and was pretty mesmerized by so many tools for different work.
Now:
Can somebody explain what all tools are for source control. Do I have to install a different tool for every different task. Isn't there any single package for all of them. And basically what are the tasks we perform in Source Controlling. I only know Check In, Check Out and checking difference from Codeplex Website. What else should I know.
Does every website like Git, BitBucket, etc use different Tortoise (xxx) for their source control.
Are Source Control and Version Control different terms
Please help..

This is a huge topic and will be impossible to provide a single all-encompassing answer. Nonetheless here are a few thoughts, assuming you are looking for more of a Software Configuration Management solution rather than a simple Revision Control System type approach:
Release Management:
In addition to concurrency control (check-in, check-out, etc.) your SCM can/should also provide history, tagging, branching, and other release management type capabilities. That is, it should always provide a single source of truth as to what source files when into which release, service packs, etc. In order to do this, your build environment needs to be well integrated into your SCM.
WIP Management:
A good SCM system will allow to you compare your work-in-progress to the latest checked in revision. It should also let you revert your WIP, shelve it temporarily, or merge another's changes on a file by file basis.
Documentation & Training
Do not underestimate how important it is to use a tool that can give you a ton of help, books, documentation, community support, and even paid support if needed. Also selecting a "popular" tool can mean that some new developers have one less thing to learn.
Continuous Integration:
Automated builds are a must for any serious organization and you should pick an SCM that can be access by your build systems (e.g. Hudson, CruiseControl, Bamboo, etc.)
Security
The SCM system should have a built in authentication system and also be able to use outside authentication providers as many organizations change over time. In addition, it should be able to support developers working outside the firewall, preferrably over http.
IDE and Build Tool Integration
To make all this stuff easier your SCM must be able to be seamlessly linked into your development system and any command line tools you use. This fact is made easier by the fact that almost all non-Microsoft IDE's support all SCM tools.
Source Browsing
Most SCM tools that I've seen have a number of very high quality, third party browsers such as Fisheye. So I discount this as a differentiating factor.
So which tool to use?
If your organization is fairly well contained within your company then pick Subversion. It is very popular, integrates with every IDE/OS/Build tool, works with ToroiseSVN, supports all platforms, supports multiple protocols, several UI, a powerful command line, a huge community, is free, and is rock solid. It also has an excellent free book.
If you have a highly distributed development group and/or expect to receive open-source contributions from many different folks, go with the distributed capabilities of Git.
Beyond these two, save yourself a ton of time and hassle and forget everything else....really. I realize I am being opinionated, but you kinda asked for an opinion.

If I was to advise something to you, it would be
Use mercurial (aka hg), and start by
learning it in the command line. That
way you will learn all basic concepts,
which could be somewhat hidden from
you when using only GUI overlay such
as TortoiseHG. All with a good
simplistic tutorial of course, perhaps
widely known hginit which covers
some simple usage scenarios.
That would be answer to "What else should I know" part, at least for a start. You can then explore by yourself, having a limited, but somewhat solid base. Or, at least, you will be able to ask more concise questions to learn more, or make more sense of the SO question you quote. Your question is somewhat broader than this, of course, but I would advise not to try to grasp everything at once. Each system has it's own quirks and specialties, but you shouldn't be worried by that fact now. Just as with programming -- you should not try to learn many languages at once, if you don't know any yet.
Ah, and as a finishing touch: Tortoise(xxx) is not exactly a revision control system, thats just a typical name for a shell-integrated Windows client to system xxx. As far as I'm concerned, the "Tortoise" part refers to "shell".
PS. the "Mercurial" advice is due to my personal taste of course, but also by the feeling that learning Hg will enable you to grasp most of the ideas from other systems quite easy (if you ever need to).

From my personal experience I would recommend looking at the new generation of 'Source Control Systems' that are called Distributed Version Control Systems. These are systems like Git (and I think Mercurial but I haven't used that.) that actaully store a full version control system locally and when you commit to the remote repository (push in git terms) you push the changes in your local version control system to the master version control system on the server.
Also Git is designed to make Branching a breeze. In systems like Subversion branching is not as easy but with Git Branching is the recommended practice of making changes. I have used Git, Subversion (SVN) and SourceSafe(the worst Source control System of the three by far!) and this is the major advantage of Git over more traditional Source Control Systems.
For Example if you are fixing a bug or adding a feature in a code base that uses SVN the standard practice would be to
Check out the branch you are going to work in.
Make any bug fixes and test them.
Checkin the changes.
With Git or Similar systems you would
Branch the master branch locally (i.e. development, producton version 1.1, etc.).
Make any bug fixes and test in your locally branched version (i.e. you made a jira-123-bugfix branch for version 1.1).
Merge the branch back into your local copy of the master branch that you created it from and make sure everything is OK.
Then push the changes you made to your local copy of the master branch to the central Git repository.
The advantage of this is that if you have to go back and revist the bug fix you still have your local copy of that branch.
See articles like A Successful Git Branching Model for more info.

Visual Studio Code Analysis - Does Microsoft follow it themselves?

Did a quick search but could not find anything about this.
I guess all of you know that the Visual Studio Code Analysis is quite nitpicking and gives warnings about a lot of things. Does anybody know how well Microsoft follow this themselves..? That is, if I were to run a code analysis on their assemblies, would the warnings be none or very few (perhaps surpress warning with a justification..?).

Most of the things that code analysis (or FXCop) check are closely based on the ".NET Framework Library Design Guidelines" (either the book, or on MSDN).
However those guidelines (especially in the book) have caveats, not all apply in all circumstances.
There are plenty of indications that MS do use these tools, but I assume they do have reasons to not apply all the rules all the time, as any other project does.

There are two core tools used widely at Microsoft for Code Analysis: FXCop for managed code and PreFast for native C++.
Historically, while not every team has thoroughly enforced the use of CA when building their products, there's been a significant upswing over the last 3-4 years in particular in the number of teams that now enforce pretty stringent CA requirements on their feature teams and on the product as a whole.
For example, in Vista, the Windows team essentially took 3 months off product development and SAL-annotated the vast majority of their key method and function declarations. in Win7, they mandated that all new code had to comply with a set of requirements for SAL-annotating key scenarios (primarily to reduce the likelihood of buffer overruns). In Win8 they're going further still and are incorporating new SAL annotations for a number of key scenarios. Combined with improved compilers and tools like PreFast (now build into VS 2010 Pro and up), they and you can find and eliminate potential issues before the product is released.
Note that the warnings issues by CA (whichever CA tool you choose to use) will always require overrides - sometimes, there's a really good reason as to why the code has to do what it does. But you should only override if you're ABSOLUTELY sure it's necessary and appropriate. NEVER turn off a warning because you don't understand it and never turn off a warning if you can't be bothered to fix it.

C# Call Graph Generation Tool

I just got a heaping pile of (mostly undocumented) C# code and I'd like to visualize it's structure before I dive in and start refactoring. I've done this in the past (in other languages) with tools that generate call graphs.
Can you recommend a good tool for facilitating the discovery of structure in C#?
UPDATE
In addition to the tools mentioned here I've seen (through the tubes) people say that .NET Reflector and CLR Profiler have this functionality. Any experience with these?

NDepend is pretty good at this. Additionally Visual Studio 2008 Team System has a bunch of features that allow you to keep track of cyclomatic complexity but its much more basic than NDepend. (Run code analysis)

Concerning NDepend, it can produce some usable call graph like for example:
The call graph can be made clearer by grouping its method by parent classes, namespaces or projects:
Find more explanations about NDepend call graph here.

It's bit late, but http://sequenceviz.codeplex.com/ is an awesome tool that shows the caller graph/Sequence diagram. The diagrams are generated by reverse engineering .NET Assemblies.

As of today (June 2017), the best tool in class is Resharper's Inspect feature. It allows you to find all incoming calls, outgoing calls, value origin/destination, etc.
The best part of ReSharper, compared to other tools mentioned above: it's less buggy.

I've used doxygen to some success. It's a little confusing, but free and it works.

Visual Studio 2010.
Plus, on a method-by-method basis - Reflector (Analyzer (Ctrl+R); "Depends On" and "Used By")

SequenceViz and DependencyStructureMatrix for Reflector might help you out: http://www.codeplex.com/reflectoraddins

I'm not sure if it will do it over just source code, but ANTS Profiler will produce a call graph for a running application (may be more useful anyway).