Upgrade of .NET agent for Azure Pipelines

Bohdan Janousek

We are upgrading the .NET used by Azure Pipelines agent from current .NET Core 3.1 to .NET 6. This is to support new Apple silicon hardware as well as newer operating systems such as Ubuntu 22.04, or Windows on ARM64. Another reason for the .NET upgrade is the fact the .NET Core 3.1 version is already in maintenance phase and the support ends on December 13th, 2022. This means there will be no patches after this date. See .NET and .NET Core official support policy (microsoft.com) and .NET Core 3.1 reaching end of support on December 13th, 2022 for more details. We do not want our customers to build and release their applications on unsupported frameworks.

If you are running self-hosted agents on newer operating systems that are already supported by .NET 6, this update will be seamless for you. Unfortunately, not all operating systems supported by .NET Core 3.1 are supported by .NET 6. The following operating systems are not supported by .NET 6 and hence cannot be used to run the new (.NET 6 based) Azure Pipelines agent. This is not a complete list.

System/Distribution Version not supported by .NET 6
CentOS < 7
Debian <= 4.9
Fedora <= 32
RedHat EL <= 6
Ubuntu <> 18.04, < 20.04
MacOS < 10.15

If you use on one of the above operating systems to run self-hosted agents, you must update your agent machines to a newer operating system to prevent pipelines from failing. To provide you the best support we’re planning to roll out the .NET 6 Azure Pipelines agent in the following phases:

Phase I – Preview

We have already made a prerelease version of .NET 6 agent available to all customers. In other words, we are now shipping a .NET Core 3.1 version (agent versions 2.x) as well as a .NET 6 version of the agent (agent versions 3.x) every few weeks. This is to let you download and test the new agent in your pipelines and to give us feedback. To use the new agent, set up a separate agent pool following the instructions here. Download the latest .NET 6 agent from our GitHub releases page.

Phase II – General availability for Microsoft-hosted pools

Starting mid-December, we will update all the Microsoft-hosted agents to use the .NET 6 agent. Your pipelines should continue to work without any changes. In case of any issue contact support.

Phase III – General availability for self-hosted pools

In this phase, we will stop updating the .NET Core 3.1 agent. We will only update the .NET 6 agent. The exact date when that will be done will be communicated. The current plan is to do that towards the end of Q1 2023. In general, our expectation is that you will update your agent machines to newer operating systems by this time. We will help you with this transition before we make this change by:

  • Providing a script that will process all pools in your organization and identify v2 agents on operating systems that are not supported by the v3 agent, e.g. CentOS 6, Fedora versions before 31, macOS 10.14, RHEL 6. Note that recent builds of the v2 agent will not try to auto-upgrade to the v3 agent on an operating system known not to be compatible with it.
  • Adding warnings to pipeline runs when you use an OS that is not supported by .NET 6. Note that these warnings will only be visible if you get our agent updates regularly. So, you may not see these warnings in all cases.
  • Adding a banner to your Azure DevOps experience to remind you to upgrade your agent machines.
  • Providing a mechanism to prevent auto-upgrading of the agent from 2.x version to 3.x version if you use an OS that is not supported by .NET 6. Look out for a follow-up blog with instructions.

FAQ

Q: What is the difference between the 2.x and 3.x agents?
A: The 2.x agents (e.g., 2.212) are .NET Core 3.1 and the 3.x agents (e.g., 3.212) are .NET 6. During Phase I and II, we will have both versions simultaneously with the 3.x versions being in prerelease.

Q: How will security issues in the agent be patched going forward?
A: When the .NET 6 agent becomes generally available for self-hosted pools in Q1 2023, there will be no patches done, in general, for the 2.x agents. The patches will be done only for the 3.x agents. However, we also have Azure DevOps Server customers that will still be relying on 2.x agents. So, we will review the security issues on a case by case basis to decide.

Q: What do I need to do when I’m on an unsupported OS?
A: You should migrate to a newer operating system that is supported by .NET 6 now. Otherwise, your agent may attempt to upgrade, and it will fail as .NET 6 cannot be installed on your OS. We will publish some guidance in a follow-up blog post that will prevent auto-upgrades of the agent. However, that is only meant to be a temporary solution to give you some more time to upgrade your agent machines.

Q: Can I stay forever on 2.x agents if I am not working on any changes in the project anymore.
A: No. We are regularly adding new features to Pipelines and some of them may require an update to the agent even though your pipeline does not explicitly depend on that feature. When you prevent auto-upgrades of the agent using the guidance in a follow-up blog, that agent cannot be used to schedule the pipeline. If no agent with the required capabilities can be found, the pipeline execution will fail.

Q: I use Azure DevOps Server and not Azure DevOps Service. Does this change impact me?
A: No. The new agent is only applicable for Azure DevOps Service customers at this time. However, a future version of Azure DevOps Server (2022.1) will include the new agent. So, it is recommended that you update your agent machines to newer OSes that are supported by .NET 6 starting now, if you plan to keep up with the Azure DevOps Server releases in the future.

15 comments

Discussion is closed. Login to edit/delete existing comments.

  • Arie Heinrich 0

    A good change, but are you sure doing this in December, the month of holidays and less people in offices is the best thing to do ?
    I understand .bet core 3.1 ends mid December but its not that things will stop working on the 13th just because of that. Not to mention it will give people more time to test it without being stressed with end of the year projects and holidays ?

    • Bohdan JanousekMicrosoft employee 0

      Thanks for your the feedback. In the Phase II, we’re upgrading the Microsoft-hosted agents only. The pipelines should continue to work on those with no changes.

      Upgrade of the self-hosted agents is done in the Phase III only. In this phase we provide enough time to anyone to test the .NET 6 agent (as per details in Phase I) and to upgrade to newer and supported versions of operating systems. We encourage all customers to start the new .NET 6 agent testing soon/now.

      • Rajakumaran CMicrosoft employee 0

        Hi Bohdan, we are seeing build issue with MSBuild task in our pipeline with error
        C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(4968,5): error MSB3030: Could not copy the file “D:\a\1\s\ProjectName\obj\x86\Release\netcoreapp3.1\apphost.exe”

        seems like many other ppl are seeing the same as you see below. Is this a known issue? or is there anything we need to address to build the project with MSBuild task?

        • Bohdan JanousekMicrosoft employee 0

          The error you see has nothing to do with the .NET agent upgrade this blog is about. It is most probably a result of the recent change to the OS image you’re using (Windows 2019) where the 6.x versions of the .NET SDK/runtime were added (see the contents of different OS images here).

          You can pass additional parameter to the MSBuild task to make sure the required toolset toolsVersion and framework version property:TargetFrameworkVersion will be used. See the reference for more details).

  • Dmitry Oskin 0

    Our pipeline stopped working with the error:

    C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(4968,5): error MSB3030: Could not copy the file “D:\a\1\s\ProjectName\obj\x86\Release\netcoreapp3.1\apphost.exe” because it was not found.

    With the proj file configuration:

        
        <PropertyGroup>
            <TargetFrameworks>net472;netcoreapp3.1</TargetFrameworks>
            <OutputType>WinExe</OutputType>
            <UseWindowsForms>true</UseWindowsForms>
            <RootNamespace>Browser</RootNamespace>
            <GenerateResourceUsePreserializedResources>true</GenerateResourceUsePreserializedResources>
            <Platforms>x86;AnyCPU</Platforms>
        </PropertyGroup>
        

    Had to remove the “;netcoreapp3.1” part at least to build the project as a temporary workaround.
    Any suggestion how this can be fixed please if it is a known issue?
    Cheers, Dmitry

    • Henry Dyer 0

      This has broken our pipelines too, with the same apphost.exe not found error.
      Luckily, we have another build agent of our own, but the hosted agent will not work.

    • Bohdan JanousekMicrosoft employee 0

      The error you see has nothing to do with the .NET agent upgrade this blog is about. It is most probably a result of the recent change (add of the 6.x versions of the .NET SDK/runtime) to the OS image you’re using. See the contents of different OS images here.

      You can pass additional parameter to the MSBuild task to make sure the required toolset toolsVersion and framework version property:TargetFrameworkVersion will be used. See the reference for more details).

      • Henry Dyer 0

        Thanks for the info. Could you please give me an example of which parameters I should pass to build my solution that contains some netcore 3.1 and netstandard 2.1 projects with VS 2022? We are using the “Visual Studio build” task in Azure DevOps, instead of the .NET Core build task, so that it builds the SQL Server database project too (we use the dacpac file for some automated data access tests in a later step).

        What I don’t quite understand is why it doesn’t pick up the netcoreapp3.1 from the project files.

        • Bohdan JanousekMicrosoft employee 0

          Blog comments aren’t the best place to look for this kind of support, Henry. Suggest you review the details already provided, docs, check Developer Community, file a support ticket, etc.

    • Jeff A Levi 0

      As above … I have a continuous integration pipeline on Azure DevOps using the ‘windows-2022’ agent that has now stopped working as of Jan 10, 2023. Jan9 worked ok, jan10 build fails with the apphost error. My application(s) will BUILD ok, but will not PUBLISH. The publish steps from msbuild fail with the similar error to above (I am publishing to a linux-arm64 target run identifier, application is net6.0) :

      [error]C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(5150,5): Error MSB3030: Could not copy the file “D:\a\1\s\ProjectName\obj\Release\net6.0\linux-arm64\apphost” because it was not found.

      • Bohdan JanousekMicrosoft employee 0

        Thanks for the comment. Nonetheless this is not related to the upgrade of the .NET agent but something else.

        Jeff, suggest you review the details already provided, docs, check Developer Community, file a support ticket, etc.

  • Ritesh 0

    So to clarify that means Agent versions 3.X that will be running on a supported OS e.g Win Server 2019 still needs the .NET 6 to be installed on the server ? i.e .NET 5 or lower versions installed on a .NET 6.0 supported server will not work with Agent 3.X ?

    • Bohdan JanousekMicrosoft employee 0

      No, all dependencies the .NET 6 agent requires are part of the agent itself.

  • Adam Schröder 0

    Will there be a button on the agents interface to update to the v3 agent, or will the update to the latest do that, and there will only be something to prevent that from happening?

    • Bohdan JanousekMicrosoft employee 0

      Upgrade process will be using the latest version of relevant path. So, the 2.x will upgrade to latest 2.x and 3.x to latest 3.x. The 2.x will upgrade to latest 3.x when the feature required by the task is not supported by the 2.x. In addition this will be done when manually upgrading the agents in the pool and the 2.x is not supported anymore. The more details for the self-hosted pools are being prepared.

Feedback usabilla icon