dotnet / vscode-dotnet-runtime

VSCode Extension for Installing .NET via VS Code
MIT License
127 stars 230 forks source link

Allow user to set which runtime to install in runtime acquisition #211

Closed captainsafia closed 3 weeks ago

captainsafia commented 3 years ago

The dotnet-runtime acquisition installer currently installs the Microsoft.NETCore.App shared runtime if the installRuntime flag is set.

https://github.com/dotnet/vscode-dotnet-runtime/blob/112e74c75ff15e7951860749fb46e4ff53d4bfa0/vscode-dotnet-runtime-library/src/Acquisition/AcquisitionInvoker.ts#L83-L85

It should be possible to customize which of the shared runtimes should be installed via the properties provided to the dotnet.acquire command. I couldn't see a way to do this at the moment.

cc: @sfoslund

sfoslund commented 3 years ago

@captainsafia which other runtime do you need? My first instinct is that we won't be able to fulfill this feature request since it would require reworking how we manage and store our installs to account for both the runtime type as well as version.

captainsafia commented 3 years ago

We use the installer extension to install the runtime which is needed to launch a a debugging proxy that is needed to support debugging Blazor WASM apps in VS Code. The debugging proxy relies on the Microsoft.AspNetCore.App shared framework.

Was the change to install just Microsoft.NETCore.App runtime recent? I believe this used to install all the runtimes around 2 months ago.

sfoslund commented 3 years ago

No, we have always installed only the net core runtime. The installRuntime flag you pointed out was added recently for the SDK extension that is also using this library, but it had no effect on the runtime extension.

captainsafia commented 3 years ago

Do you have recommendations for how to work around this?

I see the SDK extension is not recommended for use outside of the Education bundle but it looks like that will install all the shared frameworks alongisde the SDK.

Are there other options?

sfoslund commented 3 years ago

Yes, the SDK extension should definitely not be used here, it's for education bundle use only. How does the blazor extension handle this right now, or is this a new problem? @NTaylorMullen do you know of any other extensions that require more than the net core runtime?

NTaylorMullen commented 3 years ago

@NTaylorMullen do you know of any other extensions that require more than the net core runtime?

I do not

sfoslund commented 3 years ago

@captainsafia the goal of this extension is to stop reuse across multiple extensions, so if blazor is the only extension that would require this functionality I don't see this as a high enough priority feature request to address. Are you able to make your extension self contained (bundle the aspnet runtime into the extension)?

NTaylorMullen commented 3 years ago

@captainsafia the goal of this extension is to stop reuse across multiple extensions, so if blazor is the only extension that would require this functionality I don't see this as a high enough priority feature request to address. Are you able to make your extension self contained (bundle the aspnet runtime into the extension)?

Is the capability not already part of the powershell script?

captainsafia commented 3 years ago

Are you able to make your extension self contained (bundle the aspnet runtime into the extension)?

We could, but it's not ideal.

Is the capability not already part of the powershell script?

Yes, the dotnet-install script supports this via:

$ ~/Downloads/dotnet-install.sh --runtime aspnetcore --runtime dotnet

My first instinct is that we won't be able to fulfill this feature request since it would require reworking how we manage and store our installs to account for both the runtime type as well as version.

Can you clarify this bit? What additional logic would be needed to distinguish runtime type/version for installs?

sfoslund commented 3 years ago

Yes, the install script is capable of this so the actually downloading of different runtimes would be simple. The problem is in how we will differentiate and manage multiple runtime types without breaking existing users.

I imagine we'd have to change our file structure and how we track installed runtimes. Right now when a runtime install is requested we simply save the version in our records and install the runtime into a dir of the format {vscode storage}\{ runtime version }\dotnet...`. If we have to manage multiple runtime types we will have to make sure they are separated so that we don't break in the case of one extension requesting version x of the net core runtime and another extension requesting the exact same version of the aspnet runtime. As a result, we'd have to change both our install records and the directory where the runtime is stored to include the runtime type.

Overall, I do think this is something that could be implemented but we would have to be very careful not to break existing users. Also, it's a matter of cost. Since this is the first time we've had this feature request and my team is working through higher priority issues right now I doubt we would have the capacity to do this work until the fall at the soonest. If you would be willing to contribute the feature I'd be happy to discuss designs and do the code review.

bobbytreed commented 9 months ago

Is there any update to this feature? Is there support in this extension or another to fulfill this request. The .NET Install tool has been extremely beneficial to me as an extension author to support multiple platforms while always ensuring that our language server can run effectively. As newer features are discussed, it would be nice to be able to specify additional runtimes (specifically AspNetCore at the moment).

Thanks!

baronfel commented 3 weeks ago

Closing in favor of https://github.com/dotnet/vscode-dotnet-runtime/issues/1763 instead.