Closed mrlacey closed 5 months ago
grochocki
commented
5 months ago Thank you for the detailed write-up! Super helpful to have documented for future reference.
To allow installing on Community, Professional, and Enterprise versions, it's only necessary to specify that the extension can be installed on the Community version.
Is this an optimization we can make in the VS2017/2019 manifest as well?
mrlacey
commented
5 months ago To allow installing on Community, Professional, and Enterprise versions, it's only necessary to specify that the extension can be installed on the Community version.
Is this an optimization we can make in the VS2017/2019 manifest as well?
Yes - but I don't have vs2017 installed anywhere to test it
For #466 and #479
Description:
The VS 2022 extension had a mismatch between the minimum supported version and the referenced SDK version. This meant it was possible to install on a version of VS that contained an older version of the SDK than the one the extension uses and was compiled against.
This PR contains two changes:
1. It sets the minimum install version to match the referenced SDK version. Currently 17.8.
(It's ok only to match the major and minor parts of the version number as there is only one 17.8.* version of the SDK.)
The manifest was configured to allow installation on v17.0 or above, but the SDK the extension referenced a newer version.
When the extension (package) loads, it tries to load the reference assemblies based on the version it was compiled with. If the assembly it tries to load isn't compatible with what it expects (e.g. there has been a breaking change in the binary compatibility or APIs) the package will fail to load and throw an exception like that seen in #466.
While the above is not apparent from the error messages (nor documented--AFAIK), it makes sense once you know what's happening.
Yes, it would be nice to have an analyzer or similar build-time check to avoid inconsistencies in these two numbers that might cause errors. (I doubt MS will ever make one, and it hasn't gotten high enough up my to-do list for me to make something.)
If there's a reason to support installing on older versions of VS, the referenced SDK version should be changed to match the minimum supported version.
(I've checked the VS2019 versions, and they're the same--both 15.0)
2. It removes unnecessary install targets.
If you allow installing on the Community version of VS, this really means "Community or higher" and this includes Professional and Enterprise. Similarly, if you allow installing on the Professional version, this also allows installing in the Enterprise version.
To allow installing on Community, Professional, and Enterprise versions, it's only necessary to specify that the extension can be installed on the Community version.
Because of this, I have removed the Professional and Enterprise specific install target entries as they're not needed.
In earlier versions of VS, it was more common to make extensions available only to some SKUs. It's now much more common to make 3rd party extensions available to all. MS also claim that all functionality between Community and professional should be the same and it's really only licensing that the difference between the two. There are also only a few things that the Enterprise version has that the others don't. Unless creating an extension that relies or builds upon one of these features there should be no real reason not to only target the Community version.
Checklist: