Editorial Policy

Our Commitment

dotnet-guide.com is an independent educational resource for .NET developers. Our goal is to make technical topics understandable through practical tutorials, clear explanations, and examples that readers can examine and adapt.

We aim to distinguish documented framework behavior , tested sample behavior , and implementation guidance . Where a tutorial includes a verified companion project, we explain what was tested, which versions were used, and what remains outside the example's scope. These practices are particularly important for our newer .NET AI tutorials .

Content is published under the dotnet-guide.com brand, and editorial responsibility remains with the site. A successful sample run is evidence for that sample and environment—not a guarantee that every deployment or future package version will behave identically.

How We Create Content

Our typical workflow starts with a developer problem and progresses through research, implementation, review, and publication. The amount of testing depends on the topic and whether a runnable companion project is provided.

Topic Selection

We consider common developer questions, Microsoft and .NET releases, changes in open-source libraries, practical implementation gaps, and feedback from readers. We prioritize topics where a focused explanation or complete working sample can make a meaningful difference.

Research and Reference

We begin with relevant primary sources, such as Microsoft Learn, official .NET and library documentation, SDK and NuGet package information, release notes, and the project's source repository. For protocols such as Model Context Protocol (MCP), we also consult the protocol's own documentation and official SDK materials.

Writing and Code Development

For hands-on guides, code is developed alongside the explanation rather than being treated as decoration. We use the .NET CLI and other suitable development tools to restore, build, test, and run examples where practical. The tutorial identifies important prerequisites and avoids presenting an unverified hypothetical snippet as a tested application.

Editorial Review

Before publication, content is reviewed for clarity, technical consistency, version-specific details, source attribution, and alignment between the explanation and the example. For tutorials with a verified GitHub companion, the published walkthrough is checked against that implementation instead of silently changing the sample to fit the prose.

Code Verification and GitHub Companion Samples

Some tutorials include a complete source project in our public GitHub companion repository . Those projects make it easier to inspect the real implementation, reproduce the documented steps, and see the evidence behind technical claims.

What We Check

• Version baseline: record the applicable .NET SDK, target framework, and important direct NuGet package versions.
• Restore and build: check that a supplied sample can restore and compile in the environment used for verification.
• Deterministic tests: verify predictable program behavior with automated tests where suitable, reporting actual counts rather than assumed coverage.
• Integration or protocol runs: exercise a real database, local model, service, or protocol connection when it is part of the tested scope.
• GitHub CI: document automated checks that ran successfully in the repository; CI coverage is not assumed to include external services or model APIs.
• Scope and limitations: state what was not tested, including optional providers, production deployment, security hardening, or other features not exercised by the sample.

What Our Verification Terms Mean

Build verified means the project compiled in the recorded environment. Deterministically tested refers to passing repeatable tests with known expectations. Integration verified or MCP stdio end-to-end verified refers to an actual connection or protocol run. Live-provider verified means a real provider call was made. CI verified means the stated GitHub Actions checks passed. These are different kinds of evidence and should not be treated as interchangeable.

Where Our Information Comes From

We primarily rely on public technical sources that readers can check themselves. Depending on the topic, these include:

• Microsoft Learn and official .NET API documentation.
• The .NET Blog, ASP.NET Core and Entity Framework Core documentation, and published SDK release notes.
• Official GitHub repositories for .NET, ASP.NET Core, EF Core, and relevant libraries.
• NuGet package metadata, changelogs, and the documentation maintained by package authors.
• Model Context Protocol documentation and the official MCP C# SDK when a tutorial uses MCP.
• Established technical books, conference material, and primary research or vendor documentation where relevant.

We link to official or primary sources where they materially support a technical claim. We also distinguish a third-party project's documented behavior from design choices made in our own educational samples.

Accuracy and Version Tracking

.NET, NuGet packages, cloud APIs, and AI SDKs change over time. Documentation that is accurate for one version may not apply to another. We therefore try to make the tested context visible instead of suggesting that a sample will work unchanged on every future release.

Version-Specific Documentation

Where a tutorial depends on a particular runtime or package API, we identify the relevant .NET version and important package versions in the article or linked companion sample. For our newer verified projects, the repository may also include global.json , project files, package graphs, and recorded verification evidence.

Ongoing Content Updates

We revisit material when releases, reader feedback, or testing reveal meaningful changes. Updates may revise code, add caveats, point to current guidance, or preserve an older-version example as historical reference. Review frequency varies, and an article's published or updated date should not be interpreted as a live compatibility guarantee.

Accuracy and Currency Notice

We make reasonable efforts to keep tutorials accurate and useful, but examples can become outdated or may not cover your particular environment. Verify important details against the current official documentation and perform your own tests, security checks, and operational review before using code in production. If you identify an issue, please contact us .

Use of AI-Assisted Tools

We use AI-assisted tools for research support, drafting, explanation refinement, and code-generation assistance. These tools can help prepare material, but their output is not treated as an authoritative source or proof that code works.

Our publication approach includes human editorial review, primary-source checks, and practical testing where appropriate. AI-generated statements about package APIs, CLI commands, provider features, test results, or execution output are checked before being presented as verified facts. We do not intentionally fabricate test logs or claim that an integration was exercised when it was not.

Editorial decisions about content, scope, corrections, and disclosures remain with dotnet-guide.com. We aim to identify uncertainty and limitations rather than conceal them behind confident technical wording.

Additional Standards for .NET AI Tutorials

Our .NET AI learning hub includes provider-neutral model access, hybrid search, tool-using agents, and Model Context Protocol. AI tutorials need a few additional distinctions because model responses, hosted APIs, and local infrastructure can behave differently from ordinary deterministic code.

Provider and Test Boundaries

We separate a provider adapter that compiles from one that was exercised with a real service. Likewise, a successful unit test does not establish that a cloud endpoint, embedding model, database, or model-assisted workflow was tested unless a corresponding integration run was performed and reported.

Repeatable Tests Versus Model Responses

Deterministic tests validate known inputs and expected behavior. Live language-model results can vary between runs. When a guide includes live-model verification, we describe the tested path and relevant limitations instead of treating one generated answer as a universal guarantee. Where possible, CI tests avoid requiring paid API calls or credentials.

Safe Examples and Production Boundaries

Our newer AI examples prefer synthetic or controlled test data, scoped tool behavior, and explicit handling of unknown or unproven information. We do not publish real API keys in source files. A learning sample is not a certification of production security, privacy, reliability, or compliance.

Examples of These Practices

• Provider-Agnostic Chat Gateway — separates provider-neutral application logic from the providers actually exercised during verification.
• Hybrid Search with EF Core and pgvector — distinguishes deterministic tests from PostgreSQL and embedding integration checks.
• Evidence-First Incident Triage Agent — separates observed evidence, guidance, inference, and unknowns.
• Build Your First MCP Server in C# and .NET — verifies MCP tool discovery and calls over stdio without claiming LLM or remote-MCP integration.

Editorial Independence

Our technical coverage and recommendations are guided by subject relevance, available evidence, practical usefulness, and editorial judgment. We do not present our samples as official implementations from the companies or communities whose technologies they demonstrate.

dotnet-guide.com may earn revenue from display advertising and clearly disclosed affiliate relationships. Such commercial relationships are kept separate from technical conclusions. Where a particular article contains sponsorship or affiliate links, the relevant disclosure should be visible to readers.

What We Are (and What We Are Not)

We are an independent technical education website offering .NET explanations, tutorials, and learning-oriented source examples.

We are not Microsoft, an official certification body, a consulting engagement, or a guarantee of production fitness. Readers should adapt examples to their own requirements and carry out appropriate security, performance, maintenance, licensing, and deployment reviews.

Corrections and Feedback

Technical information can change or contain mistakes. Reports of broken code, obsolete APIs, misleading verification claims, broken links, or unclear explanations are welcome.

Please use our Contact page and include the article URL, the relevant .NET or package version, the problem you found, and any useful error output. We review submissions and correct confirmed issues as appropriate. When an update materially changes a tutorial's implementation or conclusions, we aim to make that change clear to readers.

Frequently Asked Questions