Fix vs2015

[SSE4]

closes #66

[jgsogo]

Testing in a VM with only VS2015 installed (no 2017 or 2019 installed before) is needed. Working in 2015 is not required for the first version.

[SSE4]

checked on VM with only VS2015 installed, works flawlessly

[Gernatch]

@jgsogo Do you think this will make it to 1.1? We have someone having this issue and I would like to see if this resolves. Or is there a VSIX I could supply with this change for testing?

[SSE4]

@Gernatch you may try to install from here: https://ci.appveyor.com/project/ConanOrgCI/conan-vs-extension/builds/25177464/artifacts
please let us know if it works for you

[SSE4]

a bit beautified output:

    <description>Client rights determined: {"CurrentClientRights":{"ActivityId":"5210f107-241d-4d79-8eab-7b55ae79ab1c".
"AuthorizedVsEdition":2.
"AuthorizedVsEdition2":300.
"CrtokenDaysToExpire":30.
"DaysSinceCreation":0.
"DaysToExpire":30.
"IsLicenseGood":true.
"IsSubscriptionBased":true.
"IsTrialLicense":false.
"LicenseDescription":"MSDN Subscription".
"LicensedUserId":"ac88aa23-e23a-40f2-b1b4-4454e89428a0".
"LicensedUserName":"username@company(edited this).com".
"LicenseSource":1.
"LicenseSource2":1.
"LicenseStatus":4.
"LicenseType":12.
"LicenseUrl":"".
"LicensingAccount":"".
"MayUplevel":false.
"ReleaseType":1.
"RightsDaysToExpire":2147483647.
"RightsStatus":10.
"SubscriptionChannel":"VL".
"ClientRightsMetadata":{"SubscriptionChannel":"VL".
"NonLocalizedLicenseDescription":"MSDN".
"LicenseUrl":"".
"ExpirationDate":"\/Date(1563371882000)\/".
"ClientRightsVersion":{"Major":15.
"Minor":0.
"Build":28307.
"Revision":705.
"MajorRevision":0.
"MinorRevision":705}}}.
"CurrentLicenseSource":1.
"CurrentLicenseSource2":1.
"IDEUserClientRights":{"ActivityId":"5210f107-241d-4d79-8eab-7b55ae79ab1c".
"AuthorizedVsEdition":2.
"AuthorizedVsEdition2":300.
"CrtokenDaysToExpire":30.
"DaysSinceCreation":0.
"DaysToExpire":30.
"IsLicenseGood":true.
"IsSubscriptionBased":true.
"IsTrialLicense":false.
"LicenseDescription":"MSDN Subscription".
"LicensedUserId":"ac88aa23-e23a-40f2-b1b4-4454e89428a0".
"LicensedUserName":"username@company(edited this).com".
"LicenseSource":1.
"LicenseSource2":1.
"LicenseStatus":4.
"LicenseType":12.
"LicenseUrl":"".
"LicensingAccount":"".
"MayUplevel":false.
"ReleaseType":1.
"RightsDaysToExpire":2147483647.
"RightsStatus":10.
"SubscriptionChannel":"VL".
"ClientRightsMetadata":{"SubscriptionChannel":"VL".
"NonLocalizedLicenseDescription":"MSDN".
"LicenseUrl":"".
"ExpirationDate":"\/Date(1563371882000)\/".
"ClientRightsVersion":{"Major":15.
"Minor":0.
"Build":28307.
"Revision":705.
"MajorRevision":0.
"MinorRevision":705}}}.
"PIDClientRights":{"LicenseSource":0.
"LicenseSource2":0.
"IsSubscriptionBased":false.
"DaysSinceCreation":-1.
"LicenseType":2.
"AuthorizedVsEdition":2.
"AuthorizedVsEdition2":300.
"DaysToExpire":-1.
"IsLicenseGood":false.
"LicenseDescription":"30 day trial (for evaluation purposes only)".
"LicenseStatus":-1.
"LicenseUrl":"".
"MayUplevel":false.
"LicensedUserId":"00000000-0000-0000-0000-000000000000".
"LicensedUserName":"".
"LicensingAccount":"".
"ReleaseType":1}}; Account identity provider: AAD</description>

[Gernatch]

@SSE4 I tried to delete my reply. Wasn't quick enough. Somehow my VS key became deactivated... or I was switched to a 30day MSDN subscription without realizing it. Sorry for the confusion.

I am seeing the netstandard error that was fixed on PR #89. That is the real cause of the issue. I assume this will be a non issue when this is all merged together.

PS: Will beautify future output ;P

[SSE4]

@Gernatch so to confirm, does it work for you with just #89 applied, or only with both #89 + #75?

[Gernatch]

@SSE4 Each individually. I install the #89 using the VSIX, it works. I do the same for #75, it does not. Note again I'm running a VS2017 version.

[jgsogo]

So, you are not blocked by this PR which is targeting VS2015, right?

I think we can release v1.1 (main change is #89) this week and leave #85 for the next one (it is one of the major/breaking changes I think we need to implement asap).

[kkripa84]

@SSE4 I see issues with this extension when I installed in VS2017 15.0.0 +26228.57 version.

After install, I clicked continue with the error message

Error I see in my activitylog

Could not load file or assembly 'Microsoft.VisualStudio.Threading, Version=15.6.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. File name: &

Assembly binding logging is turned OFF.

[jgsogo]

@SSE4, can you merge dev, please. We will try to merge this for v1.1 too. Thanks

[SSE4]

@jgsogo done

[jgsogo]

Thanks! I'll test it in clean Windows + VS2015 installation. If anyone else wants to try, here it is the link to the artifact: https://ci.appveyor.com/api/buildjobs/0ch7aaf8wak0ngym/artifacts/Conan.VisualStudio%2Fbin%2FRelease%2FConan.VisualStudio.vsix

[jgsogo]

Tested with:

• VS 2015 Community Update 3, installed in a VM from scratch only with Visual C++. It works 👌
• VS 2019, it doesn't run 😞

[jgsogo]

VS2019 fails in my machine 😞 , but VS2015 works

[Gernatch]

Kripa (above) tried installing this today. It seems like it loaded, but all functionality seems to be disabled. @kkripa84 is that right?

[jgsogo]

This fails casting the Project to a VCProject (we need to convert it to a C++ type project to get its configuration and so). The VCProject relies on the VCProjectEngine.dll which is different from version to version (at least I found them to be incompatible between 14 and 16, which is the change needed from VS2015 to VS2019).

Not a bug: https://developercommunity.visualstudio.com/content/problem/568/systeminvalidcastexception-unable-to-cast-com-obje.html

There are some ideas to follow:

• Check against the UUID: C++ projects are not identified as such when running in VS 2017 RC VioletGiraffe/cppcheck-vs-addin#156 Not useful here, we not only to know it is a C++ project, but also we need to d the actual cast to retrieve its properties
• Here they suggest different extensions for different VS versions: https://stackoverflow.com/questions/44288050/typecast-fails-when-visual-studio-extension-uses-reference-to-older-assembly
• The most promising one (to ensure compatibility now and then) is to split the Extension into different assemblies, so we keep the logic in a single one and build different assemblies for each VS version: http://www.visualstudioextensibility.com/2014/07/01/strategies-migrating-from-visual-studio-add-ins-to-packages/ Can we create a single package with all of them?

[jgsogo]

Kripa (above) tried installing this today. It seems like it loaded, but all functionality seems to be disabled. @kkripa84 is that right?

Hi @Gernatch the problem here is summarized in this post from the MSFT team, we cannot have a single extension compatible with VS2015 and VS2017/9 (at least using the current approach).

[LBHawk]

To clarify, we (myself, @Gernatch, @kkripa84) are not blocked by this PR for vs2015. I think we should keep the vs2017 issues we have (which are blocking for us) separate from this PR.