Broken intellisense and aspnet warnings on WebForms projects

[julealgon]

After migrating our main WebForms projects to use this SDK, we noticed that the intellisense on aspx files (and any others such as ascx, etc) stopped working properly. Additionally, on each opened file, an error is indicated like this at the very first line:

Autocomplete doesn't show normal asp: controls as well:

Standard	SDK

I tried deleting the contents in the %LocalAppData%\Microsoft\VisualStudio\[Version Number]\ComponentModelCache folder and restarting Visual Studio. When I do that, intellisense starts working for a bit, but after a few seconds (not doing anything in VS, just time based apparently), intellisense just stops working again.

To ensure this wasn't something particular to our project, I proceeded to create a brand new WebForms project using the standard VS template. I then performed the same conversion steps that we did on our real project on this minimal template, and I started observing the exact same behavior.

After the conversion, I attempted adding the EnableWebFormsDefaultItems msbuild flag (which I was unaware of) as well as tried using different versions of the DotNetCompiler (when we migrated our own project, we used the ExcludeSDKDefaultPackages flag).

Is this a known issue? How do I fix it?

For reference, here is a solution with 2 projects from the standard template: 1 converted, and the other standard.

• WebFormsSDK-IntellisenseBrokenSample.zip

[CZEMacLeod]

@julealgon
A few quick notes:

• You seemed to have missed correctly creating the launchSettings.json file and thus the F5 debug didn't work in your example.
• You don't need to define EnableWebFormsDefaultItems as it is true by default. This is only required for specific scenarios where you don't want to use the built in globbing system.
• You don't need the Reference items as these are brought in automatically by the base SDK.
• You don't need AppendTargetFrameworkToOutputPath as this is set by the SDK.

<Project Sdk="MSBuild.SDK.SystemWeb/4.0.88">

	<PropertyGroup>
		<TargetFramework>net472</TargetFramework>
		<GeneratedBindingRedirectsAction>Overwrite</GeneratedBindingRedirectsAction>
	</PropertyGroup>

	<ItemGroup>
		<PackageReference Include="Microsoft.Web.Infrastructure" Version="2.0.1" />
		<PackageReference Include="AspNet.ScriptManager.jQuery" Version="3.4.1" />
		<PackageReference Include="Microsoft.AspNet.ScriptManager.MSAjax" Version="5.0.0" />
		<PackageReference Include="Microsoft.AspNet.ScriptManager.WebForms" Version="5.0.0" />
		<PackageReference Include="Microsoft.AspNet.Web.Optimization" Version="1.1.3" />
		<PackageReference Include="Newtonsoft.Json" Version="12.0.2" />
		<PackageReference Include="WebGrease" Version="1.6.0" />
		<PackageReference Include="Antlr3.Runtime" Version="3.5.1" />
		<PackageReference Include="Microsoft.AspNet.Web.Optimization.WebForms" Version="1.1.3"/>
		<PackageReference Include="Microsoft.AspNet.FriendlyUrls" Version="1.0.2" />
	</ItemGroup>

</Project>

{
    "iisSettings": {
        "windowsAuthentication": false,
        "anonymousAuthentication": true,
        "iisExpress": {
            "applicationUrl": "http://localhost:51867/",
            "sslPort": 0
        }
    },
    "profiles": {
        "IIS Express": {
            "commandName": "IISExpress",
            "launchBrowser": true,
            "environmentVariables": {
                "ASPNETCORE_ENVIRONMENT": "Development"
            }
        }
    }
}

I can't really help beyond that - the issue with intellisense is down in visual studio and/or the compiler, not the SDK.
The LSP system has fixes in place to force the old style parsing for razor pages to allow editing MVC easily, but it looks like there is something in the base VS product that doesn't handle aspx/ascx etc. files well.

I wouldn't recommend using this for 'greenfield' development (not that many people are likely to be doing that with either .net 4.x or webforms), but it is more meant to be able to build well in a CI/CD system and allow you to easily manage package updates etc. which are some of the major advantages of the new project format.
I would recommend only using it to maintain an existing site, where you are most like to be doing one of 4 activities:

1. Editing 'text' (or html) content in webform pages. The main reason for this is that no modification of controls etc. will work as the back end to update the .designer.cs files does not work without the old project system.
2. Editing of code - intellisense should work correctly in the code behind files, and allow you to make fixes or changes to the code.
3. Editing of content - css, javascript, images, etc. Again, intellisense will work for these files, and adding/altering content files is handled by the globbing to make it easier to manage the project file, especially in a team environment.
4. Updating packages due to security fixes or similar. For instance in an Owin based application maybe you want to update the security packages due to changes to the backends used for authentication, or if a security flaw is found.

It can also be useful if you are migrating to a new aspnetcore application using systemweb-adapters.

I don't know if you will be able to get any help from Microsoft on this, but I would suggest asking on some of the forums etc. to see if anyone has any insight.
If you find a solution to the problem, please do come back to me and we can see if it can be built into the SDK for other webforms users.

[julealgon]

• You seemed to have missed correctly creating the launchSettings.json file and thus the F5 debug didn't work in your example.

Ah, right. I wasn't looking into this at all since in our development environment for this project we all use full IIS. I appreciate the reminder though.

• You don't need to define EnableWebFormsDefaultItems as it is true by default. This is only required for specific scenarios where you don't want to use the built in globbing system.

Oh really? I didn't realize that. Thanks for pointing it out, that's less noise to maintain in the csproj :)

• You don't need the Reference items as these are brought in automatically by the base SDK.

Fair. I did a crude migration and just kept all the existing packages for now (same as I did on our large project here). Trimming down dependencies was going to be a next step that I was going to look into, including packages already covered by the SDK.

• You don't need AppendTargetFrameworkToOutputPath as this is set by the SDK.

Again, nice to know! I'll definitely remove that as the less noise in the csproj the better. That property actually came from an executable project we migrated recently from old to SDK-style csproj and I added this explicitly there because we have a few places depending on the output path in a hardcoded manner.

I can't really help beyond that - the issue with intellisense is down in visual studio and/or the compiler, not the SDK. The LSP system has fixes in place to force the old style parsing for razor pages to allow editing MVC easily, but it looks like there is something in the base VS product that doesn't handle aspx/ascx etc. files well.

That's sad to hear. I'll do a few extra tests here to confirm that nothing else in the old csproj controls this, but it looks like I might just be out of luck. I thought you'd be able to help me out in seeing what the errors were though: in particular, that cryptic error message in the first line of the file, it looks like it is somehow missing the actual error in the tooltip and I can't find it anywhere.

I wouldn't recommend using this for 'greenfield' development (not that many people are likely to be doing that with either .net 4.x or webforms), but it is more meant to be able to build well in a CI/CD system and allow you to easily manage package updates etc. which are some of the major advantages of the new project format. I would recommend only using it to maintain an existing site, where you are most like to be doing one of 4 activities:

1. Editing 'text' (or html) content in webform pages. The main reason for this is that no modification of controls etc. will work as the back end to update the .designer.cs files does not work without the old project system.
2. Editing of code - intellisense should work correctly in the code behind files, and allow you to make fixes or changes to the code.
3. Editing of content - css, javascript, images, etc. Again, intellisense will work for these files, and adding/altering content files is handled by the globbing to make it easier to manage the project file, especially in a team environment.
4. Updating packages due to security fixes or similar. For instance in an Owin based application maybe you want to update the security packages due to changes to the backends used for authentication, or if a security flaw is found.

Yeah, we are not developing any new application using WebForms at the moment. This is a (fairly large) webforms project where most newer parts of it are actually leveraging angular inside a webforms container. However, for ultra simple/report-like pages, we sometimes still rely on new webforms pages to do it due to simplicity. Being able to fix the intellisense/errors issue would be nice but is probably not 100% critical.

Intellisense somehow seems to work after I add the whole element tag (for example, to show attributes of controls and such). It is really weird what is going on there.

It can also be useful if you are migrating to a new aspnetcore application using systemweb-adapters.

Had never heard of this project before. Might actually be interesting for some migration efforts we'll be doing in the near future. Thanks for bringing that up.

I don't know if you will be able to get any help from Microsoft on this, but I would suggest asking on some of the forums etc. to see if anyone has any insight. If you find a solution to the problem, please do come back to me and we can see if it can be built into the SDK for other webforms users.

I'll reach out to them and post back with updates.

I think you should consider marking this as a "known limitation" if you also confirmed the behavior on your side. Would help others with WebForms projects like myself in the future. This caught me by surprise unfortunately.

[robrobrobrob]

I'm experiencing the same issue. In addition to no Intellisence, I'm unable to set breakpoints and debug. Only workaround I have found is to split up aspx/aspx.cs, but not a great solution with hundreds of aspx's

[CZEMacLeod]

@robrobrobrob As I said earlier in this thread - if you are doing ongoing development work with webforms, this project may not be the best choice for you.
If you have encapsulated your logic and code into classes or (at worst) code behinds, that is much easier to manage, and would allow you an easier path when you come to migrate to a net6+ solution.
In the case of webforms, I would recommend it only for mature sites where you may need to modify content/basic html and/or css to keep up with newer browsers for instance, and want to make it easy to manage your package dependencies. In other cases - it is probably better to stick with the original project style since it is supported and handles all the features of webforms correctly.

[leusbj]

@julealgon I tried your sample project and were not getting the errors/warnings you were seeing, and so I'm curious if you would share some more information:

Looks like you are using Visual Studio 2022 is that right? and which version (Community/Professional/Enterprise)?
Are you in "Debug" or "Release" mode?

The one picture that appears to come from hovering over the root element of Default.aspx showing "ASP.NET runtime error:" does it give you the text of the error?

If you are not in "release" mode, can you see if switching over to release mode makes this error appear in the "Build Output" tab at the bottom of visual studio, or does it only appear in intellisense when editing an aspx file?

[julealgon]

@julealgon I tried your sample project and were not getting the errors/warnings you were seeing, and so I'm curious if you would share some more information:

@leusbj Notice that I shared a solution with 2 projects in it: one "vanilla", and the other "converted". Are you sure you were checking the converted one, and not the vanilla one?

I kept both in there for comparison purposes, but only the second project (WebApplication2) is the problematic one there.

Looks like you are using Visual Studio 2022 is that right? and which version (Community/Professional/Enterprise)? Are you in "Debug" or "Release" mode?

I'm using VS2022 Professional 17.7.5. If I switch from Debug to Release, nothing changes: I'm still getting the same warning the same way:

The one picture that appears to come from hovering over the root element of Default.aspx showing "ASP.NET runtime error:" does it give you the text of the error?

No. There is nothing else to the message. It stops at "ASP.NET runtime error:", both in the tooltip when hovering, as well as in the warnings as you can see above.

If you are not in "release" mode, can you see if switching over to release mode makes this error appear in the "Build Output" tab at the bottom of visual studio, or does it only appear in intellisense when editing an aspx file?

As per the above, switching doesn't make any difference, and the warning still appears "truncated".

The build output does not show the error:

Build started...
1>------ Build started: Project: WebApplication1, Configuration: Release Any CPU ------
2>------ Build started: Project: WebApplication2, Configuration: Release Any CPU ------
1>  WebApplication1 -> C:\Users\Juliano Gonçalves\source\repos\WebApplication2\WebApplication1\bin\WebApplication1.dll
2>WebApplication2 -> C:\Users\Juliano Gonçalves\source\repos\WebApplication2\WebApplication2\bin\WebApplication2.dll
2>C:\Users\Juliano Gonçalves\.nuget\packages\microsoft.codedom.providers.dotnetcompilerplatform\3.6.0\build\net472\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.targets(8,9): message : MSB4120: Item 'RoslynCompilerFiles' definition within target references itself via (qualified or unqualified) metadatum 'RecursiveDir'. This can lead to unintended expansion and cross-applying of pre-existing items. More info: https://aka.ms/msbuild/metadata-self-ref
2>C:\Users\Juliano Gonçalves\.nuget\packages\microsoft.codedom.providers.dotnetcompilerplatform\3.6.0\build\net472\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.targets(8,9): message : MSB4120: Item 'RoslynCompilerFiles' definition within target references itself via (qualified or unqualified) metadatum 'Filename'. This can lead to unintended expansion and cross-applying of pre-existing items. More info: https://aka.ms/msbuild/metadata-self-ref
2>C:\Users\Juliano Gonçalves\.nuget\packages\microsoft.codedom.providers.dotnetcompilerplatform\3.6.0\build\net472\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.targets(8,9): message : MSB4120: Item 'RoslynCompilerFiles' definition within target references itself via (qualified or unqualified) metadatum 'Extension'. This can lead to unintended expansion and cross-applying of pre-existing items. More info: https://aka.ms/msbuild/metadata-self-ref
========== Build: 2 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
========== Build started at 2:08 PM and took 13.107 seconds ==========

[robrobrobrob]

@julealgon Thought I'd add, there is only 1 developer on my team which can successfully get intellisense on the SDK csproj in VS2022 (17.7.5 Pro, .NET Runtime 6.0.23, .NET SDK 7.0.402). So it is possible. I've tried the exact same setup without any luck.

Also, developers using Rider don't have this issue with SDK csproj.

[julealgon]

@julealgon Thought I'd add, there is only 1 developer on my team which can successfully get intellisense on the SDK csproj in VS2022 (17.7.5 Pro, .NET Runtime 6.0.23, .NET SDK 7.0.402). So it is possible. I've tried the exact same setup without any luck.

That's fascinating! If you ever find out how this was possible, please post it here @robrobrobrob .

Also, developers using Rider don't have this issue with SDK csproj.

I had no idea Rider dealt better with this. Good to know, even if our team currently doesn't use it.

[OronDF343]

IntelliSense was working for me until I removed Visual Studio 2019 and updated Visual Studio 2022 from 17.8.2 to 17.8.3+. So it might be related to some old component that isn't included anymore.

I had reported an issue here before realizing that it was already mentioned here and specific to this project type.

[julealgon]

IntelliSense was working for me until I removed Visual Studio 2019 and updated Visual Studio 2022 from 17.8.2 to 17.8.3+. So it might be related to some old component that isn't included anymore.

This is promising @OronDF343 ! If we could find what component that is that would be awesome!

Are you sure the 2022 update was part of it breaking down though?

[OronDF343]

IntelliSense was working for me until I removed Visual Studio 2019 and updated Visual Studio 2022 from 17.8.2 to 17.8.3+. So it might be related to some old component that isn't included anymore.

This is promising @OronDF343 ! If we could find what component that is that would be awesome!

Are you sure the 2022 update was part of it breaking down though?

It's more likely that removing 2019 is what caused it, considering others' reports in this issue. I'll maybe check on some coworkers' PCs next week and see if there is any correlation (some have older installations).

[OronDF343]

Here is what I have been able to discover: (sample size = 7 PCs)

• PCs that has Visual Studio 2019 installed does not have the issue in Visual Studio 2022
• PCs that has Visual Studio Build Tools 2019 installed does not have the issue in Visual Studio 2022. Interestingly, the Visual Studio Build Tools 2019 installations included mostly C++ components
• The PCs that have only Visual Studio 2022 installed (without any 2019 versions) have the issue. Versions found: 17.6.4, 17.8.3, 17.8.4

I was able to get IntelliSense working on my machine by installing Visual Studio Build Tools 2019, selecting "Desktop development with C++" and deselecting all of the optional features. Here is my vsconfig:

{
  "version": "1.0",
  "components": [
    "Microsoft.VisualStudio.Component.Roslyn.Compiler",
    "Microsoft.Component.MSBuild",
    "Microsoft.VisualStudio.Component.CoreBuildTools",
    "Microsoft.VisualStudio.Workload.MSBuildTools",
    "Microsoft.VisualStudio.Component.Windows10SDK",
    "Microsoft.VisualStudio.Component.VC.CoreBuildTools",
    "Microsoft.VisualStudio.Component.VC.Redist.14.Latest",
    "Microsoft.VisualStudio.Component.TextTemplating",
    "Microsoft.VisualStudio.Component.VC.CoreIde",
    "Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Core",
    "Microsoft.VisualStudio.Workload.VCTools"
  ],
  "extensions": []
}

So something to do with the 2019 MSBuild core packages?

[julealgon]

@OronDF343 that's amazing.... it works! After closing VS, installing 2019 build tools using your steps, and then reopening my aspx files, the error squiggle lines are all gone, and after a minute or so, all intellisense is working perfectly, autocompleting both properties of existing controls and new tags from scratch.

It would be great if we could spot precisely which of the components above does it, but honestly... I feel like this can already be closed at this point, that's just an optimization! Thoughts @CZEMacLeod ?

[CZEMacLeod]

I'd really like to know which 2019 component is required for this to work properly. It feels like it might be a 32bit component (since 2022 is 64bit) that isn't installed otherwise, but that would just be a guess.

If anyone has time to try stripping out components until it works it would give a minimal solution, and require the least amount of space and updates...

I would start with just MSBuild perhaps... (or the first 4 items).