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

[mikoskinen]

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

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: NuGet/Home#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: dotnet/extensions#2750

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

[jzabroski]

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

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]

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

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

Should be fixed.

Will push fix out in a bit.

[jzabroski]

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

[mikoskinen]

Excellent, thank you very much for the fix!

[irvinetop]

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

[jzabroski]

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

@irvinetop Would you like to submit a PR for this? See: natemcmaster/CommandLineUtils#277 (comment)

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: natemcmaster/CommandLineUtils#278

[jzabroski]

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.

[jzabroski]

This might be resolved with #351