Web.config中的奇怪警告

Question

A picture is worth 1000 words, so here are several pictures (ignore my redacting):

I am neither referencing nor using Entity Framework in any project in this solution. This just started happening as of Tuesday after I installed a bunch of Windows updates. There are nine warnings in total. I'm running Windows 8.1 Pro, but I don't know if that matters. I have other projects in the same solution with identical project types and .NET framework versions. The project itself appears to run just fine in IIS. All of my Web.config files have similar configuration and structure. This is the problematic one (more redacting):

<?xml version="1.0"?>
<configuration>
    <configSections>
        ...
    </configSections>
    ...
    <connectionStrings>
        ...
    </connectionStrings>
    <system.web>
        <compilation debug="true" targetFramework="4.5.1"/>
        <authentication mode="None"/>
        <sessionState mode="Off"/>
        <customErrors mode="RemoteOnly"/>
        <httpRuntime enableHeaderChecking="false" enableVersionHeader="false" requestValidationMode="2.0" sendCacheControlHeader="false" targetFramework="4.5.1"/>
    </system.web>
    <system.webServer>
        <httpErrors existingResponse="PassThrough"/>
        <validation validateIntegratedModeConfiguration="true"/>
        <handlers>
            <remove name="ExtensionlessUrlHandler-Integrated-4.0"/>
            <remove name="OPTIONSVerbHandler"/>
            <remove name="TRACEVerbHandler"/>
            <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0"/>
        </handlers>
        <staticContent>
            <clientCache cacheControlMode="UseMaxAge" httpExpires="7.00:00:00"/>
        </staticContent>
        <urlCompression doStaticCompression="true" doDynamicCompression="true" dynamicCompressionBeforeCache="true"/>
        <defaultDocument>
            <files>
                <clear/>
            </files>
        </defaultDocument>
    </system.webServer>
    <system.runtime.caching>
        <memoryCache>
            <namedCaches>
                ...
            </namedCaches>
        </memoryCache>
    </system.runtime.caching>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Data.OData" publicKeyToken="31bf3856ad364e35" culture="neutral"/>
                <bindingRedirect oldVersion="0.0.0.0-5.6.0.0" newVersion="5.6.0.0"/>
            </dependentAssembly>
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Data.Edm" publicKeyToken="31bf3856ad364e35" culture="neutral"/>
                <bindingRedirect oldVersion="0.0.0.0-5.6.0.0" newVersion="5.6.0.0"/>
            </dependentAssembly>
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.ServiceBus" publicKeyToken="31bf3856ad364e35" culture="neutral"/>
                <bindingRedirect oldVersion="0.0.0.0-2.2.0.0" newVersion="2.2.0.0"/>
            </dependentAssembly>
            <dependentAssembly>
                <assemblyIdentity name="System.Spatial" publicKeyToken="31bf3856ad364e35" culture="neutral"/>
                <bindingRedirect oldVersion="0.0.0.0-5.6.0.0" newVersion="5.6.0.0"/>
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
</configuration>

Answer 1

I am still not sure how, but I managed to "fix" the problem by deleting Web.config and its transforms and recreating them. I did a diff afterward and didn't see any differences that might cause such warnings. I guess I can chalk it up to some kind of strange caching issue.

Answer 2

I found this old question while searching a solution for a similar problem in Visual Studio 2017. The accepted answer put me on the right track. This must be a caching problem. One search more - this is an intellisense caching problem.

There is a very good article from Rick Strahl about this.

My problem was solved by removing the .vs folder from the solution. The .vs folder was introduced with Visual Studio 2015. So this isn't a direct answer to this question, but a hint for future visitors.