Stop wasting time during .NET Core builds


I am using Hosted build agents to build my ASP.NET Core application and each time they try to cache packages.


Set DOTNET_SKIP_FIRST_TIME_EXPERIENCE environment variable to true.


Caching packages on a temporary build machine is a waste of time.  Upon each new build a new machine is provisioned and therefore will not have the cache from before. Each build will report the following status

A command is running to initially populate your local package cache, to improve restore speed and enable offline access. This command will take up to a minute to complete and will only happen once.

To prevent this from happening you need to set an environment variable (DOTNET_SKIP_FIRST_TIME_EXPERIENCE) to true on your build machine.  If you are using containerized builds with Docker simply pass this value in your run command.  If you are using Team Services simply set the value on the variables tab.


Comments (10) -

  • Useful tip that most of us would not think of. Any idea of how much time can be saved?
    • On a hosted agent 45 to 60 seconds each build.
  • PK
    +1. It will save us time!

    However, the problem with such configurations is that you will never know when they stopped supporting it.

    I would rather prefer a flag that goes along with the dotnet restore command.

    Thanks anyway.
  • With ~ 20 packages I see a 12-24 second saving on a hosted build. Still it is something saved. Thanks, would not have found this myself.
    • You might be able to get a little more time by setting NUGET_XMLDOC_MODE=skip.  This will skip xml docs for packages.
  • That's a great tip. Could the VSTS hosted build agents automatically default this to true so that we dont have to remember to set this on every build definition?
  • Hi Donovan,

    Is there any place where I can find more documentation on these environment variables?

    • What specifically are you looking for?  VSTS vars or .NET Core?
      • Hi Donovan,

        I was asking about .NET Core vars.

  • It looks as though this is no longer necessary  - at least on the Hosted VS2017 servers.

Add comment