# Managedcode Storage

Use ManagedCode.Storage when a .NET application needs a provider-agnostic storage...

- Repository: https://github.com/managedcode/dotnet-skills (500 stars)
- Category: Testing
- License: MIT
- Last updated: 2026-10-29
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add managedcode/dotnet-skills --skill managedcode-storage -g -a claude-code -y`
Codex: `npx skills add managedcode/dotnet-skills --skill managedcode-storage -g -a codex -y`
Cursor: `npx skills add managedcode/dotnet-skills --skill managedcode-storage -g -a cursor -y`
Gemini CLI: `npx skills add managedcode/dotnet-skills --skill managedcode-storage -g -a gemini-cli -y`

## Description

Use ManagedCode.Storage when a .NET application needs a provider-agnostic storage abstraction with explicit configuration, container selection, upload and download flows, and backend-specific integration kept. USE FOR: integrating ManagedCode.Storage into a .NET application; reviewing how a project abstracts file or object storage; deciding whether to centralize storage provider. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# ManagedCode.Storage

## Trigger On

- integrating `ManagedCode.Storage` into a .NET application
- reviewing how a project abstracts file or object storage
- deciding whether to centralize storage provider differences behind one library
- documenting upload, download, container, or blob-handling flows with ManagedCode.Storage

## Workflow

1. Identify the actual storage use case:
   - blob or file storage
   - provider abstraction across environments
   - app-service integration and configuration
2. Verify whether the project wants one storage contract instead of provider-specific SDK calls scattered across the codebase.
3. Keep application code dependent on the library abstraction, not directly on backend-specific storage SDKs unless a provider-only feature is truly required.
4. Centralize provider configuration, credentials, and container naming in composition-root code and typed settings.
5. Validate the real upload, download, existence-check, and deletion flows after wiring the library.

```mermaid
flowchart LR
  A["Application service"] --> B["ManagedCode.Storage abstraction"]
  B --> C["Provider-specific storage implementation"]
  C --> D["Blob or object storage backend"]
```

## Current Upstream Notes

- `ManagedCode.Storage` `10.0.7` fixes Azure upload metadata. Upgrade all selected provider packages together, then verify Azure upload/download paths preserve the intended content type and custom metadata rather than relying on a successful byte upload alone.

## Deliver

- concrete guidance on when ManagedCode.Storage is the right abstraction
- wiring guidance that keeps provider concerns out of business code
- verification steps for the storage flows the application actually uses

## Validate

The rest: https://github.com/managedcode/dotnet-skills/blob/HEAD/catalog/Libraries/ManagedCode-Storage/skills/managedcode-storage/SKILL.md