ViewComponents called with the vc taghelper are broken on 7.0.3

[kanadaj]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

View Components aren't called properly when building the project with .NET SDK 7.0.200. The tags are instead left on the page as a regular HTML tag. In some cases, passing arguments to the HTML tag results in error CS1503: Argument 3: cannot convert from 'method group' to 'object?'

This is likely a result of the newest SDK using MSBuild version 17.5.0-preview-23061-01+040e2a90e for .NET. I'm not sure a preview version of MSBuild was meant to leak into the production CLI.

Do not that I didn't update MSBuild separately, this is just what came with the 7.0.200 SDK.

Expected Behavior

View Components should work

Steps To Reproduce

Take any simple view component test repo, build and run it using MSBuild 17.5.0-preview-23061-01+040e2a90e

Exceptions (if any)

No response

.NET Version

7.0.200

Anything else?

Using dotnet publish; this issue started surfacing on our build server. Using ASP.NET Core 7.0.2, but updating to 7.0.3 didn't seem to fix the issue.

.NET SDK:
 Version:   7.0.200
 Commit:    534117727b

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  20.04
 OS Platform: Linux
 RID:         ubuntu.20.04-x64
 Base Path:   /usr/share/dotnet/sdk/7.0.200/

Host:
  Version:      7.0.3
  Architecture: x64
  Commit:       0a2bda10e8

.NET SDKs installed:
  3.0.103 [/usr/share/dotnet/sdk]
  3.1.416 [/usr/share/dotnet/sdk]
  5.0.404 [/usr/share/dotnet/sdk]
  6.0.300 [/usr/share/dotnet/sdk]
  7.0.200 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.0.3 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.22 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.13 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.5 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.3 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.0.3 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.22 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.13 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.5 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.3 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download```

[kanadaj]

Update: rolling back the SDK on the build agent to 7.0.103 fixes this issue. 7.0.200 seems broken w/r to ViewComponents due to the preview MSBuild version.

[javiercn]

@kanadaj thanks for contacting us.

@jaredpar this might be a regression

[jaredpar]

@chsienki is this related to the issue you were looking at?

[nickalbrecht]

I hit this today as well, targeting 7.0.103 SDK resolved the issue, instead of 7.0.x. (Azure Pipeline build)

[recumbented]

Exactly same issue.
Build with 7.0.200, any <vc: tags in .cshtml are not working.
7.0.103 has no issue.

[janstrube]

Same issue here. Targeting 7.0.103 SDK however does not resolve it for me. The Azure Pipeline still uses the problematic MSBuild version 17.5.0-preview-23061-01+040e2a90e for .NET.

How can I get rid of this? Uninstalling 7.0.200 SDK didn't help.

[recumbented]

@janstrube If you use Self-Hosted agent, you need to delete 7.0.200 files and folders from _work_tool\dotnet\sdk.

[janstrube]

@recumbented Thanks, that worked.

[ernestopye]

This is also an issue on 6.0.406. We float our SDK minor version. No errors, no warnings, just a stealthy switch to a prerelease version of MSBuild which completely broke multiple projects (we rely heavily on ViewComponents).

It took us several hours to pinpoint the issue. The giveaway was the dll being way smaller on the broken version, which made us look at the build, and that's where we spotted the prerelease version of MSBuild.

Our fix was to pin the version in global.json, and modify our pipelines to use this rather than the floating version. This has been a huge pain, and if we need to wait a month to get a fix (per the SDK team's response), then we're unlikely to continue floating minor versions, which is really unfortunate.

[query-wow]

Happened to me as well, using MSBuild version 17.5.0-preview-23061-01+040e2a90e breaks vc tag helpers.

We fixed it by deleting .net 7.0.200 from our CI runner so it uses 7.0.103.
This fixed the issue for now, but in a very hacky way.
actions/setup-dotnet#383

[vadimkhm]

Exactly the same issue.
Build with 7.0.200, any <vc: tags in .cshtml are not working.
7.0.103 has no issue. Are you really done releasing or experimenting with us?
How can the preview version be released :(

[chrux]

Another workaround is to add the global.json file to the solution/project to specify the SDK. We went back to use the previous stable version (7.0.102-103) using that instead of removing the SDK did it for us.

[Eneuman]

Same problem, just spent 4 hours trying to figure out what PR broke our build but then found that 7.0.200 pulls in a PREVIEW of MSBUILD. Comon....

[kanadaj]

According to the comments on dotnet/sdk#30624 the cause is in dotnet itself (probably roslyn) rather than the msbuild version

[janstrube]

Following the installation of the VS 17.5 release, I observe the same issue on my workstation. Not impressed.

[MrClyfar]

Just wanted to clarify my understanding... we have a .NET 6 website that is affected by this issue.

Why would the .NET SDK v7.0.200 bits get in the way of the view components being processed for a website targeting .NET 6? I thought anything v7* would be for .NET 7 instead?

[indigogiant]

@MrClyfar From what I can tell the problem seems to affect the dotnet runtime versions 6.0.14 and 7.0.3.

SDK versions that match those runtimes are therefore affected, so that'd be: 6.0.114, 6.0.309, 6.0.406 for .Net 6 and 7.0.103, 7.0.200 and 7.0.201 for .Net 7.

We've just run straight into this problem since the Azure DevOps Windows hosted build agents appear to have been updated in the last 24 hours and have picked up the new runtimes. We've used the global.json workaround.

[DavidTagt]

Just wanted to add my findings.

I've tried with SDKs 7.0.103, 7.0.201, and 6.0.406 in global.json
201 doesn't work, but 103 and 406 does work.

@indigogiant I just want to check if you've tested those versions you list, or if it was just assumption? Since my testing partly contradicts the versions you listed, I just wanted to check.

Here's my json file. Github doesn't allow .json though so i changed it to .txt
global.json.txt

[pmarangoni]

Today's update didn't fix anything. I'm now at version 17.5.1

Microsoft Visual Studio Community 2022
Version 17.5.1
VisualStudio.17.Release/17.5.1+33424.131

ASP.NET and Web Tools 17.5.317.37931

Looking forward to 17.5.2

[mitchelsellers]

Just to toss my experience on here.

Pinning to a prior version of the SDK using a global.json file fixes things when working locally. However, publishing the application still stops all <vc style usages to totally stop working.

There is no viable workaround that allows us to publish applications. Currently haunting all deployments for > 45 of our customer applications

[kanadaj]

@mitchelsellers if you're using docker, you probably want to pin the container versions too. For azure app services I assume this is impossible if you use the installed runtime, so I'm not sure what can be done there.

That said, assuming you publish with CI, have you made sure to use an earlier version of the SDK in your pipeline?

[mitchelsellers]

@kanadaj all AppServices. So I'm basically screwed.

We have had to modify 400+ code files in the past 2 days to fix things. It's a nightmare

[JasonTheProgrammer]

assuming you publish with CI, have you made sure to use an earlier version of the SDK in your pipeline?

That worked for me in a DevOps build pipeline. YAML:

- task: UseDotNet@2
  displayName: 'Use .NET Core sdk 7.0.103'
  inputs:
    version: 7.0.103

[mitchelsellers]

@JasonTheProgrammer Yup! Tried that today, deployment to Azure AppService still has the issue.

We are publishing Self Contained for win-x64

[mitchelsellers]

Just to be 100% clear on what we have tried. We are using GitHub Actions for our build process

GitHub Action Step for Installation

- name: Ensure .NET Installed
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: '7.0.103'

We then also added a global.json file next to the .sln file with the following content

{
    "sdk": {
      "version": "7.0.103"
    }
  }

Our command for publishing is

dotnet publish "MyProject.csproj" --runtime win-x64 --self-contained --configuration Release --output ./App --no-restore  -p:version=2.0.3

Running/deploying using these steps did NOT fix the final solution. If I'm missing something I'm all ears

[JasonTheProgrammer]

@mitchelsellers For what it's worth, your global.json isn't specifying "rollForward": "disable" like offered in earlier examples. I don't know what the default behaviour is if that's not specified, but it could be rollowing forward to the later version?

The GitHub action step looks like it's just ensuring dotnet 7.0.103 is installed, not necessarily instructing the build to use that version.

What's your build log output saying with respect to SDK and MSBuild version? If it's showing MSBuild as "MSBuild version 17.5.0-preview-23061-01+040e2a90e for .NET", then you've not effectively pinned the earlier SDK. Pinning SDK 7.0.103 should result in it using MSBuild 17.4.1.

[mitchelsellers]

@JasonTheProgrammer it worked locally so I didn't expect it to behave differently. Without the "rollForward" bit in the global.json the MS Build version on the GitHub built was MSBuild version 17.5.0-preview-23061-01+040e2a90e for .NET.

I added the rollForward bit to my global.json so it looks like this now

{
    "sdk": {
      "version": "7.0.103",
      "rollForward": "disable"
    }
}

Still seeing the same MSBuild version when using that one

[kanadaj]

@mitchelsellers just to check, do you use self hosted Github Agents? I've had to manually delete the newer version of the SDK from my build agents because they kept using that from cache, though I didn't use global.json. Also, global.json has to be located in the current working directory of the build agent to be used by dotnet, so you might have to CD to the correct folder.

[mitchelsellers]

@kanadaj Ok, this is a fun one, our repository had the structure of

/
/src
/src/projects

Our solution file was in the /src folder, we had put the global.json there, which fixed locally etc. But didn't work with GitHub Actions.

Putting it in the root still allowed the local stuff to work, AND fixed it on GitHub Actions for now. The part I bolded from the docs here was what escaped my management

The .NET SDK looks for a global.json file in the current working directory (which isn't necessarily the same as the project directory) or one of its parent directories.

[chrux]

Perhaps, defining working-directory helps so you can define with that the src folder where the actual solution global.json is

[NemecMichal]

I just updated:

• SDK: 7.0.202, 6.0.407
• runtime: 7.0.4, 6.0.15
• VS for Mac: 17.5.2 (build 14)

and the problem is gone...

[indigogiant]

@indigogiant I just want to check if you've tested those versions you list, or if it was just assumption? Since my testing partly contradicts the versions you listed, I just wanted to check.

Sorry for the late response, probably not much use now but for what it's worth it's partly experience and partly assumption. We hit it when the VS build agents moved to the new runtimes, .406 was failing for us so curious that it worked for you.

It was mentioned elsewhere that the issue was related to those runtime versions, hence the caveat about it being from what I could gather.

[DavidTagt]

Sorry for the late response, probably not much use now but for what it's worth it's partly experience and partly assumption. We hit it when the VS build agents moved to the new runtimes, .406 was failing for us so curious that it worked for you.

It was mentioned elsewhere that the issue was related to those runtime versions, hence the caveat about it being from what I could gather.

Ah those sneaky runtimes! I completely missed that part, i don't think i ever checked that.
Anyway, the problem seems solved, so thanks everyone involved 🙂

[nmg196]

Is the problem resolved in Azure DevOps yet? I can see it's fixed in Visual Studio but I think the problem still happens if you build using Azure DevOps.

[gustafcarleson]

Fixed in VS 17.5.2?

[bfren]

Yes this was fixed in 17.5.2 - the installation of which removed all previous versions of the SDK installed on my machine so I'm left with only 7.0.202. That was quite a surprising behaviour, especially as I used the VS Updater to install the update - with no prompts asking me if that is what I wanted to happen.

However, I can confirm that (for me at least) publishing using 7.0.202 parses <vc:/> tags correctly.

[MichalSznajder]

For those using Rider: 7.0.202 seems to solve problem.

I target .NET 6 and I fixed SDK in global.json to 7.0.202. With this SDK vc taghelper is compiled as before.

[jjonescz]

Fixed by #8328.

The fix was released in .NET March 2023 Update (SDK 7.0.202 and 6.0.407) and Visual Studio 17.5.2.

[nickalbrecht]

Is it safe to assume that the update has also been made to azure, so that we can stop pinning build SDKs to 7.103

[nmg196]

Same question. It's been closed but is it actually fixed in Azure DevOps?

[jmguazzo]

Not fixed in Azure DevOps.
I just tried it and the agent hasn't been updated yet, the sdk for the win2022 is still 7.0.201.
Agent description page : https://github.com/actions/runner-images/blob/main/images/win/Windows2022-Readme.md

[nickalbrecht]

Finally got around to unpinning the SDK in my azure build, and just wanted to confirm that it works fine for me. In case the specific are pertinent to anyone, I'm using the windows-2019 image and using the following task in my YML build.

    - task: UseDotNet@2
      inputs:
        version: '7.0.x'
        includePreviewVersions: false

Build log shows that it resolved this to 7.0.203, and my view components are working fine.