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).

[OronDF343]

I think I have figured it out. Here is my new minimal vsconfig that works:

{
  "version": "1.0",
  "components": [
    "Microsoft.VisualStudio.Component.Roslyn.Compiler",
    "Microsoft.Component.MSBuild",
    "Microsoft.VisualStudio.Component.CoreBuildTools",
    "Microsoft.VisualStudio.Workload.MSBuildTools",
    "Microsoft.Net.Component.4.TargetingPack"
  ],
  "extensions": []
}

I selected only .NET Framework 4 targeting pack from the individual components, without selecting any workloads. This made IntelliSense work. Doing the same wthing with only the 4.5 pack did not work, it has to be 4.

So the culprit appears to be .NET Framework 4 targeting pack which is only available in 2019 and below.

[CZEMacLeod]

@OronDF343 Great to have narrowed this down to a specific component. I wonder if using the SDK binding logging, we could find out exactly which component is trying to load the 4.0 target for intellisense. I would have expected it to use whichever target was set in the web.config (e.g. 4.8 in the example/templates).
Can you check your web.config for the following lines:

<compilation debug="true" targetFramework="4.8" />

<httpRuntime targetFramework="4.8" />

Assuming you have the 4.8 runtime or targeting pack installed.
I can't quiet work out if it is the intellisense engine for webforms that needs the pack, or that it is checking the code against the (wrong) runtime.

I guess another thing to test is do you get intellisense for 4.5+ features in your webforms code? (when it is working).

[OronDF343]

@CZEMacLeod For my last test I used the sample project provided by @julealgon which is set up to target 4.7.2:

<compilation debug="true" targetFramework="4.7.2" />
<httpRuntime targetFramework="4.7.2" />

This is the same as my own test project that I tested against previously at work.

As for IntelliSense framework versions, from the limited testing I've done it does seem like it is limited to Framework 4.0 features for C# snippets (in <%: %>). (My test for this is if there is a constructor for Regex that has a matchTimeout parameter.)

C# language version is always set to 4:

Web Forms 4.5 features are only partially available. For example, strongly-types data bindings were introduced in 4.5. BindItem completion works but the ItemType property is never shown in IntelliSense.

These limitations are not present in a regular Web Application project. I'll double-check at work in the coming week.

[leusbj]

@CZEMacLeod

From research done by @OronDF343 , it sure seems that something about the Editor pane's intellisense "needs" the 4.0 targeting pack (or runtime). And it seems true even if the main project is configured to build at a newer version, or the web.config is set to compile/run at a newer version.

I haven't seen an MSBuild Friendly mechanism to trigger/initiate the install of the 4.0 targeting pack (like something that might be baked into the "Project template"). But there might be a way of letting MSBuild inform the developer that under certain circumstances it could beneficial to install the 4.0 targeting pack.

MSBuild's current Microsoft.Common.CurrentVersion.targets file contains a GetReferenceAssemblyPaths target that calls a GetReferenceAssemblyPaths task in order to validate that the Project's desired targetFramework is in fact available for compiling against. and maybe in a similar fashion we could validate that the the 4.0 Targeting Pack is present.

Since this is only needed for intellisense (mostly on webforms files), and not the actual compilation of the project or debug/run time,, it should have very strict conditionals (Only DesignTime Builds, and Only when in VisualStudio, maybe more conditions like there are at least 1 ascx/aspx item)
This new target could execute the task GetReferenceAssemblyPaths with some specific params

<Target Name="AspNet_4_0_TargetingCheck" BeforeTargets="MvcBuildViews" Condition=" '$(DesignTimeBuild)' == 'true' AND '$(BuildingInsideVisualStudio)' " >
    <!-- Calling this task with the 4.0 version Moniker will check to help ensure -->
    <GetReferenceAssemblyPaths
        TargetFrameworkMoniker=".NETFramework,Version=v4.0"
        RootPath="$(TargetFrameworkRootPath)"
        TargetFrameworkFallbackSearchPaths="$(TargetFrameworkFallbackSearchPaths)"
        BypassFrameworkInstallChecks="$(BypassFrameworkInstallChecks)"
        ContinueOnError="true">
      <Output TaskParameter="ReferenceAssemblyPaths" PropertyName="_MvcBuildTargetFrameworkDirectories"/>
      <Output TaskParameter="FullFrameworkReferenceAssemblyPaths" PropertyName="_MvcBuildFullFrameworkReferenceAssemblyPaths"/>
      <Output TaskParameter="TargetFrameworkMonikerDisplayName" PropertyName="_MvcBuildTargetFrameworkMonikerDisplayName" />
    </GetReferenceAssemblyPaths>
</Target>

Doing something like the above (with ContinueOnError="true") will generate a Warning instead of an Error, that looks something like the following.

MSB3644 The reference assemblies for .NETFramework,Version4.0 were not found. To resolve this, install the Developer Pack (SDK/Targeting Pack) for this framework version or retarget your application, You can download .NET Framework Developer packs at https://aka.ms/msbuild/developerpacks

[CZEMacLeod]

@leusbj I think this is a good idea in general, but wonder if it should have a couple more conditional prerequisites - detecting the existence of a webforms page for instance.

Did any investigation go into adding the nuget package version of the targeting pack to the project? e.g.
Microsoft.NETFramework.ReferenceAssemblies.net40

Maybe with something like

   <PackageReference Include="" Version="1.0.*" GeneratePathProperty="true" />
   <TargetFrameworkFallbackSearchPaths>$(TargetFrameworkFallbackSearchPaths);$(Microsoft.NETFramework.ReferenceAssemblies.net40_Path)</TargetFrameworkFallbackSearchPaths>

I'm not sure of the exact syntax required here, if the search paths would affect visual studio intellisense, or if it would need to have .NETFramework\v4.0 appended, etc. but I think there is a little more investigation required here.

There is the new CoreWebForms project that is based on the systemweb-adapters project, that might have run into similar issues. Have you checked if there is a solution proposed there?

[CZEMacLeod]

@OronDF343

C# language version is always set to 4:

You should be able to use new language features - you will need to set 2 things.
One is the <LangVersion> property in the project file - to e.g. 6.0 or even 10.0 etc.
The other is to adjust the web.config line that is added for the roslyn compilers...

<compiler language="c#;cs;csharp" 
    extension=".cs" 
    type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=3.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" 
    warningLevel="4" 
    compilerOptions="/langversion:default /nowarn:1659;1699;1701" />

Change the complierOptions flag for /langversion to /langversion:6.0 or whatever to match.

I did consider adding some code to patch up the web.config file to match the project file, but never got very far with the thought.
I think the langversion flag for the compliers, perhaps the nowarn properties too would be possible to do.
Also the

<compilation targetFramework="4.7.2" />
<httpRuntime targetFramework="4.7.2" />

Should really update to match the TargetFramework property (or the computed version number from it at any rate - TargetFrameworkVersion).

I don't know if these should/could be done as xmlpoke actions, or better with a custom task which only makes changes if it detects a mismatch.
As these are normally one off actions, I didn't spend any real time on it, but for others, it might be useful to ensure that everything is in sync correctly across all the web.config files etc. (e.g. when using Razor Views compilation).

[OronDF343]

@CZEMacLeod That is not the issue. My web.config is definitely set up correctly (and is working as is in the legacy Web Site project with whatever language and framework versions I set). The issue is specific to SDK-style projects.

I do not think that installing the 4.0 targeting pack is a viable long-term solution as it doesn't solve the underlying issue. Legacy projects do not require this for IntelliSense to work because they use the correct framework version. This seems to me like an issue with VS.

Here are the actual settings that I am using right now:

  <system.codedom>
    <compilers>
      <compiler extension=".cs" language="c#;cs;csharp" warningLevel="4" compilerOptions="/langversion:10 /nowarn:1659;1699;1701;612;618" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
      <compiler extension=".vb" language="vb;vbs;visualbasic;vbscript" warningLevel="4" compilerOptions="/langversion:default /nowarn:41008,40000,40008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
    </compilers>
  </system.codedom>

  <httpRuntime targetFramework="4.7.2" executionTimeout="600" maxRequestLength="2097151" requestValidationMode="2.0" maxQueryStringLength="2097151"/>

  <compilation batchTimeout="3600" debug="true" defaultLanguage="c#" batch="true" tempDirectory="C:\TempAspNetFiles\" targetFramework="4.7.2">

[CZEMacLeod]

@OronDF343 Looks good. I am surprised you are getting the CS8025 error when using the null propagation operator in webforms as it should be compiling using the newer version of roslyn and langversion 10 as you specify. Just as a quick check - I think it should be 10.0 not 10 but I don't think csc.exe is too bothered.

[CZEMacLeod]

@OronDF343 You're right about the fact that it looks like the issue is with VS. Unfortunately, I cannot progress that, unless someone finds a way to force VS to work correctly, or an issue with VS gets raised and the underlying problem fixed.

Because these are legacy technologies, and not actively supported, I doubt you will be able to get anyone to put any effort into investigating or fixing it from Microsoft's end, but I might be wrong - especially with the new CoreWebForms project being a thing now.

[OronDF343]

@CZEMacLeod 10.0 versus 10 does not matter to the toolchain, they are aliased. In general, the language version warning does not happen consistently. I haven't been able to repro it at work for a long time.

[julealgon]

especially with the new CoreWebForms project being a thing now.

I hadn't heard of that project until this mention from you @CZEMacLeod . Have you considered "joining forces" with them on this effort? Would be absolutely amazing to have not only proper support for SDK-style projects fully working with WebForms but also be able to migrate to modern frameworks.

[CZEMacLeod]

@julealgon I have put some effort into the systemweb-adapters project, and am looking at the stuff in corewebforms - @twsouthwick has been doing some great stuff there, some of which has actually been moved into the systemweb-adapters project.
Personally, I'd love to be able to more easily migrate the projects I have in aspnet 4.x, but these projects were not quite there (yet) for me to be able to do so.
If I have more spare time, I'm hoping to have another go with the latest versions and see what the gap is for me now, and if there is anything I can contribute that would get me there.