toddams / RazorLight

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

RazorLight 2.0.0-beta8 depends on "dateless" Nuget packages (Core 3.1) #348

Open mikoskinen opened 4 years ago

mikoskinen commented 4 years ago

Describe the bug RazorLight 2.0.0-beta8 (and some of the previous versions) has dependencies to .NET Core 3.0 packages which are broken. These packages contains DLLs which are missing modifies dates. This causes errors when trying to package a project which depends on RazorLight.

To Reproduce

  1. Create a new .NET Core 3.1 console app
  2. Add RazorLight 2..0.0-beta8
  3. Set PreserveCompilationContext to true.
  4. Publish the project

Now if you check the bin\Debug\netcoreapp3.1\refs folder, you should see the broken DLLs which are missing "Date modified":

image

Expected behavior

After following the above steps all the DLLs in refs-folder should have "Date modified" set.

Additional context

This isn't actually RazorLight's fault as there is a bug in dotnet pack which is the root issue: https://github.com/NuGet/Home/issues/7001. If any file in refs is missing the date AND your computer's time zone has positive offset, the pack command will fail.

One could maybe say that the root issue is actually the invalid Nuget packages, which are discussed here: https://github.com/dotnet/extensions/issues/2750

The problem should be fixed if the dependencies are updated to the latest ones (3.1.5).

jzabroski commented 4 years ago

@mikoskinen I will create a PR, but can you please review it. I think the correct fix is to basically split out the netcoreapp3.0 and netcoreapp3.1 nuget dependencies so that 3.0 references 3.0.x and 3.1 reference 3.1.y

jzabroski commented 4 years ago

This isn't actually RazorLight's fault

I think the mistake is RazorLight.Tests didnt target .netcoreapp3.1. I am fixing that as part of the PR. I am curious if that would have caught this problem.

jzabroski commented 4 years ago

@mikoskinen As part of the PR, I will also update the sample project from .netcoreapp2.0 (which is no longer supported by Microsoft) to .netcoreapp2.1 (Microsoft's .NET 2.1 support expires August 21, 2021).

jzabroski commented 4 years ago

@mikoskinen Please have a look at the fix I did. This is not exactly what you suggested to do, but, in my opinion, a bit safer route and better practice, as it avoids LatestMinor release RollForward behavior and instead encourages LatestFeature release RollForward behavior, while at the same time preconfiguring the project to force the latest feature dependencies.

jzabroski commented 4 years ago

Should be fixed.

image

Will push fix out in a bit.

jzabroski commented 4 years ago

Pushed to nuget.org - should be available in ~1 hour.

mikoskinen commented 4 years ago

Excellent, thank you very much for the fix!

irvinetop commented 4 years ago

I have the same problem and the last update did not fix my bug. image image

jzabroski commented 4 years ago

@irvinetop I can't see what folder you're in, and I don't know how to repro your problem since it "works on my machine". Please provide more details, such as, does "I have the same problem" refer to:

netcoreapp3.1/refs folder what version of dotnet.exe are you using what dotnet.exe --list-sdks outputs what dotnet.exe --info outputs what version of Visual Studio you're using

jzabroski commented 4 years ago

@irvinetop Would you like to submit a PR for this? See: https://github.com/natemcmaster/CommandLineUtils/issues/277#issuecomment-532532991

The version of NuGet in the 3.0 SDK intentionally removes timestamps when creating the .nupkg file as a part of a new NuGet feature called "deterministic packaging".

Nate's PR: https://github.com/natemcmaster/CommandLineUtils/pull/278

jzabroski commented 4 years ago

Just an update here. I am a little stumped as to what the problem is. We may need Microsoft help here. I also asked a former Microsoft employee who is fairly in tune with nuget and msbuild if he had any ideas.

Here is what I have done so far.

<Project>
  <!-- Workaround https://github.com/NuGet/Home/issues/7001 -->
  <Target Name="DisableNuGetDeterministicPackaging"
          BeforeTargets="GenerateNuspec"
          AfterTargets="CoreCompile" Condition="$(RazorLightNonDeterministicPackaging) == 'True'">
    <Warning Text="Disabling Deterministic Packaging" />
    <PropertyGroup>
      <Deterministic>false</Deterministic>
    </PropertyGroup>
  </Target>
  <Target Name="EnableNuGetDeterministicPackaging"
          BeforeTargets="GenerateNuspec"
          AfterTargets="CoreCompile" Condition="!($(RazorLightNonDeterministicPackaging) == 'True')">
    <Warning Text="Enabling Deterministic Packaging" />
    <PropertyGroup>
      <Deterministic>true</Deterministic>
    </PropertyGroup>
  </Target>
</Project>

Run via:

dotnet pack --configuration Release -o .\deterministicPack /p:RazorLightNonDeterministicPackaging=False
dotnet pack --configuration Release -o .\nonDeterministicPack /p:RazorLightNonDeterministicPackaging=True

You can see in the below Beyond Compare screenshots that disabling deterministic packaging doesn't seem to help.

image image

jzabroski commented 3 years ago

This might be resolved with #351