toddams / RazorLight

Template engine based on Microsoft's Razor parsing engine for .NET Core
Apache License 2.0
1.52k stars 259 forks source link

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

Closed jacodv closed 2 years ago

jacodv commented 2 years ago

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):

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 commented 2 years ago

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

jacodv commented 2 years ago

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 commented 2 years ago

@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):

jacodv commented 2 years ago

@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:

adimoldovan92 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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.

jzabroski commented 2 years ago

Here are the packages we use and a quick review of which ones keep up to date on versions:

.NETCoreApp 3.1

Package RazorLight Version Status Available OOB? Notes
Microsoft.AspNetCore.Mvc.Razor.Extensions (>= 3.1.5) 6.0.0 ✔️ -
Microsoft.CodeAnalysis.Razor (>= 3.1.5) 6.0.0 ✔️ -
Microsoft.Extensions.Caching.Abstractions (>= 3.1.5) 6.0.0 ✔️ -
Microsoft.Extensions.Caching.Memory (>= 3.1.5) 6.0.0 ✔️ -
Microsoft.Extensions.DependencyInjection (>= 3.1.5) 6.0.0 ✔️ -
Microsoft.Extensions.DependencyModel (>= 3.1.5) 6.0.0 ✔️ -
Microsoft.Extensions.FileProviders.Physical (>= 3.1.5) 6.0.0 ✔️ -
Microsoft.Extensions.Primitives (>= 3.1.5) 6.0.0 ✔️ -
System.Buffers (>= 4.5.0) 4.5.1 ✔️ ❓ Both System.Buffers and System.Memory have been in-box with the .NET SDK since .NET Core 2.1.

I didn't do the other TFMs, but you get the idea of my approach. I am not sure if System.Buffers 4.5.1 is the right version for .NET 6.0. Can you please research that?

jzabroski commented 2 years ago

There's also this advisory in the .NET 6 Breaking Changes guide: https://docs.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/6.0/older-framework-versions-dropped

Starting with .NET 6 Preview 5, the core libraries packages can no longer be installed into projects whose target framework is older than:

  • .NET Framework 4.6.1
  • .NET Core 3.1
  • .NET Standard 2.0
jzabroski commented 2 years ago

In particular, see this:

https://docs.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/6.0/older-framework-versions-dropped#affected-apis

Affected APIs

The following packages no longer ship old frameworks:

  • Microsoft.Extensions.DependencyModel
  • Microsoft.Win32.Registry.AccessControl
  • Microsoft.Win32.SystemEvents
  • System.ComponentModel.Annotations
  • System.ComponentModel.Composition
  • System.ComponentModel.Composition.Registration
  • System.Composition.AttributedModel
  • System.Composition.Convention
  • System.Composition.Hosting
  • System.Composition.Runtime
  • System.Composition.TypedParts
  • System.Data.Odbc
  • System.Diagnostics.DiagnosticSource
  • System.Diagnostics.EventLog
  • System.Diagnostics.PerformanceCounter
  • System.DirectoryServices
  • System.DirectoryServices.AccountManagement
  • System.DirectoryServices.Protocols
  • System.Drawing.Common
  • System.IO.Packaging
  • System.IO.Pipelines
  • System.Management
  • System.Net.Http.WinHttpHandler
  • System.Reflection.Context
  • System.Runtime.Caching
  • System.Runtime.CompilerServices.Unsafe
  • System.Security.Cryptography.Cng
  • System.Security.Cryptography.OpenSsl
  • System.Security.Cryptography.Pkcs
  • System.Security.Cryptography.ProtectedData
  • System.ServiceProcess.ServiceController
  • System.Speech
  • System.Text.Encoding.CodePages
  • System.Text.Encodings.Web
  • System.Threading.AccessControl
  • System.Threading.Channels

The following packages will no longer be updated because their implementation is now part of the .NET 6 platform:

  • Microsoft.Win32.Registry
  • System.ComponentModel.Annotations
  • System.IO.FileSystem.AccessControl
  • System.IO.Pipes.AccessControl
  • System.Security.AccessControl
  • System.Security.Cryptography.Cng
  • System.Security.Cryptography.OpenSsl
  • System.Security.Principal.Windows

I bolded three packages that I think are interesting. One we have a direct dependency on. The other we might have indirect (transitive) dependencies on, but dont seem to.

It also looks like System.Memory and System.Buffers got folded into .NET 6 but I dont see that listed in any breaking changes.

jzabroski commented 2 years ago

It also looks like System.Memory and System.Buffers got folded into .NET 6 but I dont see that listed in any breaking changes.

Correction (in post above): System.Memory and System.Buffers have been in-box since .NET Core 2.1 as part of Span being introduced.

jacodv commented 2 years ago

Good morning, South Africa (GMT+2) , I think we are worlds apart. I have a couple of admin tasks for the morning, then I am on this.

Thanks for the details so far

jacodv commented 2 years ago

@jzabroski this branch compiles and my simple test passes with most of RazorLight.Tests. This is not the solution, I wanted to get a better understanding of the problem, and thus made everything DotNet 6.

https://github.com/jacodv/RazorLightDotNet6/tree/branch_jdevil-Get-Dotnet6-Working

It does show that there are major compatibility issues going to DotNet 6, especially around ASP.Net Core and hosting.

I need to get back to my own work. But will take it up again tomorrow.

jacodv commented 2 years ago

@jzabroski , I can confirm that if I start using the converted engine in our code I get "locking" issues. I think it is in the _cache.Set extension. I get the same in the RazorLight.Tests project when run on the branch: https://github.com/jacodv/RazorLightDotNet6/tree/branch_jdevil-Get-Dotnet6-Working

This is going to be a tough one

jzabroski commented 2 years ago

OK, but do you see my point that I suspect major problems may be coming from any of these dependencies:

The first two are the likely culprits. See: https://github.com/dotnet/runtime/pull/35606 where they refactored how dependencies are tracked from "depproj" projects To be honest, I dont know what a depproj is, but I think its removal is likely related to the above notes about .NET 6 not supporting older libraries and that "harvesting" is no longer due in .NET 6. See for example https://github.com/dotnet/runtime/issues/29155 where they noted that they should automate harvesting for .NET 5 , then for .NET 6 they decided to remove it altogether because they realized it was a bad idea. But in 35606 they messed up part of the "fix" for removing harvesting.

jacodv commented 2 years ago

Possible yes, If you try and support all the frameworks.

But even before we get to the dependencies, just converting to .Net 6 is an issue. I tried to eliminate all the noise by just focussing on .Net 6 and even that seems to be a challenge.

await _cache.Set(item.NormalizedKey, taskSource.Task, cacheEntryOptions); Is one of the culprits

jzabroski commented 2 years ago

I'm a little surprised the built-in MemoryCache is causing locking problems. Can you be more specific?

jacodv commented 2 years ago

@jzabroski, I have two relatively full days today and tomorrow but will try and get more detail. I will focus on this test, it shows the lock. I am 99% sure it has todo with an async/await that included a .Wait() or similar. My branch: https://github.com/jacodv/RazorLightDotNet6/tree/branch_jdevil-Get-Dotnet6-Working shows the behaviour.

[Fact]
public async Task Ensure_Option_Disable_Encoding_Renders_Models_Raw() 

Also, further to your point above, you are correct atleast w.r.t System.Security.Cryptography.Pkcs. If I comment await _cache.Set(item.NormalizedKey, taskSource.Task, cacheEntryOptions); to allow the code to continue and not lock-up, I am back to this error: "Cannot find compilation library location for package 'System.Security.Cryptography.Pkcs'".

This is very frustrating, we have functionality that we want to use in .Net 6 and cannot upgrade until we have a working RAZOR component.

The irony is that all we use in our system is await engine.CompileRenderStringAsync(...). We do no have any cshtml files, we only store small strings in a database that require on-demand rendering.

jzabroski commented 2 years ago

I would recommend the following approach to debugging.

  1. See the FAQ where it covers this topic: https://github.com/toddams/RazorLight#im-getting-cannot-find-compilation-library-when-i-deploy-this-library-on-another-server
  2. If the error works fine on .NET Core App 3.1 but doesn't work on .NET 6, and the only material difference is the SDK, then I would take a BinLog of both builds and view them line by line in MSBuildStructuredLogViewer utility until you see something that pops out at you.

One thing that pops out at me is this footnote: https://docs.microsoft.com/en-us/aspnet/core/razor-pages/sdk?view=aspnetcore-6.0#runtime-compilation-of-razor-views

Runtime compilation of Razor views

  • By default, the Razor SDK doesn't publish reference assemblies that are required to perform runtime compilation. This results in compilation failures when the application model relies on runtime compilation—for example, the app uses embedded views or changes views after the app is published. Set CopyRefAssembliesToPublishDirectory to true to continue publishing reference assemblies. Both code generation and compilation are supported by a single call to the compiler. A single assembly is produced that contains the app types and the generated views.

  • For a web app, ensure your app is targeting the Microsoft.NET.Sdk.Web SDK.

I'm not sure why the RazorLight FAQ recommends setting a different setting to false:

<MvcRazorExcludeRefAssembliesFromPublish>false</MvcRazorExcludeRefAssembliesFromPublish>

These two settings do seem related, and I don't know if one was deprecated, or if we've been relying on MSBuild flags Microsoft would consider "private" to the implementation of the SDK.

One thing to test would be to see if you could try the runtime compilation advice from Microsoft that is publicly available, and see if the error changes or if its the same error. (I have not tried this).

I can see from 2019 there was some advice in this regard, here: https://github.com/dotnet/core/issues/1725#issuecomment-538100548

jacodv commented 2 years ago

Thanks @jzabroski, I will try and make time this week to start with the deeper investigation. I also want to see if I cannot make another project that is even lighter with less moving parts for our needs.

jacodv commented 2 years ago

@jzabroski - I think I have the problem. And it might be on my side. I use Resharper. I accidently ran my tests in VS test runner and now I don't see the ERROR. I have some other issues, but not missing System.Security.Cryptography.Pkcs related.

I am not sure if I want it to be Resharper or NOT.

ReSharper image

VS Tests image

jzabroski commented 2 years ago

I hate to be negative, but ReSharper is miles,better than VS Test Runner. It's funny/ironic how bad Microsoft testing is.

Since we have covered so much ground, can you summarize which problems are resolved and which are not?

jacodv commented 2 years ago

I agree, and have logged a bug with Jetbrains team. Not sure if that is a blackhole or not...

With regards to status. I will start from scratch. I have basically determined the required / maybe some not new .Net 6 references and versions. But I think starting over is going to be best and then see what exactly is required to make a .Net 6 project to work.

jacodv commented 2 years ago

@jzabroski

Short Answer: I have successfully upgraded to .Net 6 including the latest language version

https://github.com/jacodv/RazorLightDotNet6/tree/branch_jdevil-Dotnet6-Upgrade-RazorLight-Tests Show the code and tests

Running commentary

Please have a look at this readme

https://github.com/jacodv/RazorLightDotNet6/blob/branch_jdevil-Dotnet6-Upgrade-RazorLight-Tests/DotNet6Status/README.md

I have detailed every step to reproduce as well as what must be changed to enable .Net 6

jacodv commented 2 years ago

@jzabroski : This is a roller coaster ride!!! Next hurdle and this is not ReSharper related. I think I might need to help to understand what is required. I made sure that ALL the necessary projects have the PreserveCompilationContext set to true. The method internal IReadOnlyList<MetadataReference> Resolve(Assembly assembly, DependencyContext dependencyContext) receives the test hosts (VSTests or ReSharper) as the assembly and a populated dependency context. But no paths are resolved.

Jdv.Razor.RazorParsingException : One or more errors occurred. (Can't load metadata reference from the entry assembly. Make sure PreserveCompilationContext is set to true in *.csproj file)

I have updated the branch with the new Web Test Project as well as the README with the detail:

README:

https://github.com/jacodv/RazorLightDotNet6/blob/branch_jdevil-Dotnet6-Upgrade-RazorLight-Tests/DotNet6Status/README.md

Branch:

https://github.com/jacodv/RazorLightDotNet6/tree/branch_jdevil-Dotnet6-Upgrade-RazorLight-Tests

jzabroski commented 2 years ago

Hey man.

The method internal IReadOnlyList<MetadataReference> Resolve(Assembly assembly, DependencyContext dependencyContext) receives the test hosts (VSTests or ReSharper) as the assembly and a populated dependency context. But no paths are resolved.

Can you explain what you mean here? Maybe just a screenshot of your watch window with those two variables pinned and expanded?

jacodv commented 2 years ago

@jzabroski Sure, see below:

image

image

image

jzabroski commented 2 years ago

I have a very full day today, but I am going to try hard to get to this tomorrow (weekend time). Thanks for so much progress.

jzabroski commented 2 years ago

@jacodv What version of Resharper are you on so I can ensure we're matching? I dont think there are any hotfixes to VS2022 yet.

jacodv commented 2 years ago

@jzabroski I am on the latest EAP. Also, this is not ReSharper related. I get the same on VS Tests. I will create a new dotnet 6 API this morning

Code: https://github.com/jacodv/RazorLightDotNet6/tree/branch_jdevil-Dotnet6-WebApi6

Out of the box API with one reference and a test controller. Same error, see below:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <PreserveCompilationReferences>true</PreserveCompilationReferences>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\Jdv.Razor\Jdv.Razor.csproj" />
  </ItemGroup>

</Project>
[ApiController]
  [Route("/api/razor")]
  public class RazorController : ControllerBase
  {
      private readonly ILogger<RazorController> _logger;
      private readonly RazorTemplateEngine _templateEngine;

      public RazorController(ILogger<RazorController> logger)
      {
          _logger = logger;
          _templateEngine = new RazorTemplateEngine();
      }

      [HttpGet(Name = "GetRazor")]
      public string Get()
      {
          var expected = "ThePropValue";
          var template = "@Model.SomeClass.SomeProp";
          var data = new { SomeClass = new { SomeProp = expected } };

          return _templateEngine.Convert(data, template);

      }
  }

image

jacodv commented 2 years ago

@jzabroski did you manage to have a look over the weekend?

jzabroski commented 2 years ago

I did not. My wife had a long TODO list for me :(

jzabroski commented 2 years ago

@jacodv I noticed the error message is different than the csproj value. It says PreserveCompilationContext, whereas your config is PreserveCompilationReferences

jzabroski commented 2 years ago

Sorry - I re-read the whole thread and saw your comment from 3 days ago where you set all projects to PreserveCompilationContext. That sucks.

jacodv commented 2 years ago

@jzabroski , Your observation was spot on. We have a .Net ready version. I am not sure where I got PreserveCompilationReferences from, but as soon as I changed it to the correct PreserveCompilationContext it worked. Meaning this branch has a working .Net6 Upgrade (excluding full framework support :-(.

Would you be able to create new Nuget package for us please?

Lastly, We are back to the ReSharper issue though, however I believe this is not RazorLight specific. I have a ticket open with JetBrains https://resharper-support.jetbrains.com/hc/en-us/requests/3663073.

VS Test Results: image

ReSharper Test Results: image

jzabroski commented 2 years ago

That's great. Can I use https://github.com/jacodv/RazorLightDotNet6/tree/branch_jdevil-Dotnet6-WebApi6 as instructions for how to update and re-package RazorLight? Would you like to submit a PR?

I want to set-up a build matrix on GitHub for RazorLight as well. I hate the fact I've been packaging this on my machine since taking it over from Ivan.

jzabroski commented 2 years ago

It looks like since the last time I looked at GitHub Actions, someone has created a GitHub Action for publishing safely to nuget.org - and Luke Lowrey has created a tutorial to set it up. Should be straight forward to update .github/workflows/dotnet.yml using this tutorial: https://lukelowrey.com/use-github-actions-to-publish-nuget-packages/

jzabroski commented 2 years ago

@jacodv I'm getting close to automating RazorLight deploys to Nuget. I was stumped for a bit, but I think the problem was that the root directory is different when you use a build matrix. Build matrix doesn't even really make sense for pushing a nuget package, so I split the workflows into two separate workflows: .github/workflows/dotnet-pack-and-push.yml

jacodv commented 2 years ago

@jzabroski Great news.

Yes, https://github.com/jacodv/RazorLightDotNet6/tree/branch_jdevil-Dotnet6-WebApi6, has all the latest code and successful VS Tests.

Let me know if I can help with anything. Also, do you think it possible to create an even lighter package if we only use CompileRenderStringAsync in our projects?

jzabroski commented 2 years ago

I have wanted a lighter package for awhile. I think the .NET 4.8 support should go in its own csproj as a netstandard2.0 package called RazorLight.Net48. That should help avoid one of the problems we discussed above, which is when people transitively reference RazorLight from a library that itself targets netstandard2.0 but is meant to target .NET 6 framework.

Can you come up with a general proposal of how you think it should look? I am not clear on what it would look like with just CompileRenderStringAsync. In 2020 I did some hotfixes around NullRazorProjectItem to handle some code that was copy-pasted across the Internet, which was the root cause of a LOT of bug reports... so I am a little leery of encouraging people to only use that piece. I can't remember if the NullRazorProjectItem fix and other fixes were intended to allow for it to work as a stand-alone function. I had pretty severe COVID in March 2021 and some of my memory isn't quite there, but it's coming back.

jzabroski commented 2 years ago

The deploy of rc.4 succeeded but I think the snupkg files may not have made it up. See: https://github.com/toddams/RazorLight/runs/4452017565?check_suite_focus=true

The diagnostics nuget provides suck. They started improving them in .NET 5 with better error messages and a troubleshooting page, but they are still not great in the Ci/CD scenario where you can't use Fiddler to spy on http packets.

jzabroski commented 2 years ago

Hmm... I am honestly not sure why the GitHub action failed. It looks like everything succeeded on nuget.org. I was able to download the package and the symbols.