Devenv takes a long time to run the first time

[kudaba]

Describe the bug
In the all current versions of MSVC (2017 and 2019), the first time devenv runs it goes through some internal 'new user experience' work that takes 3-8 minutes. Since this time is outside of the control of users would it be possible to run devenv when building the environments so users don't have to constantly pay the cost?

Virtual environments affected

• macOS 10.15
• Ubuntu 16.04 LTS
• Ubuntu 18.04 LTS
• Windows Server 2016 R2
• Windows Server 2019

Expected behavior
Using devenv to build a project or solution should start compiling right away instead of just idling for many minutes.

Actual behavior
Unfortunately my repo is currently private, but from what I can gather using devenv over msbuild on any solution or project should cause this. In my case I can't use msbuild because of how the projects are setup.

The following image shows the problem, devenv is executed at line 28 but doesn't even show the startup banner for 8 minutes.

[alepauly]

Thanks for reporting. @kudaba do you have a sample first devenv command line that you run and causes this to happen? We might be able to warmup the instance ahead of time.

[kudaba]

Sure, here's a trimmed down version of my job:

  Windows:
    runs-on: ${{ matrix.os }}
    env:
      MSBUILD_PATH: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\devenv.com
      SLN_PATH: path\to\application.sln
    strategy:
      matrix:
        os: [windows-latest]
    steps:
    - uses: actions/checkout@v1
      with:
        submodules: recursive
    - name: Setup Nuget.exe
      uses: warrenbuckley/Setup-Nuget@v1
    - name: nuget restore
      shell: cmd
      run: nuget restore "%SLN_PATH%"
    - name: compile debug
      shell: cmd
      run: |
        "%MSBUILD_PATH%" "%SLN_PATH%" /build debug
    - name: compile release
      shell: cmd
      run: |
        "%MSBUILD_PATH%" "%SLN_PATH%" /build release

And updated outputs showing the time between nuget and the first compile:

And the time between the first and second compile

[alepauly]

@kudaba sorry for the delay, I'm working on this now and gathering data for the Visual Studio team to help out here.

[github-actions]

This issue has not had any activity for 45 days and will be closed in 45 days if there continues to be no activity.

[alepauly]

I gathered some perfviews and sent them to the VS team who confirmed this is due to MEF composition on startup. Running devenv /updateconfiguration should alleviate it. We already have code that should be running this but apparently it's not doing the trick so we should investigate why.

[andy-mishechkin]

I have tested builds of some my solutions in Canary builds and I didn't find any big delays. 'devenv /updateconfiguration' is executed now when MMS provisioner runs on VM, and perhaps it already fixed this issue.
Please test it once again.
If you still get this issue, please provide your solution for test building.

[kudaba]

I went through a bunch of recent builds, and at first it looked like it dropped from 3 minutes to 1 minute for a while, but the 3 recent builds show some pretty erratic behavior. I have 2 devenv jobs per build and the initial devenv launch timing is as follows:

Mon, 16 Mar 2020 06:07:48 GMT - 1 sec, 3 min
Mon, 16 Mar 2020 06:06:20 GMT - 3 min, 1 min
Mon, 16 Mar 2020 05:42:29 GMT - 3 min, 1 min

Only one case was it fast (the most recent), but all others were either almost exactly 1 minute (+- 4 seconds) or 3 minutes (+- 20 seconds).

[maxim-lobanov]

Hello @kudaba , we have tweaked VS a bit.
Could you check one more time?

[kudaba]

Sure: 4 builds had the following timings in seconds between the first and second executions of visual studio:

First	Second
60	8
114	6
87	9
68	7

It's a small sample set but seems to be heading in the right direction.

[maxim-lobanov]

Hello,
Our latest result (reducing VS initialization time to 1-1.5 minutes) was achieved by invocation devenv.exe /updateconfiguration during deployment. It does first VS initialization and improves build time.

Unfortunately, we don't see more ways to improve it because it seems that remain time comes from VS execution (probably, initialization of solution or something similar)
I am going to close this issue for now. Please let us know if you see other ways to improve it.

[kudaba]

It's a lot better than before, thanks for taking the time to look into this. I can imagine the rest of the cost is probably just spinning up from the HD into the ram cache, etc, etc. This still saves a lot of minutes per run.

[kudaba]

This started acting up again taking 5+ and sometimes over 10 minutes for the initial execution to run, compared to other platforms that complete their entire build process in just over a minute.

[dibir-magomedsaygitov]

Hello @kudaba. We will take a look.

[nikolai-frolov]

Hello @kudaba, I've investigated the issue but unfortunately wasn't able to reproduce the mentioned 5+ minutes delay. All my pipelines pass first build step (build debug) in 2-3 minutes and I guess it is expected for the devenv tool since it performs initialization for the first project run on machine (e.g. https://github.com/nikolai-frolov/image-testing/runs/4433619975?check_suite_focus=true). Probably this delay can actually depend on project size. Anyway I'm not sure if we can do something here, since it's related to devenv tool which is a part of Visual Studio and external for us. I can suggest you to use msbuild instead: it allows restore packages and build project much faster and it's already available in Windows images. Please find example pipeline which does the same but really much faster: https://github.com/nikolai-frolov/image-testing/runs/4445726711?check_suite_focus=true

    steps:
    - uses: actions/checkout@v2
      with:
        submodules: true
    - name: Add msbuild to PATH
      uses: microsoft/[email protected]
    - name: msbuild restore
      shell: cmd
      run: |
        msbuild /t:restore "%SLN_PATH%"
    - name: compile debug
      shell: cmd
      run: |
        msbuild "%SLN_PATH%" /p:Configuration=Debug
    - name: compile release
      shell: cmd
      run: |
        msbuild "%SLN_PATH%" /p:Configuration=Release

[kudaba]

That seems to be working so far. I can't remember if there was a reason I needed to use devenv over msbuild (I'm building a c++ project so who knows).

[domenichelfenstein]

I still have the same problem: It took 10 minutes before the build even started on the windows-2022 image.

@nikolai-frolov: What I'm using (and @kudaba also seems to use) is devenv (Visual Studio in C:\Program Files\Microsoft Visual Studio\2022\Enterprise), not msbuild

The build itself "only" took 1min

[screig]

I am seeing the same problem

snippet from the yml file.

    $devcom = 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\devenv.com'
    echo $devcom
    echo '>>> Does the executable exist ....'
    Test-Path -Path $devcom 

    $helpargs = 'addin_selector.sln /?   /out log.txt ' 
    echo '>>> These are the TEST arguments I will pass ....'
    echo $helpargs        
    echo '>>> Call the executable...'
    Start-Process -FilePath $devcom -ArgumentList  $helpargs  -NoNewWindow -Wait

    $myargs = 'addin_selector.sln /build Release /Project addin_selector_installer\Installer.vdproj '
    echo '>>> These are the BUILD arguments I will pass ....'
    echo $myargs       
    echo '>>> Call the executable...'
    Start-Process -FilePath $devcom -ArgumentList  $myargs  -NoNewWindow -Wait

[screig]

note I can't use msbuild as suggested as I am building a vdproj file.

[robertoandrade]

We too can't use msbuild and are building a solution with dtproj (SSIS) via dev env and notice the same delay building in Azure DevOps with the same images.