---
name: microsoft-docs
description: Consulta la documentación oficial de Microsoft antes de escribir código con SDKs de Azure, librerías de .NET o APIs de Microsoft, en lugar de tirar de memoria. Sirve para verificar que un método existe, comprobar una firma, encontrar un ejemplo que funciona y descartar patrones obsoletos. Úsala al usar una API por primera vez o cuando un error no cuadre con lo que esperabas.
version: 1.0.0
license: CC-BY-4.0
updated: 2026-08-17
---

# Consultar la documentación de Microsoft

Los SDKs de Azure y .NET son el terreno donde un modelo de lenguaje se equivoca
con más aplomo: los nombres son predecibles, las versiones se solapan y cada
renombrado deja años de ejemplos antiguos indexados. El resultado es un método
que suena perfecto, que compila en tu cabeza y que no existe.

La regla es sencilla: **cuando el coste de equivocarse es una hora de depurar,
consultar cuesta diez segundos.**

## Cuándo consultar, sin excusa

- Usas una API **por primera vez**
- El método suena *demasiado* conveniente: `UploadFile` cuando lo real es `Upload`
- Se mezclan versiones del SDK: `CloudBlobClient` (v11) con `BlobServiceClient` (v12)
- El nombre del paquete no sigue la convención (`Azure.*` en .NET, `azure-*` en Python)
- Un error no cuadra con lo que esperabas del código

## Preguntas que devuelven algo

Lo específico funciona; lo genérico devuelve la página de portada.

```text
# Mal
"Azure Functions"

# Bien
"Azure Functions Python v2 programming model"
"Cosmos DB partition key design best practices"
"BlobClient UploadAsync Azure.Storage.Blobs"
```

Añade siempre lo que acota: la **versión** (`.NET 8`, `EF Core 8`), la
**intención** (`quickstart`, `limits`, `overview`) y el **espacio de nombres**
cuando busques una API concreta. El namespace es lo que separa una respuesta útil
de tres páginas de desambiguación.

## Buscar, leer entera o buscar ejemplo

Tres movimientos distintos para tres necesidades distintas:

| Necesitas | Qué haces |
|---|---|
| Saber si existe y cómo se llama | Buscar en la documentación |
| Todos los pasos o todas las opciones | Traer la página completa |
| Ver cómo se usa de verdad | Buscar un ejemplo de código oficial |

Trae la página completa cuando sea un tutorial (necesitas todos los pasos), una
guía de configuración (necesitas todas las opciones) o cuando el extracto de
búsqueda se corte justo donde importaba.

## Errores y qué preguntar

| Síntoma | Consulta |
|---|---|
| El método no existe | `"<Clase> methods <Namespace>"` |
| El tipo no se encuentra | `"<Tipo> NuGet package namespace"` |
| La firma no encaja | `"<Clase> <Método> overloads"` y traer la página entera |
| Aviso de obsoleto | `"<TipoViejo> migration v12"` |
| Falla la autenticación | `"DefaultAzureCredential troubleshooting"` |
| 403 Forbidden | `"<Servicio> RBAC permissions"` |

Para un error, comparar tu código con un ejemplo oficial suele ser más rápido que
leer la referencia: la diferencia salta a la vista y casi siempre está en la
inicialización, no en la llamada que falla.

## Antes de dar por bueno el código

1. Confirmar que el método o el paquete existe
2. Si tiene sobrecargas o parámetros complejos, leer la página completa
3. Buscar un ejemplo que funcione para el caso concreto

Para una consulta simple basta el primero. Para una API que no habías tocado, los
tres.

## Por qué no fiarse de la memoria

Tres razones concretas, no una postura:

- **Está viva.** La documentación refleja el SDK de hoy; el conocimiento de un
  modelo, el de su fecha de corte.
- **Está completa.** Un tutorial trae todos los pasos, incluida la línea de
  configuración que nadie recuerda.
- **Es la fuente.** Cuando la documentación y un ejemplo de Stack Overflow de
  2019 se contradicen, no hay debate.

El coste real de no consultar no es el método inventado —ese lo caza el
compilador—, sino el patrón obsoleto que compila, funciona en desarrollo y
falla el día que alguien retira la versión antigua.