Fix for coded UI test debug broken

[smadala]

• Porting to master.
• TMIHelper from d15.6stg.
• Keep the default VSIX version in Int32 range.

Related issue

Can't debug coded UI test in latest VS2017

[codito]

Thank you!

[codito]

[xml](Get-Content $TP_ROOT_DIR\scripts\build\TestPlatform.Dependencies.props).Project.PropertyGroup.TestPlatformExternalsVersion

[smadala]

Thanks, I was searching for this 😄

[smadala]

Done.

[codito]

I was about to declare #1351 as the last PR to vstest for 2017, and then this one... @smadala on a roll today ;) 👍

[mayankbansal018]

Do we want to investigate that, rather than acquiring dependencies from nuget, & inserting it back, we create a vsix in devdiv, which directly drop these dependencies into Testplatform\Externals, just like we didf for UWP recently?

[smadala]

@mayankbansal018 I had discussed same with @codito. We thought that will cause different versions of external assemblies(MSTestv1 adapter, etc) ships in Microsoft.Testplatform nuget package and VS.

[mayankbansal018]

@smadala, I agree there could be different bits in VS preview, & TP nuget preview bits, but we can make sure that same version ends up in non-preview bits of Testplatform nugets, & in official VS release.

Which should be acceptable. It also avoids us making insertions in VS, just to update some dependencies, & we also need to go through the check-points, which we can avoid. I think it's worth it.

[codito]

In my opinion, we shouldn't fragment the distribution with more packages. While we get to do less VS insertions, but the cost of validation (i TPv2 vsix with j external vsix) and risk of human errors will increase. For instance, right now the acceptance tests give good confidence, with i and j variable, how should we ensure quality? And how do we ensure that VSTS task == VS insertion for every commit?

I'd rather fix the issues with VS insertion process if there are any, or plan the insertions better.