none
eWDK changes after 16232 are game breaking RRS feed

  • Question

  • What is going on with the changes to the eWDK batch files and folder layout structure?  Is this documented anywhere?  Playing catch-up on this has been a nightmare.

    The change in the LaunchBuildEnv.cmd  --> call "SetupBuildenv.cmd" %*  to  @%comspec% /k "%~dp0BuildEnv\SetupBuildEnv.cmd %*"   Why was this done? this is horrible for automation based environments.

    In previous eWDK versions is was very simple to ewdk\LaunchBuildEnv.cmd && ExecuteMyBuildScript in ewdk context.  Cmd /k ruins that.

    Second, I notice that many of the folder paths now look like:

    D:\ewdk_16262\Program Files\Windows Kits\10\bin\10.0.16262.0\WppConfig\Rev1

    But the Macro's in VS still show:

    D:\ewdk_16262\Program Files\Windows Kits\10\bin\WppConfig\Rev1

    Are these known issues?

    Wednesday, August 16, 2017 11:45 PM

Answers

  • 1. Versioning is common to both the WDK and the EWDK, as a part of moving to VS2017 build tools and keeping in sync with the SDK. By Setting the TargetPlatformValue appropriately, you can build for previous Win10 releases.  If you always want to default to the latest build, set your TPV to to $(LatestTargetPlatformVersion).

    2. You are absolutely free to create / modify the batch file in any way that seems appropriate to you.    In what way does the current incarnation break automation?

    3. I will pass the macro issue on to the devs.

    Thursday, August 17, 2017 5:21 PM

All replies

  • 1. Versioning is common to both the WDK and the EWDK, as a part of moving to VS2017 build tools and keeping in sync with the SDK. By Setting the TargetPlatformValue appropriately, you can build for previous Win10 releases.  If you always want to default to the latest build, set your TPV to to $(LatestTargetPlatformVersion).

    2. You are absolutely free to create / modify the batch file in any way that seems appropriate to you.    In what way does the current incarnation break automation?

    3. I will pass the macro issue on to the devs.

    Thursday, August 17, 2017 5:21 PM
  • 1. We use $(LatestTargetPlatformVersion) for all projects and that is resolving to the current ewdk 16262.

    2. I really don't want to edit every eWDK drop.  That batch file has used Call since I've been using eWDK's.  Call vs Cmd /k operate very differently.  Assume I have 100+ VM build nodes.  Using Call I can tell the VM to execute "d:\ewdk\LaunchBuildEnv.cmd && executeBuildScript".  The build script will execute in the context of the eWDK.  I'm no Batch Guru but cmd /k spawns a new session, how do I execute my script in that new session to use it's context... from a remote machine?

    3. This affects many other tools also, stampInf.  Is this a VS2015 vs VS2017 issue, should all projects be upgraded using VS2017?  Just flipping the bits from 14 to 15 doesn't seem to affect the paths.


    Thursday, August 17, 2017 7:11 PM
  • For #3, WDKBinRoot has been updated to be backward compatible so for VisualStudioVersion <=14.0 it defaults to non-versioned bin and for > 14 it defaults to the versioned bin folder.

    The RS3 WDK however is only compatible with Visual Studio 2017 so you should upgrade your projects to that.


    Anish

    Friday, August 18, 2017 11:57 PM