Share via

An asp.net web form works in visual studio, works browsing from IIS, but fails from remote browser

Crosswhite, Jesse 20 Reputation points
2025-10-24T13:39:34.0633333+00:00

I have an asp.net app with simple web forms. It works from Visual studio 2022. it works when its deployed to IIS if I browse from IIS but from a desktop it throws an error (below). I not sure where the version 1.0.0.0 comes from because Microsoft.Web.Infrastructure 2.0.0 is the NuGet package associated with the project. There are other similar web apps deployed on the server that are working.

I'm looking for why the web app fails unless its running on the same machine as the browser.

"Could not load file or assembly 'Microsoft.Web.Infrastructure, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)"

=== Pre-bind state information ===
LOG: DisplayName = Microsoft.Web.Infrastructure, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
 (Fully-specified)
LOG: Appbase = file:///D:/WSFApps/Apps/
LOG: Initial PrivatePath = D:\WSFApps\Apps\bin
Calling assembly : System.Web.Optimization, Version=1.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: D:\WSFApps\Apps\web.config
LOG: Using host configuration file: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Microsoft.Web.Infrastructure, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/root/caffad67/991609de/Microsoft.Web.Infrastructure.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/root/caffad67/991609de/Microsoft.Web.Infrastructure/Microsoft.Web.Infrastructure.DLL.
LOG: Attempting download of new URL file:///D:/WSFApps/Apps/bin/Microsoft.Web.Infrastructure.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
Developer technologies | ASP.NET | Other
Answer accepted by question author
  1. Jack Dang (WICLOUD CORPORATION) 4,865 Reputation points Microsoft External Staff Moderator
    2025-10-29T08:38:56.5833333+00:00

    Hi @Crosswhite, Jesse ,

    Thanks for confirming those test results - that extra detail helps narrow this down.

    Since disabling impersonation already resolved the local and Visual Studio cases, the core assembly loading issue is no longer present. The fact that it still fails only when accessed remotely points to an IIS authentication or environment configuration difference rather than a code or package problem.

    When the request comes from a remote browser, IIS may run it under a different identity or security context than when browsing locally. This can occur if Anonymous Authentication is disabled or if Windows Authentication isn’t configured for Kerberos delegation. In those cases, the request might no longer run under the account that has permission to load assemblies or access the ASP.NET Temporary Files folder, causing the failure to reappear.

    To make the site work for all users remotely, ensure it always runs under the Application Pool identity - for example, by keeping impersonation disabled and enabling Anonymous Authentication. IIS will then handle all requests using a consistent, trusted account. You can still retrieve usernames for display or logging without impersonation.

    If Windows Authentication is required, double-check that Kerberos delegation and SPNs are correctly configured for the app pool account. Otherwise, remote requests may fall back to NTLM and lose access permissions.

    Once authentication and identity settings are aligned, the app should behave consistently for both local and remote users.Hope this helps! If my answer was helpful - kindly follow the instructions here so others with the same problem can benefit as well.

    0 comments

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jack Dang (WICLOUD CORPORATION) 4,865 Reputation points Microsoft External Staff Moderator
    2025-10-27T07:17:09.2166667+00:00

    Hi @Crosswhite, Jesse ,

    Thanks for your question! The error:

    Could not load file or assembly 'Microsoft.Web.Infrastructure, Version=1.0.0.0'...

    occurs because something in your app (likely System.Web.Optimization) is trying to load version 1.0.0.0, while your project has the Microsoft.Web.Infrastructure 2.0.0 NuGet package installed. This version mismatch causes the runtime to fail when accessed remotely.

    Solution 1: Add a binding redirect

    In web.config under <runtime>:

    <runtime>
   <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
         <assemblyIdentity name="Microsoft.Web.Infrastructure" publicKeyToken="31bf3856ad364e35" culture="neutral" />
         <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
   </assemblyBinding>
</runtime>

    Then restart IIS. This tells the runtime to use the assembly from your NuGet package whenever version 1.0.0.0 is requested.

    Solution 2: Verify DLL deployment

    Ensure Microsoft.Web.Infrastructure.dll is present in your app’s /bin folder. If it’s missing, reinstall via NuGet:

    Update-Package Microsoft.Web.Infrastructure -reinstall

    Rebuild and redeploy.

    Optional

    Check for older versions in the GAC:

    gacutil -l Microsoft.Web.Infrastructure

    If version 1.0.0.0 exists and isn’t needed by other apps, it can be removed to prevent conflicts.

    The runtime is looking for v1.0.0.0 while your project has the 2.0.0 NuGet package. Adding a binding redirect and ensuring the DLL is deployed should resolve the remote load error.

    Also, please confirm whether creating a blank project can reproduce the issue.

    Hope this helps! If my answer was helpful - kindly follow the instructions here so others with the same problem can benefit as well.

  2. Crosswhite, Jesse 20 Reputation points
    2025-10-28T13:36:24.1533333+00:00

    After starting with a fresh project and adding and testing at each step I found the issue. I had set asp impersonation on to get the user ID. Leaving asp impersonation off and using HttpContext.Current.Request.LogonUserIdentity.Name; for the name worked. I think the biggest hint is it worked in VS and if I was on the server running the web app but failed when a remote connection happened.

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.