Skip to content

Move the solution to VS2019 and v142 toolset #565

Closed

Description

@chunliu

As mentioned in README, (also related to #534)

If you're running VS2019, you'll also need to install the "v141 Toolset" and "Visual C++ ATL for x86 and x64"

But actually v141 Toolset is not required in VS2019. The following are the configurations of my VS2019 and I can build the solution successfully.

C++ Desktop development
image

UWP development
image

Individual components
image

To build the solution in VS2019, you need to have:

  • Windows 10 version 1903
  • Windows 10 SDK (10.0.18362.0)
  • VS2019 with C++ Desktop and UWP development workloads, as shown in the above screenshots

And retarget the solution to v142 platform and the latest Windows SDK.

Activity

  1. fcharlie commented on May 8, 2019

    @fcharlie
    Contributor
    git clone https://github.com/microsoft/Terminal.git
    cd Terminal
    git submodule init
    git submodule update
    nuget restore OpenConsole.sln
    msbuild /p:Configuration=Release;AppxBundle=Always;AppxBundlePlatforms="x64" /p:Platform=x64 /p:PlatformToolset=v142 /p:TargetPlatformVersion=10.0.18362.0 /p:PreferredToolArchitecture=x64 OpenConsole.sln
    
  2. MarioLiebisch commented on May 8, 2019

    @MarioLiebisch

    Consider the README instructions as minimal build environment requirements. And v142 > v141.

    Might be, but it's still very misleading. If you have VS 2019, you don't need the v141 tools, because it should install either v141 or v142 by default anyway. My first impression was also that I'd have to install those, too.

  3. timheuer commented on May 8, 2019

    @timheuer
    Contributor

    Chun Liu (@chunliu) consider renaming this issue to "Move to VS2019 and v142 toolset" to be more directed at what is proposed.

  4. jongio commented on May 8, 2019

    @jongio

    J23 (@fcharlie) Did you run in Command Prompt for VS or cmd?

  5. timheuer commented on May 8, 2019

    @timheuer
    Contributor

    J23 (@fcharlie) Did you run in Command Prompt for VS or cmd?

    If you run tools/razzle.cmd before what J23 (@fcharlie) runs you can do it in cmd and not need the 'for VS' one (basically sets all the paths just in case)

  6. chunliu commented on May 8, 2019

    @chunliu
    Author

    Tim Heuer (@timheuer) if the source solution is moved to VS2019 and v142, people with VS2017 could have problem to build it as v142 toolset might not be installed on VS2017.

    I think the proper way to address the building issue of VS2019 is to keep the source solution targeting on VS2017 and v141 toolset, but include the proper instructions for VS2019 and v142 toolset in README. The team can retarget the source solution when they don't need to support VS2017 anymore.

  7. chunliu commented on May 8, 2019

    @chunliu
    Author

    Jon Gallant (@jongio) I tried it with VS2019 command prompt and it is working fine. You need to include the path .\dep\nuget\ for nuget command.

  8. changed the title [-]v141 toolset is not required in VS2019[/-] [+]README should include guidance for building the solution with VS2019 and v142 toolset[/+] on May 8, 2019
  9. snooopcatt commented on May 8, 2019

    @snooopcatt
    git clone https://github.com/microsoft/Terminal.git
    cd Terminal
    git submodule init
    git submodule update
    nuget restore OpenConsole.sln
    msbuild /p:Configuration=Release /p:Platform=x64 /p:PlatformToolset=v142 /p:TargetPlatformVersion=10.0.18362.0 /p:PreferredToolArchitecture=x64 OpenConsole.sln
    

    this worked, but how do I deploy? OpenConsole.exe starts old console

  10. fcharlie commented on May 9, 2019

    @fcharlie
    Contributor

    SnoopCatt (@snooopcatt) My notebook is too old, I have not tried how to package and deploy it on the command line.

  11. chunliu commented on May 9, 2019

    @chunliu
    Author

    SnoopCatt (@snooopcatt) the easiest way is to package or deploy it with Visual Studio.

  12. chunliu commented on May 9, 2019

    @chunliu
    Author

    SnoopCatt (@snooopcatt) there is a PowerShell script in build/scripts/Create-AppxBundle.ps1. I didn't try it, but maybe you can use it to package the app from command line.

  13. 12101111 commented on May 9, 2019

    @12101111

    图片
    I have thousands of "error MIDL2003: [msg]redefinition [context]".
    I 'm using VS 2019, v142 and SDK 10.0.18362

    I can build it using SDK 10.0.17663 and v142

  14. Tuumke commented on May 9, 2019

    @Tuumke
    git clone https://github.com/microsoft/Terminal.git
    cd Terminal
    git submodule init
    git submodule update
    nuget restore OpenConsole.sln
    msbuild /p:Configuration=Release /p:Platform=x64 /p:PlatformToolset=v142 /p:TargetPlatformVersion=10.0.18362.0 /p:PreferredToolArchitecture=x64 OpenConsole.sln
    

    this worked, but how do I deploy? OpenConsole.exe starts old console

    Don't you need to press CTRL+T to start a new tab?

  15. 25 remaining items

  16. ghost added
    Needs-Tag-FixDoesn't match tag requirements
    on May 17, 2019
  17. added
    Issue-TaskIt's a feature request, but it doesn't really need a major design.
    Product-ConhostFor issues in the Console codebase
    and removed on May 17, 2019
  18. ghost removed
    Needs-Tag-FixDoesn't match tag requirements
    on May 17, 2019
  19. miniksa commented on May 24, 2019

    @miniksa
    Contributor

    Current issues delaying completion of this:

    • The internal build lab required for signing packages does not yet support Visual Studio 2019, 14.2, nor the 1903 SDK (10.0.18362).

      • Mail has been sent to the lab onboarding team asking for support and an ETA
    • The alternative of using a multi-phase build (use public Hosted 2019 pool for build, use internal pool for signing) is a possibility, but...

      • We would need to have something that sets up the versioning resources for us. This is currently done by an internal-only pool support task. We would need to identify and implement a public task to set up the version during the compilation phase on the Hosted 2019 pool and then send the artifacts to the internal 2017 pool for signing dispatch and symbol registration
    • A final alternative recommendation was given to us by the lab build team: try to nuget-fetch the build tools required onto the 2017 machine.

      • I tried this and it sat for 6+ minutes going nowhere and I presume it will time out. Reliability/performance of this is too bad for me to consider further.
    • I will upload a draft PR with the version number changes. It works fine in VS2019 with the version number changes. Also, as of my tests today thanks to the .vsconfig file, VS2019 can build it just fine (after resolving dependencies automatically/installing them). So can VS2017.

  20. miniksa commented on May 24, 2019

    @miniksa
    Contributor

    More stuff we're stuck on:

  21. fcrick commented on Jun 26, 2019

    @fcrick

    I have thousands of "error MIDL2003: [msg]redefinition [context]".
    I 'm using VS 2019, v142 and SDK 10.0.18362
    I can build it using SDK 10.0.17663 and v142

    韩朴宇 (@12101111) I hit this. Doing Clean Solution and building again made it go away.

  22. ghost added
    Needs-Tag-FixDoesn't match tag requirements
    on Jun 26, 2019
  23. ghost removed
    Needs-Tag-FixDoesn't match tag requirements
    on Jun 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Area-BuildIssues pertaining to the build system, CI, infrastructure, metaIssue-TaskIt's a feature request, but it doesn't really need a major design.Product-ConhostFor issues in the Console codebaseProduct-TerminalThe new Windows Terminal.Resolution-Fix-CommittedFix is checked in, but it might be 3-4 weeks until a release.

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions