Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
When developing with Aspire locally and deploying to Kubernetes, sharing files between services requires fundamentally different approaches, breaking the abstraction that Aspire provides.
Current workaround:
- Local development: Services running directly on the host and containers use bind mounts or direct filesystem access to share files
- Kubernetes deployment: Services run in containers and use PersistentVolumeClaims (PVCs) to share files
This means developers must maintain two separate configurations and understand the nuances of each deployment target.
Additional limitations:
- BindMounts are not supported by the Kubernetes publisher
- Local Docker services cannot share volumes with each other (only host bind mounts work)
- Even with ProjectResourceV2 enabling C# to run as a container, there's no unified abstraction for file sharing (use of bind mounts is still breaking as k8s publisher crashes)
Describe the solution you'd like
Introduce a unified abstraction for shared file storage (e.g., SharedVolume, SharedFileStorage, or similar resource type) that:
-
Works consistently across deployment scenarios:
- Local development: handles bind mounts and/or volume mounting between containers
- Kubernetes: translates to PersistentVolumeClaims
- Other deployment targets: adapts appropriately
-
Enables simple service-to-service file sharing:
var sharedStorage = builder.AddSharedVolume("app-data");
builder.AddContainer("service1").WithVolume(sharedStorage);
builder.AddContainer("service2").WithVolume(sharedStorage);
-
Abstracts away deployment-specific details: Developers write code once and it works across local Docker, Kubernetes, and other targets without configuration changes.
-
Works regardless of whether services are containers or directly-hosted: Whether a service is a .NET app running on the host, a C# container, or any other type of service, they can all reference the shared volume.
Additional context
Real-world scenario:
A C# application running locally through Aspire shares files with a containerized service. Currently:
- Locally: host path is bind-mounted to the container, and C# app references the path directly (since it runs on the host)
- In production: both run as containers with a PVC shared between them
ProjectResourceV2 will help by allowing C# to run as a container, but it doesn't solve the broader abstraction problem. File sharing still requires manual configuration changes between deployment targets.
This feature would enable true "write once, deploy anywhere" semantics for file sharing scenarios.
Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
When developing with Aspire locally and deploying to Kubernetes, sharing files between services requires fundamentally different approaches, breaking the abstraction that Aspire provides.
Current workaround:
This means developers must maintain two separate configurations and understand the nuances of each deployment target.
Additional limitations:
Describe the solution you'd like
Introduce a unified abstraction for shared file storage (e.g.,
SharedVolume,SharedFileStorage, or similar resource type) that:Works consistently across deployment scenarios:
Enables simple service-to-service file sharing:
Abstracts away deployment-specific details: Developers write code once and it works across local Docker, Kubernetes, and other targets without configuration changes.
Works regardless of whether services are containers or directly-hosted: Whether a service is a .NET app running on the host, a C# container, or any other type of service, they can all reference the shared volume.
Additional context
Real-world scenario:
A C# application running locally through Aspire shares files with a containerized service. Currently:
ProjectResourceV2 will help by allowing C# to run as a container, but it doesn't solve the broader abstraction problem. File sharing still requires manual configuration changes between deployment targets.
This feature would enable true "write once, deploy anywhere" semantics for file sharing scenarios.