Peter Ritchie's MVP Blog : Visual Studio 2008

DevTeach 2009 Vancouver

PeterRitchie — Thu, 26 Mar 2009 16:33:00 GMT

The schedule for DevTeach 2009 Vancouver has been announced (http://www.devteach.com/). There’s lots of great software development sessions from some of the leaders in our industry.

If you’re planning on improving yourself, this is the conference to go to. Not only can you attend excellent sessions; but you can hob-knob with the presenters and pick their brains.

If you have a friend or co-worker who’s interested, there’s a limited-time two-for-one offer for an even better price: http://www.devteach.com/Register.aspx

Unable To Step Into .NET Source

PeterRitchie — Mon, 24 Nov 2008 20:59:00 GMT

I began getting a problem a while ago that I was unable to step into the .NET source in Visual Studio 2008. It happened suddenly, and I noticed it shortly after installing SP1. Given my observation it appears to be due to upgrading the SP1; but I couldn’t find anyone else not having the same problem. I had another computer where it worked, so I basically put it aside.

Today I had a chance to have a closer look. I had configured 2008 (RTM, not SP1) to get the .NET source based on Shawn Burke’s blog and had not encountered any problems. Once I upgraded to SP1 and checked “enabled .Net source stepping”, I all I ever got when trying to step through source is a dialog asking me for the location of the CS file.

What I had configured was to place the debug symbols into a folder in the Visual Studio 2008 user directory (c:\Documents and Settings\PRitchie\My Documents\Visual Studio 2008\Symbols, for example).

Despite creating a new subdirectory for SP1, I still could not step through the source.

It wasn’t until I moved the directory down the hierarchy that I finally got some joy. I first tried it on the root and it worked fine. I then tried it as a sub directory within my documents and it worked fine. I imagine that the path was longer that 260 and rather than present the user with an error with that detail it assumed it couldn’t find the file it was looking for and asked the user for the location of it. But, I’m guessing.

Hope this helps someone else.

Becoming a Visual Studio Jedi Part 1

PeterRitchie — Tue, 02 Sep 2008 18:49:00 GMT

Becoming a Visual Studio 2008 (and often Visual Studio 2005) Jedi

In much the same grain as James' Resharper Jedi posts, I'm beginning a series of posts on becoming a Visual Studio Jedi. It involves getting the most out of Visual Studio off-the-shelf, doing things as quickly as possible and with as little friction as possible. I think it's useful for all users; but especially useful for those who are in situations where they can't install refactoring tools like Refactor Pro! or Resharper.

First, familiarize yourself with Sara's Visual Studio Tips blog; then subscribe to her blog.

I'll attempt to provide detail at a less granular level than Sara's blog (i.e. using a series of commands to perform a specific task); but I may overlap here and there

Take advantage of Auto-Hide
Like Jimmy Bogard and Jeffery Palermo, I have my Visual Studio UI very lean. 99% of the time, I'm working in code. The Solution Explorer (SE), Properties, Output, etc are auto-hide panes. When I need to use them I hover the mouse over the tab to make them visible, do what I need to do with them, then get back to the code. The Code Editor is the only window that isn't auto-hide or floating.

Navigate find results via keyboard
Whenever anything is displayed in a find results window, you can iterate each item in the list via a keystroke. The default C# keyboard map had F8 and Shift+F8 as the shortcuts for next and previous.

For example:

Press Ctrl+Shift+F to bring up the Find in Files form.
Enter "TODO\:.*refactor" in the "Find what" text box.
Ensure Match case, Match whole word are unchecked.
Ensure Use is checked and has Regular expressions selected.
Press Alt+F to search.

A Find Results window is displayed that shows the results of the search.

F8 goes to the first result.
Pressing F8 again goes to the next.
Pressing Shift+F8 goes to the previous result.

F8 and Shift+F8 work for most lists like Find Results 1, Find Results 2, Error List, Output:Build, etc.

File name extensions when adding classes
Do you find your self selecting text in the file name when you use the Add Class wizard? Or, do you always type ".cs" at the end of your file name? You may be happy to know you don't have to do that. Simply invoke the Add Class wizard and type the name of the class. The wizard adds the missing .cs for you. For example:
Press Alt+P, C
Enter "MyNewClass"
Press Enter
A file MyNewClass.cs is added to your project and it contains class named "MyNewClass".

Consider a Custom toolbar

There's generally only handful of toolbar buttons that you might need, especially if you're a keyboard user like me. There's some things that simply don't have a default keyboard mapping. Another good reason for having a custom toolbar item with only the buttons you use is if you often change the size of your Visual Studio window. The default layout has two or more toolbars (depending on the edition and any add-ins you have installed). You can carefully position those toolbars so they may take up one or two lines; but when you then shrink the size of your window the get wrapped and they won't restore if you expand the size of your window. Having a single toolbar means this wrapping of toolbars can never happen.

Export Settings

Once you get your UI the way you want it, you can actually save the layout.

Click on Tools\Import and Export Settings.
Select Export selected environment settings.

This is really handy if you get into low-resource situations (like the application you're developing or its framework uses up too many GDI handles and Visual Studio can't allocate a handle to display a toolbar or a frame. When this happens Visual Studio actually turns off those GUI elements; when you close and restart those panes/frames are no longer displayed by default.)

Drag and drop of control selections onto forms designer toolbox

PeterRitchie — Thu, 21 Aug 2008 16:43:39 GMT

A while back I blogged about the ability we have in Visual Studio to select text in a text editor and drag it onto the toolbox. Once on the toolbox you could drag those items back into the text editor to effectively “paste” frequently needed snippets of code into other text files.

Imagine my surprise when we didn’t have this ability in the forms designer. When writing code, it’s a bit specious to want to have multiple copies of hard-coded snippets of code (DRY should come to mind). But, for forms, the only alternative is to create user controls to contain commonly-used control groups. User controls is very heavy weight and basically becomes unusable when talking about simple groups of buttons. For example, “OK” and “Cancel” buttons.

So, as a result, I’ve logged a suggestion on Microsoft Connect suggesting this ability be added to Visual Studio.

If you want to see the potential of a feature like this, see http://machine.nukeation.com/preview.html

Working with Resharper's External Annotation XML Files

PeterRitchie — Mon, 21 Jul 2008 20:32:00 GMT

Resharper 4.0 has external annotation XML files that you can create to give Resharper more information about your code. For example, you can tell Resharper that a particular method does not accept a null argument. For example, the following method does not accept a null argument:

using System;

namespace Utility

    public static class Text

        public static int GetLength(String text)

            if (text == null) throw new ArgumentNullException("text");

            return text.Length;

An external annotation file can be created to inform Resharper of this fact and have it warn you when possible null values are passed as an argument:

            String text = null;

            Utility.Text.GetLength(text);

First, you need to create a directory within the Resharper ExternalAnnotations directory. This ExternalAnnotations directory is usually in the form of "%SystemDrive%\Program Files\JetBrains\ReSharper\vBuild#\Bin\ExternalAnnotations" for example "C:\Program Files\JetBrains\ReSharper\v4.0.816.4\Bin\ExternalAnnotations".

The directory we need to create is the same name as our assembly (without the extension). In our case this would be "C:\Program Files\JetBrains\ReSharper\v4.0.816.4\Bin\ExternalAnnotations\Utility".

Next, we need to create an XML file to contain the information required by Resharper. The name of this file is the same as the directory name, plus ".xml". So, the full file name would be "C:\Program Files\JetBrains\ReSharper\v4.0.816.4\Bin\ExternalAnnotations\Utility\Utility.xml". This file essentially has an assembly element with child member elements that provide meta-data about methods and arguments. In our case we want to tell Resharper that the Utility.Text.GetLength(String) method does not accept null values for the argument named "text". To do this we populate the file with the following XML:

<?xml version="1.0" encoding="utf-8" ?>

<assembly name="Utility">

    <member name="M:Utility.Text.GetLength(System.String)">

        <parameter name="text">

            <attribute ctor="M:JetBrains.Annotations.NotNullAttribute.#ctor" />

        </parameter>

    </member>

</assembly>

After restarting Visual Studio, Resharper will now warn that "text", when passed to GetLength, in the following code, has a "Possible 'null' assignment to entity marked with "NotNull" attribute".

            String text = null;

            Utility.Text.GetLength(text);

I've tried this with the GA build and with both Visual Studio 2005 (SP1) and Visual Studio 2008.

For more information about the annotation options, search for AssertionConditionType in the Resharper help and browse around "%SystemDrive%\Program Files\JetBrains\ReSharper\vBuild#\Bin\ExternalAnnotations" for examples.

Drag-copying in Visual Studio Solution Explorer.

PeterRitchie — Fri, 18 Jul 2008 16:46:00 GMT

NOTE: I've tried this in Visual Studio 2008 (VS2k8), I'm assuming the same thing happens in Visual Studio 2005 (VS2k5).

In the process of refactoring, it's *very* common for me to rename a type. This is most easily done by renaming the file in the Solution Explorer (SE)--which renames the file, the type, and and any uses of the type in the entire solution.

Occasionally, I need to create a new type based on another. Copying an abstract type in order to implement the abstract type is often handy--I just fill in the abstract members (and delete "abstract") in the copied type after renaming it.

Drag-copy in the SE seems like it would take care of a couple of steps at once for me: make a copy and rename it. Unfortunately it doesn't do that. It makes a copy of the file (as "Copy of typename.xx") but doesn't rename any types in the class that match the file name.

This might seem somewhat trivial... I can simply rename the file name then refactor rename the type in the file so that the type and all it's constructors are renamed in one fell swoop. Alas, this simply opens a can of worms that can completely confound a newcomer and annoy an expert.

That simple, intuitive method of renaming a copy of a file then the type within the file actually renames *all* types of that name. Since we've just made a copy of the type, that means it's always going rename types in two files. The side-effect of drag-copy in SE means you *must* manually rename the type in the file you just copied. You can do this with search-replace; but that's friction I don't want and really makes SE drag-copy unusable.

I've logged a bug about it on Connect; but the olde "by design" card was played...

Nested Types

PeterRitchie — Tue, 15 Jul 2008 14:47:00 GMT

Recently Michael Features blogged about nested types. The title was almost "nested types considered harmful".

I don't agree. I don't agree that they're any more harmful than any other C# construct (except goto...). Nested types are like anything else in our tool-belt: they have a time and place and can be abused.

But, when to use them? Well, for the most part I agree with Michael, you should avoid them. But, there are times when they're simply the best solution in a given set of circumstances.

Let's look at asynchronous programming model (APM) in .NET.

        // Paraphrased from MSDN

        // Accept one client connection asynchronously.

        public static void DoBeginAcceptTcpClient(TcpListener

            listener)

            // Start to listen for connections from a client.

            Trace.WriteLine("Waiting for a connection...");

            // Accept the connection.

            // BeginAcceptSocket() creates the accepted socket.

            listener.BeginAcceptTcpClient(

                DoAcceptTcpClientCallback,

                listener);

        // Process the client connection.

        public static void DoAcceptTcpClientCallback(IAsyncResult ar)

            // Get the listener that handles the client request.

            TcpListener listener = (TcpListener)ar.AsyncState;

            // End the operation and display the received data on

            // the console.

            TcpClient client = listener.EndAcceptTcpClient(ar);

            // TODO: do something with client.

            // Process the connection here. (Add the client to a

            // server table, read data, etc.)

            Trace.WriteLine("Client connected completed");

In this simple scenario we are getting by with a state of simply a TcpListener object. In a more complex scenario, you'll likely also want a connection-specific queue, some sort of information about what to do after a connection, etc. While you can use existing types of have several collection instance fields to keep track of each of these things; you then have to introduce synchronization of those collections, managing the content of those collections, etc.--it's much easier and safer to send that information on the stack. One method I've tried is simply passing an Object collection as the state; but that quickly becomes hard to manage because of the lack of type-safety on the elements in the array (if I remove an element and replace it with another type, the compile can't know and I'll get a run-time error instead of a compile-time error). To get type safety I generally introduce a new type to aggregate all the types I need in this asynchronous callback. While this new type *could* be reusable by other classes; it likely isn't and I don't want to then be bound that that explicit contract I've signed by making the types publicly available. The only option of not making them publicly available is as private nested types. For example:

        private class AcceptTcpClientParameters

            public CommandQueue CommandQueue { get; private set; }

            public Command NextCommand { get; private set; }

            public TcpListener TcpListener { get; private set; }

            public AcceptTcpClientParameters(int commandQueue, int nextCommand, TcpListener tcpListener)

                CommandQueue = commandQueue;

                NextCommand = nextCommand;

                TcpListener = tcpListener;

        // Accept one client connection asynchronously.

        public static void DoBeginAcceptTcpClient(TcpListener

            listener, CommandQueue commandQueue, Command nextCommand)

            // Start to listen for connections from a client.

            Trace.WriteLine("Waiting for a connection...");

            // Accept the connection.

            // BeginAcceptSocket() creates the accepted socket.

            listener.BeginAcceptTcpClient(

                DoAcceptTcpClientCallback,

                new AcceptTcpClientParameters(commandQueue, nextCommand, listener));

        // Process the client connection.

        public static void DoAcceptTcpClientCallback(IAsyncResult ar)

            AcceptTcpClientParameters parameters = ar.AsyncState as AcceptTcpClientParameters;

            if(parameters == null) return;

            TcpClient client = parameters.TcpListener.EndAcceptTcpClient(ar);

            parameters.NextCommand.Process(parameters.CommandQueue, client);

I find this use of nested types to be more object-oriented (the needs of the DoAcceptTcpClientCallback are abstracted), more intention revealing, better implements Single Responsibility Principle (SRP), better separates concerns, more maintainable and more agile.

Now, to be clear; this is forced set of circumstances. You're using a library that implements the APM (right? You haven't implemented APM yourself...). But, that's my point--nested types are almost essential in a given set of circumstances.

Trace to output window without adding code.

PeterRitchie — Fri, 13 Jun 2008 17:08:00 GMT

Want to trace some run-time data to the output window while debugging without changing and recompiling your code? Use Tracepoints: http://blogs.msdn.com/saraford/archive/2008/06/13/did-you-know-you-can-use-tracepoints-to-log-printf-or-console-writeline-info-without-editing-your-code-237.aspx

No "Add Method Stub" When Passing or Assigning Delegates

PeterRitchie — Fri, 15 Feb 2008 20:45:00 GMT

I finally noticed the other day the "Add method stub" SmartTag wasn't appearing for a new method name I type in. I decided I'd have a closer look...

When you're practicing Test-Driven Development (TDD) you want to write a test for methods before you write the methods. This means you write a test method that calls several other methods that don't exist yet. The Visual Studio IDE, in an effort to promote TDD, recognizes this and when you have your caret over a call to one of these methods a SmartTag shows up and you can select Generate method stub for 'SomeMethod' in 'SomeNamespace.SomeClass'. For example, if you have the following:

    static void Main(string[] args)
    {
        SomeMethod();
    }

...if you place the caret (e.g. click on "SomeMethod") somewhere on "SomeMethod" (and it doesn't exist in the current class) the SmartTag rectangle under the 'S' in SometMethod appears and you can hover your mouse over the word "SomeMethod" and the options icon appears that you can click and select Generate method stub for 'SomeMethod' in 'SomeNamespace.SomeClass', and it will generate a method like the following:

    private static void SomeMethod()
    {
        throw new NotImplementedException();
    }

Well, I figured this would also happen when I tried to assign a non-existent method to a delegate. For example, if I had the following:

    static void Main(string[] args)
    {
        Action action = SomeOtherMethod;
    }

...I would expect that placing the caret over "SomeOtherMethod" that the SmartTag would show up and I would be able to select 'SomeOtherMethod' in 'SomeNamespace.SomeClass' and it would generate a method like the following:

    private static void SomeOtherMethod()
    {
        throw new NotImplementedException();
    }

Alas, the IDE doesn't recognize use of an undeclared method when used with delegates. i.e. it doesn't appear in these circumstances either:

    static void ProcessDelegate(Action action)
    {
        //...
    }
    static void Main(string[] args)
    {
        ProcessDelegate(SomeOtherMethod);
        ProcessDelegate(new Action(SomeOtherMethod));
    }

I thought "Add method stub" would be more useful in these circumstances because you're not explicitly passing arguments to the method so it's more likely that you don't know what signature you need to declare. So, I logged a suggestion for it: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=328782

By the way, the non-generic Action delegate (System.Core.Delegate) is new to .NET 3.5.

Is C++/CLI a Second Class Language with Microsoft?

PeterRitchie — Tue, 29 Jan 2008 16:03:00 GMT

The post frequency on the Visual C++ team blog is reasonably high. Some posts deal with new features that were added to VC++ 2008.

But, is Visual C++ a second-class citizen in the Visual Studio product group? Recently the Visual Studio 2008 Product Comparison was released (don't ask me why it wasn't released at the same time as the products...). In the product comparisons VC++ Express has an inordinate number of features that only it doesn't have. When you look at the Visual C++ 2008 Express Edition product sites, it seems pretty clear that it's geared towards native-only software development. Despite this the product comparison shows VC++ Express has Managed Debugging, Mixed-Mode Debugging and Compiler Support for any CPU (which details "...compile your managed application..."). But, VC++ 2008 Express is the only edition that doesn't support adding reference to WCF services ("Service Reference"), Code Snipped Manager, Code Snippets, Rename Refactoring, Text File (you can't create a plain text file with VC++ 2008 Express?), and one of two editions that doesn't include support for XML File (create a blank XML file), and SQL Server 2005 Compact Edition. As well, only VC++ 2008 doesn't include managed-only features like Object Browser, Object Relational Designer, and SQLMetal (the last two deal with .NET-only LINQ-to-SQL.

C++ has stagnated as a language for quite some time, but Visual C++ 2008 includes new language features like C++0x and TR1 that help evolve the language for the parallel future. But, despite assurances that native development is still a focus at Microsoft, there is the appearance that VC++ just isn't getting the same resources as the other editions. Makes you wonder how much longer will Microsoft keep it in the Visual Studio family...

New Warning CS1060 in C# 3 (Visual Studio 2008)

PeterRitchie — Sun, 09 Dec 2007 22:38:00 GMT

Recompiling C# 2 (Visual Studio 2005) code in C# 3 (Visual Studio 2008), you may incounter a new warning that didn't used to ocur:

Warning CS1060: Use of
possibly unassigned field 'fieldName'. Struct instance variables are initially unassigned if struct is unassigned.

Dealing strictly with syntax, C# let's you declare a value type (struct) with a reference member, for example:

namespace Examples
{
    using System.Drawing;
    public static class Program
    {
        public static void Main()
        {
            LabelEntry labelEntry;
            labelEntry.Location.Point.X = 0;
        }
    }
 
    public struct LabelEntry
    {
        public LabelLocation Location;
        public String Label;
    }
 
    public class LabelLocation
    {
        public Point Point;
    }
}

Unfortunately, in C# 2, and previous, it wouldn't give you an warning if you tried to read a value type reference member before initializing it, as in the highlighted code.

As I've alluded to before, syntactic correctness does not imply conceptional correctness and this warning improves syntax correctness.

If avoiding reference members in structs isn't clear, let me know and I can do a post on that.

New warning CS0809 in C# 3 (Visual Studio 2008)

PeterRitchie — Mon, 26 Nov 2007 20:31:00 GMT

There were several breaking changes (fixes) in C# 3 from C# 2. One is the ability to attribute a member override with ObsoleteAttribute without also attributing it the virtual member in the base class.

For example, the following will compile without error In C# 2 (Visual Studio 2005/.NET 2.0):

using System;

internal class BaseClass

    public virtual void Method()

internal class DerivedClass : BaseClass

    [Obsolete]

    public override void Method()

public static class Progam

    public static void Main()

        BaseClass baseClass = new DerivedClass();

        baseClass.Method();

This same code will generate a CS0809 warning with C# 3.

This change was done because, as you can see in the example, if DerivedClass.Method is accessed via a BaseClass reference, the compiler can't reliably warn you that you're in fact calling an Obsolete method.

In reality, even you you did call DerivedClass.Method() via a DerivedClass reference you still wouldn't get a warning. This may have something to do with a quirk in the way the compiler detects attributes with overrides and virtual methods; but I'm surmising.

The fix, if you have access to the base class, is to attribute bot the base and the derived class member with ObsoleteAttribute. If you don't have access to the base class, you'll have to live with or suppress the warning.

New Contributor to the C# Developer Centre

PeterRitchie — Thu, 25 Oct 2007 22:17:00 GMT

A new contributor to the C# Developer Centre has posted a new article. This article goes into great detail about extension methods, what they are and how they're implemented. If you're more than curious about this feature of the soon-to-be-release Visual Studio 2008 and C# 3.0, it's a great read.

http://msdn2.microsoft.com/en-ca/vcsharp/bb905825.aspx

Web seminars on Visual Studio 2008

PeterRitchie — Thu, 13 Sep 2007 15:43:00 GMT

In the same fashion as Visual Studio 2008, Bill Lodin of IT Mentors is giving Web seminars on Visual Studio 2008. Introducing Microsoft Visual Studio 2008, Microsoft Visual Studio 2008 - Next-Generation Web Applications, and Microsoft Visual Studio 2008 - Rich Windows Client Applications have been presented and recordings can be downloaded for each:

Future web seminars by Bill on Visual Studio 2008 will include:

Microsoft Silverlight and Microsoft Visual Studio 2008
Building Better Web Services with Microsoft Visual Studio 2008
Microsoft ASP.NET AJAX and Microsoft Visual Studio 2008
Web Development with Microsoft Visual Studio 2008
Microsoft Visual Studio 2008 - Office Business Applications.

My Visual Studio 2008 Code Analysis Rules

PeterRitchie — Tue, 04 Sep 2007 16:02:00 GMT

Although a couple of suggestion for changes to existing rules seem to have made it into Visual Studio 2008 Beta 2, unfortunately, none of my suggestions for new Code Analysis rules made it into Orcas Beta 2 (and thus likely not in RTM).

I was holding off on writing my own rules waiting for a stable SDK because I didn't really want to write several different versions of the same rule. But, unfortunately that also wasn't in the cards for Orcas, so I've begun writing a few rules for Visual Studio 2008 that I feel are important.

Some of the rules I've suggested over the years that I've implemented in this Code Analysis add-in are:
DoNotUseCurrentUICultureAsIFormatProviderArgument
I've blogged about issues using CurrentUICulture for formatting and parsing methods (i.e. as an IFormatProvider argument) in the past. The issue is that CurrentUICulture can be assigned a neutral or a specific culture but formatting and parsing requires a specific culture. A neutral culture is one that only specifies language and not region or country. Region and country define the formatting specifications. Using a neutral culture, although syntactically correct, as an IFormatProvider argument will result in an exception.

DoNotLockOnOPubliclyVisibleObjects
This guideline is from from the MSDN documentation (in various places, see http://msdn2.microsoft.com/en-us/library/c5kehkcz(vs.80).aspx for one). Code Analysis already checks for locks on typeof but it doesn't check for locks on this or other public members. DoNotLockOnOPubliclyVisibleObjects checks for lock on "this" (or SyncLock on "Me") as well as direct use of Monitor.Enter/Exit.

I've created some rules for checking some of the issues I've blogged about in the past:
DoNotUseThreadAbort
DoNotUseThreadSleep
DoNotUsesleepWithZeroArgument
...I won't flog that horse more than it's already been flogged...

I created one of many (I hope) C#3/VB9 rules:
AvoidExtensionMethodsThatDuplicateInstanceMethods
In Visual C# Orcas you can write an extension method that has the same signature as an instance method. With the method resolution rules in C# this extension method will never get called; but no warning is issued to that effect. For example:

using System;

using ArrayExtensions;

namespace Application

{

    class Program

    {

        static void Main ( string[] args )

        {

            int[] arr = new int[10];

            arr.SetValue(10, 0);

        }

    }

}

namespace ArrayExtensions

{

    internal static class Extensions

    {

        public static void SetValue ( this Array array, object value, int index )

        {

            array.SetValue(value, index);

        }

    }

}

No warning is given that Extensions.SetValue can never be called as an extension method.

On much the same lines as AvoidExtensionMethodsThatDuplicateInstanceMethods I've also added:
DoNotRecursivelyReferenceProperty
Rather than requesting either of these be added to Code Analysis I'd recommend these checks actually be performed by the compiler (as I have with recursively calling a property). In the meantime, these rules can be flagged as errors in Visual Studio. Syntactically in C# there's nothing wrong with calling a property from itself. This, of course, will result in a StackOverflowException and your application's termination because of the infinite recursion--without warning or error. With DoNotRecursivelyReferenceProperty, there isn't enough metadata to efficiently distinguish between directly calling an object's property from itself or calling another object's property from the same property, so this rule will be raised on code like this:

    class Entity
    {
        private Entity otherEntity;
        private string text;
        String Text
        {
            get
            {
                if (otherEntity != null)
                {
                    return otherEntity.Text;
                }
                else
                {
                    return this.text;
                }
            }
        }
        //...
    }

I don't think this is a bad thing. For one thing it's an unlikely scenario; and another, there's no way to tell if the code might get hit by an infinite recursion (otherEntity could be assigned "this"). In the unlikely event this scenario is legit (i.e. you're checking to make sure the object is not "this") then you can simply add a suppression for this rule where appropriate. For example:

        [System.Diagnostics.CodeAnalysis.SuppressMessage("PRI.Design", "PRICA1001:DoNotRecursivelyReferenceProperty")]
        String Text
        {
            get
            {
                if (otherEntity != null)
                {
                    return otherEntity.Text;
                }
                else
                {
                    return this.text;
                }
            }
        }

Download

The add-ins may be downloaded from here: http://www.peterritchie.com/Hamlet/Downloads/105.aspx

Deployment
After exiting all instances of Visual Studio 2008 Beta 2, simply unzip the contents to "C:\Program Files\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\Rules" and re-load Visual Studio.

Visual Studio 2008 Managed Code Analysis

PeterRitchie — Mon, 27 Aug 2007 20:04:00 GMT

I had a quick look at the managed code analysis (FxCop) rules the other day to see what's new and what's been removed. Unfortunately, one of the analysis engines wasn't able to be "resurrected" in time for the release, so there's a few really useful rules that haven't stayed with Beta 2 the reslease of Visual Studio 2008. Fortunately, there have been some additions too. Fortunately, there is not a deficit, we're up by 12 new rules.

Following are the new rules:

DoNotRaiseExceptionsInUnexpectedLocations
NormalizeStringsToUppercase
SpecifyMarshalingForPInvokeStringArguments
SpecifyStringComparison
UseOrdinalStringComparison
AvoidUnmaintainableCode
ReviewMisleadingFieldNames
AvoidExcessiveClassCoupling
IdentifiersShouldBeCasedCorrectly
IdentifiersShouldBeSpelledCorrectly
IdentifiersShouldDifferByMoreThanCase
IdentifiersShouldNotContainTypeNames
OnlyFlagsEnumsShouldHavePluralNames
ResourceStringCompoundWordsShouldBeCasedCorrectly
ResourceStringsShouldBeSpelledCorrectly
MarkAssembliesWithNeutralResourcesLanguage
RemoveEmptyFinalizers
CatchNonClsCompliantExceptionsInGeneralHandlers
TestForNaNCorrectly
AttributeStringLiteralsShouldParseCorrectly
SecurityTransparentAssembliesShouldNotContainSecurityCriticalCode
SecurityTransparentCodeShouldNotAssert
SecurityTransparentCodeShouldNotReferenceNonpublicSecurityCriticalCode
CatchNonClsCompliantExceptionsInGeneralHandlers

And following are the rules that were removed:

ProvideCorrectArgumentsToFormattingMethods
DisposeMethodsShouldCallBaseClassDispose
DoNotCallPropertiesThatCloneValuesInLoops
DoNotDisposeObjectsMultipleTimes
SpecifyMarshalingForPInvokeStringArguments
DoNotPassLiteralsAsLocalizedParameters
LongAcronymsShouldBePascalCased
ShortAcronymsShouldBeUppercase
AvoidUnnecessaryStringCreation
DoNotConcatenateStringsInsideLoops
SecureGetObjectDataOverrides
AssembliesShouldDeclareMinimumSecurity