Description
Historically the winappdeploycmd exe used for Windows 10 device detection, app installation and such would always be installed 'globally' in
C:\Program Files (x86)\Windows Kits\10}\bin\x86. Since 10.0.15063.0 this appears to be no longer the case and it is packaged with the SDK, at
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x86
Our tooling makes the assumption that winappdeploycmd is in this global space, we need to adapt the tooling to inspect an SDK for winappdeploycmd, I'm unsure whether if we detect one we assign it to the overall VS info, overriding one that exists or we keep a winappdeploycmd tied to an SDK.
Posted a question here to see whether this will be the norm from here
https://docs.microsoft.com/en-us/windows/uwp/packaging/install-universal-windows-apps-with-the-winappdeploycmd-tool
Considering this a requirement for us to document support for VS2017 as without it will require installing multiple SDKs to build (n)
[~kiguchi] I've started to work on this but just wanted some input from you. I'm trying to keep the existing functionality as best as possible. Here's what I'm doing so far - After the detection, if deployCmd is null [here](https://github.com/appcelerator/windowslib/blob/58823680ebad9d100d5a3226f4cbf8b24868fc29/lib/windowsphone.js#L175-L180), starting with the highest SDK work through them and check for
C:\\Program Files (x86)\\Windows Kits\\10\\bin\\<SDK_VER>\\x86\\winappdeploycmd.exe. Taking the highest available The problem I have is, if I'm using SDK 15063 and 14393 we will take the globally installed winappdeploycmd, when I feel like I should be taking the latest under 10.0.15063, what're your thoughts?[~eharris] Yes, it sounds natural to me to select latest version of winappdeploycmd tooling when target sdk is 10.0. (y)
Windowslib PR: https://github.com/appcelerator/windowslib/pull/75 Travis is failing because of a super old node version, I think we should nuke travis, (pr https://github.com/appcelerator/windowslib/pull/73) as imo it's not worth the hassle. Maybe we can look into appveyor if we want some sort of configurable ci as a service (which imo we should do to allow us to test diff versions of VS against windowslb)
Merged. need to update titanium_mobile then.
Master: https://github.com/appcelerator/titanium_mobile/pull/9349 6_2_X: https://github.com/appcelerator/titanium_mobile/pull/9350
[~smohammed] [~amukherjee] Do you have a machine available that only has VS2017 installed?
[~eharris] The machine we use for VS2017 has both VS2017 and VS2015 installed.
Passing review as it's merged into the SDK now, it is present in latest 6_2_X 6.2.0.v20170824144806 but not latest master 7.0.0.v20170823165814 Verification
Ensure you have the 10.0.15063 tooling installed with VS2017
Run appc ti info -t windows -o json
Check the results.windowsphone[10.0] object for the deployCmd value, it should list a file under the 10.0.15063 bin dir like
"C:\\Program Files (x86)\\Windows Kits\\10\\bin\\10.0.15063.0\\x86\\WinAppDeployCmd.exe"Closing ticket as changes present in SDKs: 6.2.0.v20170828180251 7.0.0.v20170829103419