DOTNET 6 Error - Cannot find compilation library location for package 'System.Security.Cryptography.Pkcs'

[jacodv]

Describe the bug
Existing tests fail after upgrade.

To Reproduce
Upgrade Test Project from Dotnet 5 to Dotnet 6:

Expected behavior
The template should transform

Information (please complete the following information):

• OS: Windows 11
• Dotnet6
• RazorLight version:
  -- https://www.nuget.org/packages/RazorLight/2.0.0-rc.3
  -- https://www.nuget.org/packages/RazorLight.NetCore3/
• Are you using the OFFICIAL RazorLight package? https://www.nuget.org/packages/razorlight
• Visual Studio version : Visual Studio Community 2022 Professional Released

Additional context
TEST

    public void Convert_GivenValidInput_ShouldConvert()
    {
      // arrange
      Setup();
      var data = new { Name = "TheName" };
      var template = "Name is @Model.Name";

      // action
      var result = _engine.Convert(data, template, true);

      // assert
      result .Should().Be("Name is TheName");
  }

IMPLEMETATION:

        var result = engine.CompileRenderStringAsync(GetTemplateCachedId(templateData), templateData, data,  (ExpandoObject)null).Result;

ERROR:

IIAB.Core.Common.Exceptions.RazorParsingException : One or more errors occurred. (Cannot find compilation library location for package 'System.Security.Cryptography.Pkcs')
   at IIAB.Razor.RazorTemplateEngine.Convert(Object data, String templateData, Boolean ifErrorTrySerializeAndDeserialize) in C:\Git\IIAB-netcore\src\IIAB.Razor\RazorTemplateEngine.cs:line 102
   at IIAB.Razor.Tests.RazorTemplateEngineTests.Convert_GivenValidInput_ShouldConvert() in C:\Git\IIAB-netcore\src\IIAB.Razor.Tests\RazorTemplateEngineTests.cs:line 32

[jzabroski]

@jacodv I don't think RazorLight.Tests has any test with Convert_GivenValidInput_ShouldConvert. Can you reproduce this in the current repositories tests?

[jacodv]

I have cloned the repo, but Visual Studio 2022 keep on hanging trying to load the projects. I will create a clean solution and try load them again. If I succeed then I will push to GitHub and revert ASAP.

[jacodv]

@jzabroski I have created a repo (https://github.com/jacodv/RazorLightDotNet6)

I get different errors, but they can be fixed by updating the RazorLight.csproj. Here are my tests in order (branches):

• branch_jdevil-Dotnet5-Success (Started with a .Net5 Test Project)
• branch_jdevil-Dotnet6-UpdateProjectOnly (Only change the test project to .Net6) - See README in root for error
• branch_jdevil-Dotnet6-ChangeLanguageVersion-To-9-Sucess (Leave Test Project on .Net6, Change LanguageVersion to 9)
• branch_jdevil-Donet6-Add-6-To-RazorLight-Project-success (Update RazorLight project with .Net 6 conditions)

[jacodv]

@jzabroski : My Error has todo with a dependency (System.Security.Cryptography.Pkcs) of referenced Nuget packages. It would seem that different Nuget packages depend of different versions of this dependency. I realized it by looking at the project.assets.json file in the obj folder.

I still get the error after making the above changes and referencing the new RazorLight project. If I remove the project that has all the nuget packages it works.

Three questions:

• Is there a way to for the load of a specific version when the RazorEngine compiles?
• Why does this only occur when the test project (Entry Assembly) is .Net6?
• Is there a way to debug and determine which Nuget package causes the error? Bear in mind that the razor template and data does not reference any of the nuget packages, it must happen in the load of the reference assembly.

[adimoldovan92]

I am having the same problem after upgrading from .NET Core 3.1 to .NET 6. I haven't managed yet to find a fix for this,

[jacodv]

@jzabroski I managed to replicate the problem. All I had todo was to add a package reference to System.Security.Cryptography.Pkcs in the test project.

See the README in the root

https://github.com/jacodv/RazorLightDotNet6/tree/branch_jdevil-Add-IIAB-To-See-Why-Error-Occurs

Thank you in advance

[jzabroski]

@jacodv ...Why are you adding a reference to that project?

That said:

It would seem that different Nuget packages depend of different versions of this dependency. I realized it by looking at the project.assets.json file in the obj folder.

The only solution to fix this conflict is to write an assembly resolve helper. This isn't really a RazorLight problem, this is a your-dependencies-are-in-hell-you-need-to-sort-it-out problem.

[jzabroski]

I get different errors, but they can be fixed by updating the RazorLight.csproj. Here are my tests in order (branches):

• branch_jdevil-Dotnet5-Success (Started with a .Net5 Test Project)
• branch_jdevil-Dotnet6-UpdateProjectOnly (Only change the test project to .Net6) - See README in root for error
• branch_jdevil-Dotnet6-ChangeLanguageVersion-To-9-Sucess (Leave Test Project on .Net6, Change LanguageVersion to 9)
• branch_jdevil-Donet6-Add-6-To-RazorLight-Project-success (Update RazorLight project with .Net 6 conditions)

Thanks, I'll try to take a look at this soon to understand the problem.

[jacodv]

@jacodv ...Why are you adding a reference to that project?

@jzabroski I added the reference to show that it is not DLL hell as suggested. If I only add that project and add RazorLight then I get the error. Let us assume I had this code in my project

Commit to: https://github.com/jacodv/RazorLightDotNet6/tree/branch_jdevil-Add-IIAB-To-See-Why-Error-Occurs

[Test]
		public void Convert_GivenValidInput_ShouldConvert()
		{
			// arrange
			Setup();
			var data = new { Name = "TheName" };
			var template = "Name is @Model.Name";

			// action
			var result = _engine.Convert(data, template, true);

			var signedResult = _sign(Encoding.UTF8.GetBytes(result), X509Certificate2.CreateFromPemFile("personal.pem"));

			// assert
			result.Should().Be("Name is TheName");
		}
		
private static byte[] _sign(byte[] message, X509Certificate2 cert)
		{
			var contentInfo = new ContentInfo(message);
			var signedCms = new SignedCms(contentInfo);
			var cmsSigner = new CmsSigner(cert)
			{
				IncludeOption = X509IncludeOption.EndCertOnly
			};

			signedCms.ComputeSignature(cmsSigner);

			var signed = signedCms.Encode();
			return signed;
		}

[jacodv]

@jzabroski / @toddams, did you manage to see what might cause this issue? On my last commit I showed that my initial guess that a 3rd party is causing the problem was incorrect.

[jzabroski]

Sorry man. I have not given this repo a lot of love the last ~2 years (basically, since covid hit). I acknowledge your repro and think it is great you went that far. I'm hesitant to sink a lot of time into issues related to loading third party DLLs, since ultimately RazorLight is doing very simple things.

I would guess there is an issue with the Metadata Resolver, for which there is already an FAQ entry.

Typically when I debug these problems I try to see if:

1. There is a conflict across versions due to "diamong dependencies" across nuget packages, and there is no way to "roll forward".
2. The problem is due to third party packaging issues. Sometimes, OOB (Microsoft term for packages that ship on nuget.org instead of with a target framework SDK that sits on disk) packages don't have a clear package under certain conditions, like netstandard packages vs a specific, concrete target framework (e.g., net5.0).
3. I check to see how things are being packaged on our side. As I've explained to people before, if you want to use this project on newer frameworks, self-contained deployment is the way to go, but you do open yourself up to security risks due to the underlying dependencies being unpatched nuget.org patches (which is likely part of the reason why Microsoft moved to making the framework something that sits on disk vs. can be included off nuget.org).

The third reason is rather subtle, and something people criticize me for how I chose to package the project. They would rather I not do it the way I chose to do it, so that things "just work". I think that's the incorrect perspective as you should know/understand your dependencies.

[jzabroski]

I think, the fix might be to change the way we packaged netstandard2.0, as it is probably ambiguous which version of Microsoft.AspNetCore.* assemblies we should use when we request a frameworkreference for net6.0 in a context where the interstitial project between the entrypoint assembly and the RazorLight assembly is a netstandard2.0 assembly/csproj.

e.g.

Program.csproj [net6.0]
 \
  References EmailRenderer.csproj
|
EmailRenderer.csproj [netstandard2.0]
 \
  Package Reference RazorLight
  \
   FrameworkReference 6.0
 \
  Microsoft.AspNetCore.* references 2.1 version

In this case, MSBuild will resolve half of the dependencies to netstandard2.0 direct depenencies,& will resolve framework references to net6.0 dependencies provided by Microsoft on Disk for whichever version of the 6.0 SDK you have.

THIS IS JUST A WORKING THEORY I HAVE NOT FULLY TESTED. Just sharing on my lunch break to try to help unblock you.

[jzabroski]

https://github.com/jacodv/RazorLightDotNet6/blob/branch_jdevil-Add-IIAB-To-See-Why-Error-Occurs/RazorLight.Jdv/Jdv.Razor/Jdv.Razor.csproj you can see here you are using netstandard2.1

I am honestly not 100% sure what the behavior is, but I think my characterization of the problem is on the right track.

[jacodv]

@jzabroski , Firstly I appreciate you and the rest of the team's efforts to maintain a crucial function for us. If I can help, I will do so greatly.

Your assessment seems on track, It has todo with conflicts between 2.0 and 2.1. We need 2.1 for some of the collectable assembly functionality and there lie the issue I believe. Because .Net 5 works without any issues.

I will also play with your suggestions later today when I have a gap in my day

[jzabroski]

The primary reason we support netstandard2.0 TFM is really for .NET Framework 4.8 projects. The Microsoft.AspNetCore.* assemblies do not target net4.8 TFM, so that is why we targeted netstandard2.0.

One possible solution is to create a RazorLight.Net48 project and move the netstandard2.0 dependency there. It would share the same code as RazorLight.csproj through auto-globbing rules, but have a different assembly title and package name.

Another solution is to delete the FrameworkReference entirely and see what breaks and what needs to be fixed.

However, the hidden problem lies when an assembly takes advantage of a newer TFM's Runtime IL instruction or attribute that is not present on a older TFM's underlying runtime. For example, support for Span is a classic example. I think that is a lot harder to keep track of and know in advance to plan for, as nuget.org API does not expose any knowledge on binary breaking changes across runtimes. In this sense, the whole netstandard2.0 thing has always been a lie, and is part of why FrameworkReference needs to exist - to make netstandard2.0 a shiftable set of packages based on which runtime framework you actually want to target in your entrypoint assembly.