Inheriting comments from an interface in an implementing class?

Suppose I have this interface

public interface IFoo
{
    ///<summary>
    /// Foo method
    ///</summary>
    void Foo();

    ///<summary>
    /// Bar method
    ///</summary>
    void Bar();

    ///<summary>
    /// Situation normal
    ///</summary>
    void Snafu();
}

And this class

public class Foo : IFoo
{
    public void Foo() { ... }
    public void Bar() { ... }
    public void Snafu() { ... }
}

Is there a way, or is there a tool that can let me automatically put in the comments of each member in a base class or interface?

Because I hate re-writing the same comments for each derived sub-class!

You can always use the <inheritdoc /> tag:

public class Foo : IFoo
{
    /// <inheritdoc />
    public void Foo() { ... }
    /// <inheritdoc />
    public void Bar() { ... }
    /// <inheritdoc />
    public void Snafu() { ... }
}

Using the cref attribute, you can even refer to an entirely different member in an entirely different class or namespace!

public class Foo
{
    /// <inheritdoc cref="System.String.IndexOf" />
    public void Bar() { ... } // this method will now have the documentation of System.String.IndexOf
}

Use /// <inheritdoc/> if you want inheritance. Avoid GhostDoc or anything like that.

I agree it is annoying that comments are not inherited. It would be a fairly simple add-in to create if someone had the time (i wish i did).

That said, in our code base we put XML comments on the interfaces only and add extra implementation comments to the class. This works for us as our classes are private/internal and only the interface is public. Any time we use the objects via the interfaces we have full comments display in intellisence.

GhostDoc is good start and has made the process easier to write comments. It is especially useful keeping comments up-to-date when you add/remove parameters, re-run GhostDoc and it will update the description.

GhostDoc does exactly that. For methods which aren't inherited, it tries to create a description out of the name.

FlingThing() becomes "Flings the Thing"

Java has this, and I use it all the time. Just do:

/**
 * {@inheritDoc}
 */

And the Javadoc tool figures it out.

C# has similar marker:

<inheritDoc/>

You can read more here:

http://www.ewoodruff.us/shfbdocs/html/79897974-ffc9-4b84-91a5-e50c66a0221d.htm

I would say to directly use the

/// <inheritdoc cref="YourClass.YourMethod"/>  --> For methods inheritance

And

/// <inheritdoc cref="YourClass"/>  --> For directly class inheritance

You have to put this comments just on the previous line of your class/method

This will get the info of your comments for example from an interface that you have documented like :

    /// <summary>
    /// This method is awesome!
    /// </summary>
    /// <param name="awesomeParam">The awesome parameter of the month!.</param>
    /// <returns>A <see cref="AwesomeObject"/> that is also awesome...</returns>
    AwesomeObject CreateAwesome(WhateverObject awesomeParam);

ReSharper has an option to copy the comments from the base class or interface.

Another way is to use the <see /> XML documentation tag. This is some extra effort but works out of the box...

Here are some examples:

/// <summary>
/// Implementation of <see cref="IFoo"/>.
/// </summary>
public class Foo : IFoo
{
	/// <summary>
	/// See <see cref="IFoo"/>.
	/// </summary>
	public void Foo() { ... }

	/// <summary>
	/// See <see cref="IFoo.Bar"/>
	/// </summary>
	public void Bar() { ... }

	/// <summary>
	/// This implementation of <see cref="IFoo.Snafu"/> uses the a caching algorithm for performance optimization.
	/// </summary>
	public void Snafu() { ... }
}

Update:

I now prefer to use /// <inheritdoc/> which is now supported by ReSharper.

I ended up creating a tool to post-process the XML documentation files to add support for replacing the <inheritdoc/> tag in the XML documentation files themselves. Available at www.inheritdoc.io (free version available).

Well, there is a kind of native solution, I found for .NET Core 2.2

The idea is to use <include> tag.

You can add <GenerateDocumentationFile>true</GenerateDocumentationFile> your .csproj a file.

You might have an interface:

namespace YourNamespace
{
    /// <summary>
    /// Represents interface for a type.
    /// </summary>
    public interface IType
    {
        /// <summary>
        /// Executes an action in read access mode.
        /// </summary>
        void ExecuteAction();
    }
}

And something that inherits from it:

using System;

namespace YourNamespace
{
    /// <summary>
    /// A type inherited from <see cref="IType"/> interface.
    /// </summary>
    public class InheritedType : IType
    {
        /// <include file='bin\Release\netstandard2.0\YourNamespace.xml' path='doc/members/member[@name="M:YourNamespace.IType.ExecuteAction()"]/*'/>
        public void ExecuteAction() => Console.WriteLine("Action is executed.");
    }
}

Ok, it is a bit scary, but it does add the expected elements to the YourNamespace.xml.

If you build Debug configuration, you can swap Release for Debug in the file attribute of include tag.

To find a correct member's name to reference just open generated Documentation.xml file.

I also assume that this approach requires a project or solution to be build at least twice (first time to create an initial XML file, and the second time to copy elements from it to itself).

The bright side is that Visual Studio validates copied elements, so it is much easier to keep documentation and code in sync with interface/base class, etc (for example names of arguments, names of type parameters, etc).

At my project, I have ended up with both <inheritdoc/> (for DocFX) and <include/> (For publishing NuGet packages and for validation at Visual Studio):

        /// <inheritdoc />
        /// <include file='bin\Release\netstandard2.0\Platform.Threading.xml' path='doc/members/member[@name="M:Platform.Threading.Synchronization.ISynchronization.ExecuteReadOperation(System.Action)"]/*'/>
        public void ExecuteReadOperation(Action action) => action();

End the question:
This feature has been added at VS2019 v16.4.

https://developercommunity.visualstudio.com/t/608809#T-N875117

It works on the interfeace and abstruct class overrideable members