Skip to main content

managedcode-storage

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.

Source facts

Repository
managedcode/dotnet-skills
Last source activity
August 19, 2026 at 14:47
Detected SKILL.md language
English
Stars
499
Forks
40

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
2 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
managedcode-storage
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.
compatibility
Requires a .NET application that integrates ManagedCode.Storage or evaluates it as a storage abstraction.
# 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 project really benefits from a storage abstraction and is not hiding provider-specific behavior it still needs - storage configuration is centralized and explicit - code reviews check real read and write paths, not only registration snippets - after a `10.0.7` upgrade, Azure upload metadata and content-type round trips are covered by a focused integration test
View on GitHub