Building a VSIX project is long because of first-time VS setup

[roji]

When running msbuild in a simple VSIX project, the build gets stuck for quite a long time on the following message:

Setting up Visual Studio for debugging extensions. This one-time operation may take a minute or more.
  C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenv.exe /RootSuffix Exp /ResetSettings General.vssettings /Embedding /Command File.Exit

I'm not sure exactly what's going on, but there's obviously some one-time step that VS performs. It seems that if this could be done in the image, lots of time could be saved for anyone building VS extensions.

[FeodorFitsner]

Can you put a simple project building VSIX into public repository? We can use it as "warm up" app then.

[roji]

See this for a workaround.

[sharwell]

@FeodorFitsner It's my understanding that these two lines can be used to prepare the image for VS extension deployment, and applying the change to the prepared image itself would notably reduce build times for extensions.

https://github.com/tunnelvisionlabs/MouseFastScroll/blob/3e4efb08e2170a8bbfb4a9497a1531072776f31f/appveyor.yml#L11-L12

[FeodorFitsner]

Thanks for pointing that out. Could you please elaborate more on the purpose of those commands?

[sharwell]

These commands are typically run during a build if a Visual Studio extension (VSIX format) is getting deployed during a build. The commands have a few downsides which become apparent in this situation:

1. They take a while to run. It can increase a build for a small project from 20-30 seconds to several minutes.
2. They occasionally fail and/or produce noisy output. It appears that some extensions that ship with Visual Studio and/or the Windows SDK fail to correctly handle the initialization step, and can throw exceptions when the devenv process starts to shut down. In some cases, the failure will produce an error return code for the process that triggers a failed build.

For a long time, I simply worked around the problem by liberally applying the following to extension projects:

<PropertyGroup Condition="'$(BuildingInsideVisualStudio)' != 'true'">
  <!-- This property disables extension deployment for command line builds; required for AppVeyor -->
  <DeployExtension>False</DeployExtension>
</PropertyGroup>

More recently, I worked with a few people to move from simply building extension projects to properly testing them in integration test scenarios. The effort is led by @josetr and has moved from just an early experiment to a point where more projects are starting to use it. When integration testing is involved, we can no longer avoid extension deployment and clearly we need to launch the IDE.

The two commands I listed can be executed on a fresh installation (no code specific to any particular project is installed on the system) to initialize Visual Studio for use. With this one-time initialization complete, the deployment scenario for integration testing is both more stable and notably reduces the impact on build time.

[FeodorFitsner]

Do you envision any side effects potentially caused by these commands for other apps/tests using devenv calls?

[sharwell]

In general, these commands are not expected to cause a negative impact for any of the following:

• Users who don't launch devenv or build a VSIX project
• Users who do launch devenv using normal VSIX deployment (deployment will skip this step if it's already been performed, so these builds will be faster)
• Users who manually perform these steps as a pre-build action (executing the command twice is not an error, though these users would not see as much of a performance improvement)

My main concern would be the manner in which Visual Studio licenses are applied to these instances. If the licenses time out after some period of time, you'll want to go through a trial period of at least 45 days of reasonably-regular use after the image is created. You'll want to make sure you aren't getting messages like the following in integration test scenarios in the 30-45 day period (image taken from one of the dotnet/roslyn Jenkins test runs):

I would be willing to assign tunnelvisionlabs/MouseFastScroll to the experimental image if you want to observe the build over a period of time.