The target framework 'net8.0' must be 'net6.0'. Verify if target framework has been overridden by a global property.

[milen-denev]

Description

That's all that I have to say. Really I am not going to specify what how. I am using latest version of whatever as of today. Congutulations, this is the 4th time I get screwed up then trying to make an publish / update my Azure functions. There are no excuses. The experience with Azure Functions is just horrible. If I get any charge I am going to immediately request refund even if it's 1 penny.

Steps to reproduce

Manage Dependencies -> Updates -> Select All Packges -> Update -> Get screwed for 4th time.

[davidpeden3]

i just ran into this as well. you need to roll back Microsoft.Azure.Functions.Worker.Sdk to whatever version you were using prior to 1.17.2. that's the version that has the bug you reported. see https://github.com/Azure/azure-functions-dotnet-worker/issues/2291 for context.

[kshyju]

@milen-denev Would you mind elaborating the issues you are running into? Are you getting error when building locally or when building in a CI environment? Do you have .NET6 or later version of SDK installed in your build environment? That is required for building/publishing .NET Isolated function applications.

Our goal is to ensure developers have the best experience building .NET Isolated function apps. Please provide details of the issues you are encountering, and we will promptly assist in resolving them.

[milen-denev]

The error is on my local envicoment and not withing a CI/CD. Also a screenshot of my VS Configuration: Is this enough? Or I have to select additional options or maybe even dowload the .net 6 SDK from the dotnet website? Who knows what is screwed.

[kshyju]

@milen-denev You need to ensure you have the SDK installed in your build environment. Can you run dotnet --list-sdks command in a terminal and share what you see?

[milen-denev]

I really wonder, I remember until yerstarday, that if someone wanted to build apps with certain .NET version then all you had to do is to select it in the VS Installer. So after Microsoft Edge throwing out of memory and not working, now VS uninstalls SDKs and the CSHTML editor doesn't work?

[aherrick]

i'm seeing this too in GH actions latest Nuget packages. lol

[aherrick]

rolling back to 1.71.1 fixes it. what gives? what's the fix? cc @milen-denev

[milen-denev]

rolling back to 1.71.1 fixes it. what gives? what's the fix? cc @milen-denev

I don't know what's the fix is and I haven't fixed my issue, I just postpopned the release. But you know what I am reoppening this since I am not the only one and since it's occuring in Github Action. Pleace @aherrick give us more details. Enlighten us with the bugs. Maybe it will be fix in 2028 for windows and in 2037 for linux. Who knows

[kshyju]

I had no trouble using GH action to build/publish a .NET Isolated function app which uses 1.17.2 Worker.Sdk package. See the action run here https://github.com/kshyju/FunctionApp44/actions/runs/8157715362. See my workflow file here.

[nicolashemery]

Hello,

I have the same issue on my computer i try to publish. I use VS 2022 (latest version) and windows 10 (latest version). @kshyju I runned the command dotnet --list-sdks and i have the following: 3.1.426 [C:\Program Files\dotnet\sdk] 5.0.214 [C:\Program Files\dotnet\sdk] 5.0.303 [C:\Program Files\dotnet\sdk] 5.0.403 [C:\Program Files\dotnet\sdk] 5.0.408 [C:\Program Files\dotnet\sdk] 6.0.202 [C:\Program Files\dotnet\sdk] 6.0.203 [C:\Program Files\dotnet\sdk] 6.0.321 [C:\Program Files\dotnet\sdk] 6.0.402 [C:\Program Files\dotnet\sdk] 6.0.419 [C:\Program Files\dotnet\sdk] 8.0.200 [C:\Program Files\dotnet\sdk] Do i miss some? All the project in my solution in net8, thus i don't understand why net6 is needed anyway.

PS: i just tried the downgrade of Microsoft.Azure.Functions.Worker.Sdk to 1.17.1 and the publish worked, but this is not ideal.

[silvioboehme]

Same problem here, after update to 1.17.2: The target framework 'net8.0' must be 'net6.0'. Verify if target framework has been overridden by a global property. This error is not a build error. Build just works fine! This error comes from publish!

Project setting: `

Exe enable enable 12.0 x64 net8.0 win-x64 v4

`

Rolling back to 1.17.1 works fine.

[the-programmer]

Also the same issue here.

If I upgrade to 1.17.2, compilation results in the error The target framework 'net8.0' must be 'net6.0'.

Since I am compiling for an Azure function that uses .NET 8 (LTS) in the isolated worker model on Windows, rolling back to . NET 6 is not posible.

[MikeWhalenIII]

Same issue when upgrading Microsoft.Azure.Functions.Worker.Sdk to 1.17.2. Rolling back to 1.17.1 fixes the issue.

The target framework 'net8.0' must be 'net6.0'. Verify if target framework has been overridden by a global property. ..\WorkerExtensions.csproj

[DrGriff]

Shyju Krishnankutty said that he had no issue building it.

no trouble using GH action to build a .NET Isolated function app which use

The problem is not when buiding it, it's when publishing it.

[curia-damiano]

+1

1.17.2 gives me this error 1.17.1 is ok and can publish correctly

[kshyju]

Shyju Krishnankutty said that he had no issue building it.

no trouble using GH action to build a .NET Isolated function app which use

The problem is not when buiding it, it's when publishing it.

The GH action I linked above is doing a dotnet publish. See the artifacts produced on that GH action. It is the output ofdotnet publish command.

[FHRunner]

I observed the same thing as other recent contributors. I had upgraded my Function project from .NET 6 to 8. As part of that work, I upgraded Microsoft.Azure.Functions.Worker.Sdk to the very latest version, 1.17.2. I was able to build the Function in VS 2022 and run it locally. When I tried publishing it to Azure, the publish failed. I then downgraded Microsoft.Azure.Functions.Worker.Sdk to 1.17.1 and now I can publish just fine. So, this seems to be a bug in 1.17.2.

[kshyju]

@FHRunner @MikeWhalenIII @silvioboehme @the-programmer The 1.17.0 & 1.17.1 versions had a regression. 1.17.2 fixed that (rolled back the changes that caused the regression).

When you build a dotnet-isolated function, it creates an inner project called WorkerExtensions.csproj in a temp folder (You can see the full path of it in the build output). The TargetFramework of this project must be net6.0. Based on the error you are seeing , looks like this value was overridden by some other settings.

Do you have a global.json in your repo? Can you think of any other thing in your CI which is forcing the TargetFramework value to be different than net6.0?

Do you see same error when trying to publish it locally by running dotnet publish -c release ?

[FHRunner]

When I use dotnet publish, I do not experience the failure. Only when I publish with Visual Studio do I get the failure. I don't fully understand the inner project thing you described. Why must it be net6.0? I want to upgrade my function app to .NET 8 and I want to continue to be able to publish it to Azure with Visual Studio. Is that going to be possible with Microsoft.Azure.Functions.Worker.Sdk 1.17.2 or am I going to have to stick with 1.17.1 for now? It seems like the latter.

[the-programmer]

For a different issue I just made a demo project to validate that the issue was solved with the latest versions (it was). But when using Microsoft.Azure.Functions.Worker.Sdk version 1.17.2 everything worked fine.

However this demo project has 1 difference when compared to the main solution I work in. Here there is only 1 project instead of multiple (class library) projects.

Could that be the difference we ware looking for?

[silvioboehme]

@FHRunner @MikeWhalenIII @silvioboehme @the-programmer The 1.17.0 & 1.17.1 versions had a regression. 1.17.2 fixed that (rolled back the changes that caused the regression).

When you build a dotnet-isolated function, it creates an inner project called WorkerExtensions.csproj in a temp folder (You can see the full path of it in the build output). The TargetFramework of this project must be net6.0. Based on the error you are seeing , looks like this value was overridden by some other settings.

Do you have a global.json in your repo? Can you think of any other thing in your CI which is forcing the TargetFramework value to be different than net6.0?

Do you see same error when trying to publish it locally by running dotnet publish -c release ?

The WorkerExtensions.csproj looks identically with 1.17.1 and 1.17.2:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>net6.0</TargetFramework>
        <Configuration>Release</Configuration>
        <AssemblyName>Microsoft.Azure.Functions.Worker.Extensions</AssemblyName>
        <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
    </PropertyGroup>

    <ItemGroup>
        <PackageReference Include="Microsoft.NETCore.Targets" Version="3.0.0" PrivateAssets="all" />
        <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.3.0" />
    </ItemGroup>

    <Target Name="_VerifyTargetFramework" BeforeTargets="Build">
        <!-- It is possible to override our TFM via global properties. This can lead to successful builds, but runtime errors due to incompatible dependencies being brought in. -->
        <Error Condition="'$(TargetFramework)' != 'net6.0'" Text="The target framework '$(TargetFramework)' must be 'net6.0'. Verify if target framework has been overridden by a global property." />
    </Target>
</Project>

[silvioboehme]

And by the way.....if you make a fresh installation of VS2022 on Windows 11 there is no .net 6 sdk installed.

All dotnet-isolated functions builds / published / runs fine with sdk 1.17.0 and 1.17.1 with pure .net8. There was no problem at all. sdk 1.17.2 breaks the publish for all my function. So please roll back this change in 1.17.2 or find a different solution for this regression bug.

[curia-damiano]

I totally agree with @silvioboehme and all the others having this issue. It must be something different, because even in my case, I just upgraded my project (btw a single csproj without other class libraries) and I had this issue when publishing (not when compiling and debugging locally). And finding this GH issue, I've downgraded to 1.17.1 and the issue is gone.

I can provide my simple project so that you can try youself to publish on your tenant.

[silvioboehme]

It's a really BAD idea, to roll back a change from Oct 4, 2023 without any changes or checks and break all running functions on a LTS .net 8 version!

[mikegoatly]

@kshyju I might be able to help you reproduce this.

• Create a new isolated function app targeting .net 8 (use the latest versions of everything, including the SDK)
• Do a right-click publish to create a new publish profile for an Azure Function app, using the pubxml option
• Publish the project - this should work
• Change from publishing in Release mode to Debug mode:
• Publish the project again - you'll get the error "The target framework 'net8.0' must be 'net6.0'" in the output window

Using the UI also causes these elements to be added to the publish profile:

    <TargetFramework>net8.0</TargetFramework>
    <SelfContained>false</SelfContained>
    <SkipExtraFilesOnServer>true</SkipExtraFilesOnServer>

Removing the TargetFramework from the pubxml file allows the publish to work again.

Edit:

Putting together the pieces a bit more and looking at your publish command in github, I suspect if you add --framework net8.0 to your command you'll see the same error.

[kshyju]

Thanks @mikegoatly Yea, the VS publish profile updating the TargetFramework was discussed before here. We will continue to follow up on that issue (That issue is closed as the SDK changes to support that was done. but that caused another regression (in 1.17.0 and 1.17.1) and we had to revert that (in 1.17.2). We will revisit that issue again.

[dajbych]

I got this error too. Deleting the line in the file {appName} - Zip Deploy.pubxml containing <TargetFramework>net8.0</TargetFramework> helped me solve it.

[codeputer]

another day trying to solve this issue - able to do a dotnetpublish - but fails to deliver it to my Azure Function running a Linux plan. Is there another way to upload files to LInux? I only spent 2 days on this, which I gave an estimate for an hour... argh.

The target framework 'net8.0' must be 'net6.0'. Verify if target framework has been overridden by a global property.

the entire project is current on .net8. another dotnetty issue?

[mellevsen]

I started getting this error too since upgrading to 1.17.2 yesterday.

Rolling back to 1.17.1 fixed it.

Thank goodness I found this post.

[kyurkchyan]

I have started this issue after upgrading to 1.17.2. Downgrading to 1.17.1 resolves the issue.

[codeputer]

Bugs like this took me forever to find, cost me hundreds as I had to move to a windows app plan (as it worked without this problem), before finally downgrading and getting it too work again. Makes me really think the upgrade of packages is dangerous, and something you should not do until you really need to.

[atsmark]

I recreated the publishing setup in VS and it fixed the problem.

[martonx]

On gitlab, docker based build, we run this: dotnet publish -c Release -f net8.0 -r linux-x64 --no-self-contained You can easily reproduce the error. On local everything works fine. Shame on you guys.

[lionelschiepers]

Hi,

I have the same problem. My build works locally but it fails on azure devops. I have on both environments a global.json that globally sets the .NET framework 8 => the build is probably not the cause of the problem otherwise it should fail locally too.

on azure devops, I'm dogin a publish with these parameters: "--configuration Release -r linux-x64 -p:PublishReadyToRun=true".

=> There is perhaps a regression with 1.17.2 with some kind of publish on .NET 8 at least.

This bug exist since more than 23 days and many people seems to have the problem. If durable function is the future, it would be much than appreciated that a regression like this one is solved quickly.

In the mean time, I've downgraded to 1.17.0 because 1.17.2 seems to be a revert of a change in 1.17.1

[lionelschiepers]

It works when I remove "-r linux-x64 -p:PublishReadyToRun=true" in my build pipeline during the publish. BTW it must work in all configuration and this regression must be solved.

[raysuelzer]

Having this issue as well deploying to win-x64

[gwise-vision]

Same Issue. "The target framework 'net8.0' must be 'net6.0'. Verify if target framework has been overridden by a global property." Microsoft.Azure.Functions.Worker.Sdk - 1.17.2 There will be no problem if you downgrade to version 1.17.1.

Does the MS development team only do local testing? An error occurs when publishing to Azure server.

Knowing that there is this much of a problem, why are you sending me an email saying I need to change to the isolated worker model?

[CaidenKehrer]

Same issues here. Do we have any update as to when an update will come out that fixes this issue? I had to roll back all of my projects to 1.17.1.

[tacoWanneeJama]

I got this error too. Deleting the line in the file {appName} - Zip Deploy.pubxml containing <TargetFramework>net8.0</TargetFramework> helped me solve it.

This worked for me. So for now I would say this is the easiest solution.

[atbez-miview]

FYI. Updating from 1.17.2 to 1.17.3-preview fixed this specific issue for me locally, but caused a different issue in Azure Devops where the WorkerExtensions.csproj was trying to restore from my private repo and failing.

[doruksro]

Taky jsem dostal tuto chybu. Smazání řádku v souboru {appName} - Zip Deploy.pubxmlobsahujícím <TargetFramework>net8.0</TargetFramework>mi to pomohlo vyřešit.

Hurray works, thank you for all, one day lost with this problem. I am search in my disk file global.json, that never used. Already 3 days lost for transfer from In-process to Isolated Model. And later 1 day more to delete 1 line.

[jviau]

The target framework 'net8.0' must be 'net6.0'. Verify if target framework has been overridden by a global property.

That error message is there to intentionally turn a runtime failure into a compile time failure. The inner build must be built with same TFM that the functions runtime is (in this case .NET6). For a while it was possible to override this inner builds TFM to .NET8 via global properties (a common way was via VS pubxml). Doing so can lead to runtime assembly load failures. In 1.17.0 we added two things:

1. Preventing the global property from flowing (fixing the issue)
2. Adding a safeguard in case it is somehow overridden still. (to avoid obscure runtime failures)

In 1.17.2 we reverted number 1, but left 2 in place. With 1.17.3-preview1 number 1 is back in place.

As for the nuget restore change, this was also an intentional bug fix where the inner build was not inheriting nuget sources from outer build, effectively blocking any usage of extensions on feeds other than nuget.org. If these feeds are private you will need to add an authentication step before building the function app.

[raysuelzer]

So we should be using .net 6 for functions?

[jviau]

So we should be using .net 6 for functions?

You may use net8.0. Just be aware that If you are not using the 1.17.3-preview1 you may encounter this issue. The fix is typically to remove whatever is setting that global TFM property. In the case of publishing from VS, delete the <TargetFramework>net8.0</TargetFramework> line from your .pubxml

[jviau]

This is resolved by #2347

[ulluoink]

@jviau

not it is not resolved as there is no 1.17.3

we still have to use 1.17.1

why do you close this issue?!

[jviau]

@ulluoink it is available here https://www.nuget.org/packages/Microsoft.Azure.Functions.Worker.Sdk/1.17.3-preview1

We resolve issues when the code change is merged in.

[Bit-Shifts]

I came across this issue as well and updating to [1.17.3-preview1] solved it.

[ulluoink]

preview is absolutely no option in production

[Bit-Shifts]

You are not wrong when it comes to good practices.