Is it good practice to use the [Deprecated] attribute to instruct developers not to use parts of the API

Question

Recently, I wrote some serializable object, which also deals with specific logic and has a specific life cycle. For it to work correctly, it must be created using the appropriate constructor, which takes the required arguments. However, for serialization purposes, I also need to add a public default constructor.

The object will be publicly available by our API, and third-party developers should be able to create and use it. Although there will be appropriate documentation on how to properly manipulate this object, this does not guarantee that someone will be tempted to use the wrong constructor, and then problems will arise.

I am looking for a neat way to apply some guidelines while third-party developers write their code. The Obsolete attribute occurred to me - I could annotate the serialization constructor with the corresponding comment as a message. Then the message appears in the output warnings and directs the developer to the desired line of code. In addition, the use of the constructor will be appropriately highlighted by both Visual Studio and any code verification addition.

What bothers me with this approach is that the purpose of the Obsolete attribute is completely different. This semantic meaning is that the decorated item is outdated and is likely to be removed in other versions. This is not true in the serialization constructor script, and there will be a mismatch between the use and value of this attribute. Not to mention the option "handle warnings as errors", which may be included in some development departments ...

So the question is, is this an acceptable practice for this use of the attribute? Are there any other legal and universal ways to achieve the same effect (universal I do not mean relying on additions to third-party code verification, etc. - I do not control who uses the code and what is their setting)?

---

As for the comments in the answer below (which is still useful to me), I should clarify that I am using the default protected constructor in the inherited class. The constructor supports XML serialization, but should not be used to initialize a class in business logic. Class inheritance should call some of the other base constructors, and developers who inherit inherited classes should be aware of this. However, developers receiving this code should also have the means to serialize XML for their inherited classes, if necessary.

Answer 1

Hm, I do not think this is a good solution. However, do you really need a default constructor?

Note that there are methods in the serialization API for creating uninitialized instances without using any constructor (see MSDN: FormatterServices.GetUninitializedObject ).

In addition, the regular serialization constructor is not the default constructor, but uses SerializationInfo and StreamingContext. If you have any kind of custom serialization, you can also solve your problem by creating an internal default constructor and using InternalsVisibleToAttribute to build the serialization.