As we all know that EF Core is new and co-exists with EntityFramework, it becomes very difficult to find the classes mentioned / introduced in the documentation. For e.g. in the attached link, we're talking about NotMapped Attribute, now the first fact the user needs to know to implement this is to import the Namespace, which unfortunately is not mentioned in the article.
Likewise, assembly Name is required to make assembly references. And inheritance hierarchy is required many a times to use the BaseClasses.
Being new to .Net Core, i've found this to be challenging many a times and hence request everyone to please implement this.
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
@Praveen-Rai When creating documentation there is always a need to balance the level of detail with the goal of the documentation. Adding too much detail around peripheral/basic things can result in an excess of verbosity and obscure the main point of the documentation. For example, when showing C# constructs we assume that the reader either already knows C# or will find information about it elsewhere.
For the case of namespaces and packages (i.e. assemblies), in most cases where the namespace is a common EF namespace and is contained in an EF package, then we leave this out because adding the info would be noise for most people. This especially true these days with good tooling support in modern IDEs for resolving namespaces.
With regard to types such as data annotations that come from non-EF packages, I think it is valid to say we should document at least which package is needed to get the type. We will look at doing this.
Since most often the only required namespace is Microsoft.EntityFrameworkCore, we should make sure the step of adding it is very prominent in the getting started material.
If you guys left well enough alone and kept consistent libraries and namespaces, there would be no need to update the correct ones in your documentation. But because you're constantly changing everything in Microsoft ivory tower land, with no sense of business costs and change management and other retooling costs in our time and money, complete code is mandatory, and cutting corners is very definitely not an option!
Verified that the namespace is shown in the getting started material.
Most helpful comment
@Praveen-Rai When creating documentation there is always a need to balance the level of detail with the goal of the documentation. Adding too much detail around peripheral/basic things can result in an excess of verbosity and obscure the main point of the documentation. For example, when showing C# constructs we assume that the reader either already knows C# or will find information about it elsewhere.
For the case of namespaces and packages (i.e. assemblies), in most cases where the namespace is a common EF namespace and is contained in an EF package, then we leave this out because adding the info would be noise for most people. This especially true these days with good tooling support in modern IDEs for resolving namespaces.
With regard to types such as data annotations that come from non-EF packages, I think it is valid to say we should document at least which package is needed to get the type. We will look at doing this.