0

I have an self hosted application targeting .NET 4.6.1 and project targeting Microsoft.NET.Sdk.Web I have added AspNetCore 2.2.0 package and have all dependencies updated to the latest .NET 4.6.1 compatible packages. When trying to render an CSHTML view from file there is an exception thrown with following error

Assembly 'Microsoft.AspNetCore.Mvc.Razor' with identity 'Microsoft.AspNetCore.Mvc.Razor, Version=3.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' uses 'System.Runtime, Version=4.2.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' which has a higher version than referenced assembly 'System.Runtime' with identity 'System.Runtime, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

The precompiled views are working just fine. So i am not sure whats going on here, as i understand Microsoft.AspNetCore.Mvc.Razor requires an higher version of System.Runtime?

I have checked the nuget repo and it seems that i am using the latest version so i am not sure where to look from here :(

Any ideas ?

NullReference
  • 862
  • 1
  • 11
  • 27
  • I'm not sure but this could help you: https://stackoverflow.com/questions/9219832/error-cs1705-which-has-a-higher-version-than-referenced-assembly – Lucas Derouin Jun 26 '20 at 17:33
  • Please share your Project file to us.May be you need `Microsoft.AspNetCore.Mvc.Razor` with Version 2.2.0. – Rena Jun 29 '20 at 02:37
  • @Rena I do use 2.2, tbh i am not even sure where the Version=3.1.0.0 coming from. Now i must note that precompiled views working fine and its just the ones that is rendered from file that fail. There is also bunch of errors like this The type forwarder for type 'System.Attribute' in assembly 'mscorlib' causes a cycle , Predefined type 'System.String' is not defined or imported , The type forwarder for type 'System.Object' in assembly 'netstandard' causes a cycle I can post the project file if required. – NullReference Jun 29 '20 at 07:39
  • @NullReference **don't** use .NET Framework 4.6 if you intend to use .NET Standard 2.0 packages. There are a ton of such incompatibilities. The attempt to back port .NET Standard 2.0 to 4.6 never worked. Even Microsoft [recommends using 4.7.2 at least](https://learn.microsoft.com/en-us/dotnet/standard/net-standard) `For .NET Framework projects that need to use such libraries, we recommend that you upgrade the project to target .NET Framework 4.7.2 or higher.` – Panagiotis Kanavos Jun 30 '20 at 15:13

2 Answers2

1

The only solution is to upgrade to .NET Framework 4.7.2. .NET 4.6 is not compatible with .NET Standard 2.0 and the attempts to backport .NET Standard 2.0 support failed, generating a ton of bad binding redirects every time a package was added or upgraded.

This means that bad redirects will keep appearing, forcing you to remove them before every deployment, or find out they crept back after a failed deployment.

In the end, the .NET team admitted back porting .NET Standard 2.0 was a bad idea. The current compatibility matrix documentation explains that :

2 The versions listed here represent the rules that NuGet uses to determine whether a given .NET Standard library is applicable. While NuGet considers .NET Framework 4.6.1 as supporting .NET Standard 1.5 through 2.0, there are several issues with consuming .NET Standard libraries that were built for those versions from .NET Framework 4.6.1 projects.

For .NET Framework projects that need to use such libraries, we recommend that you upgrade the project to target .NET Framework 4.7.2 or higher.

There are no significant incompatibilities between 4.6 and 4.7.2 either, so targeting a fresh runtime (the latest is 4.8) isn't a blocking issue

Panagiotis Kanavos
  • 120,703
  • 13
  • 188
  • 236
0

The problem was related to wrong binding redirects.

NullReference
  • 862
  • 1
  • 11
  • 27
  • You'll run into the same problem again. When you try to add a new package, or upgrade the existing ones, you'll get the bad redirects again. Backporting .NET Standard 2.0 to .NET Framework 4.6 never worked. Upgrade to .NET Framework 4.7.2 – Panagiotis Kanavos Jun 30 '20 at 15:14
  • BTW I run into exactly those problems years ago, and run into a *lot* of failed deployments. – Panagiotis Kanavos Jun 30 '20 at 15:16
  • I figured it out, the initial problem was due to wrong binding redirects so i can stick to 2.2 without going to newer .net version. – NullReference Jun 30 '20 at 15:17
  • No you can't. Those bad redirects were added automatically when you added ASP.NET Core. They'll be added *again* when you add another package, or upgrade the existing packages. Why try to ignore Microsoft's own recommendation? Why assume you can fix what the .NET team admitted was an unfixable idea? – Panagiotis Kanavos Jun 30 '20 at 15:18
  • Basically the auto-generate binding redirects was disabled in project file, once enabled it worked as intended. I totally agree with you but for now i am just not ready to go with higher version of .NET or .NET Core which is actually biggest priority for me.In any case really appreciate your input Pano , eyxaristo :) – NullReference Jun 30 '20 at 15:21
  • That didn't work either. This isn't a new problem, it's actually a 2+ year old issue that never worked. If you want to use ASP.NET Core, you have to use a compatible runtime. All you need to do is change the target in a dropdown. There are no significant differences between 4.6.1 and 4.7.2 – Panagiotis Kanavos Jun 30 '20 at 15:23
  • Its the deployment for the customers, we already plan to move to Core soon so we dont want to ask customers to ensure that they have .NET 4.7 installed and then in few months ask them to install the .NET Core again :) – NullReference Jun 30 '20 at 15:33
  • @PanagiotisKanavos You where right all the way, the moment the application is deployed on machine running 4.6.1 it fails, i have some other questions in regards of deployment of ref folder and PreserveCompilationContext but perhaps i should create another questions ? – NullReference Jul 01 '20 at 14:49