Closed jgsogo closed 5 years ago
Some ideas that come to my mind:
.dll
, one for each incompatible VS version and load one of them dynamically from a third DLL (the one that is actually loaded by VS) depending on the VS version. All these DLLs should be packed inside the same vsix
so we keep just one extension in the marketplaceVCProject
to retrieve its properties (configuration values like toolset
, runtime
,...). We might we able to retrieve these properties using the original Project
object.Please, suggest your ideas, all of them will be more than welcome.
Consider raising this issue in gitter.com/extendvs
which is the best channel for community developers working on VS Extensions. Maybe others there have experience with this.
If changing the implementation to avoid the cast to VCProject
is a possibility I see it as the less problematic and easy to maintain way. But I assume, if you have open this issue and not just fixed it, that it is not that easy.
@solvingj for me gitter.com/extendvs
redirects to the http://www.goinfotek.com/ which seems to be something unrelated
Check this url: https://gitter.im/Microsoft/extendvs, I've already asked there, but without success.
Current efforts trying to make the extension compatible with VS2015 have arrived at a dead-end. There is an incompatibility regarding
VCProjectEngine.dll
for different versions of the library that is shipped with different versions of Visual Studio and the casting fromProject.object
toVCProject
fails for one version or the other.Here there are some useful links that are interesting to read: https://github.com/conan-io/conan-vs-extension/pull/75#issuecomment-505465228
I'm opening this issue to think about alternatives and decide the roadmap for it.
Thanks