devhome
devhome copied to clipboard
microsoft
Distinguish between versions of Visual Studio to install
Suggested new feature or improvement
Don't recommend installing a SKU of VS2022 when another is already installed
Scenario
on the install applications section of the "end-to-end" setup it suggested "Visual Studio 2022 community Edition" But, I already have the Enterprise and Preview versions of VS2022 installed.
Additional details
At first I thought this was because there was a new update to the version of VS2022 Enterprise that I hadn't yet installed but that's not the case.
See https://github.com/microsoft/devhome/issues/788#issuecomment-1561687716
WinGet doesn't currently have a concept for a set of packages that are logically equivalent.
Visual Studio SKUs are "different" WinGet packages.
I've been thinking about how we can differentiate. This might be an opportunity for a DSC resource to handle detecting "any" Visual Studio package.
The current thinking is that multiple configurations could be present in the ".configurations" directory for the various SKUs. Unfortunately, the user would need to select the right configuration.
default.dsc.yaml - could default to community SKU VSPro.dsc.yaml - could leverage Visual Studio Pro VSEnterprise.dsc.yaml - could leverage Visual Studio Enterprise
Additional complexity arises when more than one SKU is present in terms of which one to "configure".
@denelon , maybe this could be done with something like virtual packages on the package management side instead of configuration? We could have packages that we count as installed if one of a list of others are installed. So, we could have a VisualStudio package that counts as installed if we have any of Community/Pro/Enterprise. It would also help with stuff like just wanting to have a JRE/JDK, or any Python 3. It feels like we could do this in a pretty clean way
Yes, thanks @florelis for bringing this into the discussion as well.
That might help reduce the potential proliferation of changes across the myriad of manifests that have dependencies on languages, runtimes, etc. It's similar to the "provider"/"consumer" model in some other package managers.
