As I said, from an external point of view, the user won't see almost the difference (expect a corner case detailed just after)

From an internal point of view, as the maintainer of this code, this is a big difference. Switching from a readonly to private is important in itself because it is changing the whole semantic access to a field.

In this particular scenario, the readonly vs private is not so obvious, mainly because the class is very small, and It would be difficult to write accidentally to ContentReaderType. But usually, when you have a bigger class, with several methods, partial classes...etc., and you don't want a field of this class to be modified by any method in the class, you can only force this by setting readonly. 

In the case of using attribute with private settter when they are supposed to be only set at constructor time, in fact, private setters for attributes are still displayed in intellisense parameters when using them, even if they are private. It means that It makes the user believe that it can set the attribute, but will later discover that there is a compilation error. Try it yourself, you can write this kind of code, and intellisense will propose you the private set (unlike for regular properties).

```
    public class MyAttribute : Attribute
    {
        public int Toto { get; private set; }
    }

	// Intellisense is proposing Toto = , even if it is not available for set
    [MyAttribute(Toto = 5)]
    public class MyClass
    {
    }
```
I'm using Resharper, so that might be a bug in Resharper parser, but this is something I don't want to see. But I believe this is a reason why all attributes in the .NET Framework are not using private set when the parameter is set at constructor time. But not all attributes in .NET are using readonly for their fields, and this is mainly because they allow subclassing and modifying the based value, even it is sometimes set only at constructor time.

Bottom line is a **private setter doesn't mean readonly**. It still allow to modify the field internally, and this is an enough reason to try to use readonly fields whenever it makes sense and it is possible. Readonly on fields are nice, but I would even love to be able to put readonly on local variable inside methods...