aspire
aspire copied to clipboard
DCP should not pass all environment variables when requesting projects start
When DCP requests the tooling (VS, C# Dev Kit, etc.) launch a project, it passes along all of its environment variables to be used by the new process. Most of theseultimately came from the environment when DCP was launched, and the new process will pick them up from the environment as well; theres no need to pass them or explicitly set them.
The amount of data being passed around can be relatively large--we've see instances of 50 kilobytes. There are cases where VS or C# Dev Kit need to pass this data between processes as part of handling the launch, and we're run into cases where we run into limits on the size of the serialized data.
Limiting DCP to pass only the interesting environment variables would make this situation much less likely.
This requires a change in the Aspire.Hosting code (ApplicationExecutor).
@rafaelldi what do you think about this change? Will it be a problem for Rider if DCP only sends the env vars that are NOT in (or different from) the ambient environment?
I feel like we should re-think the whole launch profile model and maybe just have Aspire.Hosting read the launch profile and just use the DCP for the IDE for the debugging support? Right now we have a weird mix of both sides reading the launch profile and its unclear to me why we need to keep it this way.
Hi! @karolz-ms That shouldn't be a problem for us.
@davidfowl won't that just add one more implementation of launch profile interpretation ;)
The design issue we need to clarify is how DCP will learn what the final environment of the running project is. We might want to extend the process restarted notification to include this information.
Turns out that the size of the data was not the root cause for the issues we have seen. Parking this for now.