aspnet_compiler finding wrong version of System.Web.WebPages 1.0.0.0 instead of 2.0.0.0
Asked Answered
B

11

38

I have an ASP.NET MVC4 project which compiles fine in VS2010. For deployment purposes I run a Nant script which attempts to precompile the website using aspnet_compiler.exe but I keep running into an assembly reference issue with System.Web.WebPage

error CS1705: Assembly 'System.Web.Mvc, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' uses 'System.Web.WebPages, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' which has a higher version than referenced assembly 'System.Web.WebPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'

I also have the following assembly bindings in my web.config:

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
            <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
            <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
            <bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="System.Web.WebPages.Razor" publicKeyToken="31bf3856ad364e35" />
            <bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
        </dependentAssembly>
    </assemblyBinding>
</runtime>

and my csproj has the following reference:

<Reference Include="System.Web.WebPages, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
  <Private>True</Private>
 <HintPath>..\packages\AspNetWebPages.Core.2.0.20126.16343\lib\net40\System.Web.WebPages.dll</HintPath>
</Reference>
Binturong answered 1/5, 2012 at 17:58 Comment(0)
F
40

I solved this problem by explicitly referencing the 2.0 assembly in Web.config. I suppose that for some reason, the ASP.NET compiler (in my case when running MvcBuildViews), uses the old 1.0 assembly first, if it is found.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <!-- … -->
  <system.web>
    <!-- … -->
    <compilation debug="true" targetFramework="4.0">
      <assemblies>
        <add assembly="System.Web.Mvc, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />
        <add assembly="System.Web.Abstractions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
        <add assembly="System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
        <add assembly="System.Web.WebPages, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />
      </assemblies>
    </compilation>
    <!-- … -->
  </system.web>
  <!-- … -->
</configuration>

BTW: It looked like this problem occurred for the first time after I added a 3rd party ASP.NET MVC 3.0 component. That component works fine through the assembly binding, but it may be the reason why the ASP.NET compiler tries to load the 1.0 web pages first.

Flemming answered 3/5, 2012 at 12:8 Comment(1)
I started doing this, and then realized that all the MVC was version 3, so instead of changing the web config, I actually replaced the referenced dll with the correct version.Immobile
A
8

We had similar problem.

We are now using Visual Studio 2012 for developing and when we converted a 2010 project to 2012 and tried to deploy that, ASP.NET was requiring 2.0.0.0 instead of 1.0.0.0.

After some investigation I saw that the project was not referencing a specific version of System.Web.WebPages, so after upgrading to VS 2012 it was finding the 2.0.0.0 version.

If you remove the reference from your project and then re-add the specific version from the GAC, it works correctly.

Aviate answered 11/9, 2012 at 9:27 Comment(1)
Exactly the same here - removing reference and adding it from GAC works.Kegan
P
3

For us, the problem was an old copy of the relevant DLL in the _bin_deployableAssemblies folder. Deleting this got us correctly configured with the 2.0 version.

Parkerparkhurst answered 24/9, 2012 at 22:30 Comment(2)
Thank you, this just solved an issue I was dealing with for two days, I didn't realize I had that directory.Hey
Glad it helped, sorry to hear about the lost time :)Parkerparkhurst
U
2

This error also occurs for me when MvcBuildViews is set to true.

I noticed that I would always get this error when building the entire solution using 'Build Solution'. At that point, if I immediately built the MVC project by itself (right click on the project then Build), the MVC project would build successfully.

It seems that building the MVC project by itself would succeed as long as it does not trigger builds on its depended projects (ie. they are up-to-date). But building using 'Build Solution' always fails with this error.

Udell answered 10/7, 2012 at 4:10 Comment(0)
T
2

I experienced this problem when upgrading a site from MVC 3 to 5.2.3.0.

My issue was TFS not adding the packages and associated DLL's from the nuget installation.

I manually added the following folders in the packages folder of the solution.

Microsoft.AspNet.Razor.3.2.3
Microsoft.AspNet.WebPages.3.2.3

Microsoft.Web.Infrastructure.1.0.0.0

Once comitted the build server no longer had the issue.

Talus answered 25/7, 2015 at 11:6 Comment(0)
P
1

I scratched my head for a while over this problem when I had it. Eventually I noticed that I had the following section in the "runtime" section of my web.config.

<runtime>
 . . .
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
. . .
</runtime>

As you can see, this refers to version 2 of the assembly, which doesn't match the following code that you also have in the system.web/compilation/assemblies section of web.config.

<add assembly="System.Web.WebPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />

The actual assembly referenced in References for the project is indeed v1.0.0.0, so I changed the first chunk of code above to the following, which fixed the problem immediately. I'm not sure how the mistake got there in the first place.

<runtime>
 . . .
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="1.0.0.0" />
      </dependentAssembly>
. . .
</runtime>
Pavyer answered 10/1, 2013 at 10:59 Comment(0)
T
1

For me it was a reference to System.Web.WebPages.Administration v1.0.0.0 who was the culprit. Once removed, all worked without any Web.config tweaks.

Taxdeductible answered 14/3, 2013 at 14:3 Comment(0)
N
0

In such a case, it's worth doing a 'Find in Files' across all files in your solution's root folder.

For the example above, I'd have searched for: System.Web.WebPages, Version=1.0.0.0

In this way you can get rid of all references to the old version.

Nailbrush answered 2/10, 2012 at 16:46 Comment(0)
L
0

For me this issue was most likely caused buy updating to the latest version of .NET via the Web Platform installer but I did not have the latest version of ASP.NET MVC installed. Updating this Via the Web Platform installer fixed the issues.

Lisle answered 12/9, 2013 at 6:43 Comment(0)
D
0

just go to references and search for System.Web.Mvc version 4.0 or more and add it. I just add a reference of System.web.mvc 4.0.0.1 and it works.

Don't forget to remove older mvc version.

Drees answered 2/2, 2015 at 4:33 Comment(0)
H
0

Deleting and Re-Adding the Reference System.Web.Mvc Did the job for me

Hesione answered 8/6, 2015 at 8:0 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.