Aspnetcore: When publishing a web application using AddRazorRuntimeCompilation I get old Sdk files

[vsfeedback]

_This issue has been moved from a ticket on Developer Community._

---

[regression] [worked-in:16.5.5]
I use VS 2019 with the latest update (ver 16.6.0) and publish a web application to a folder.

When I checked the "refs"-folder files they suddenly are of an older version, e.g.:

• Microsoft.AspNetCore.Antiforgery.dll
• File version 3.100.220.6801
• Product version 3.1.2

Is this how it is supposed to be?

---

Have the following runtime/sdk installed:

.NET Core SDKs installed:
3.1.201 [C:Program Filesdotnetsdk]
3.1.300 [C:Program Filesdotnetsdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.1.4 [C:Program FilesdotnetsharedMicrosoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.4 [C:Program FilesdotnetsharedMicrosoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.4 [C:Program FilesdotnetsharedMicrosoft.WindowsDesktop.App]

---

Original Comments

Per Andersson on 5/20/2020, 03:09 AM:

I actually tried it on a computer with VS 2019 v. 16.5.5, and after installing the latest SDK it now has the same issue, publishing old files to the "refs"-folder, so it wasn't an issue that came with the upgrade, I just assumed it were.

------------ edit

I also now found that the 3.1.4-files is not available in the "C:\Program Files\dotnet\packs\Microsoft.AspNetCore.App.Ref" folder, only 3.1.2 and 3.1.3.

Is it safe to use the earlier published 3.1.3 files until you fixed this issue?

Per Andersson on 5/20/2020, 03:52 AM:

I downloaded the "dotnet-sdk-3.1.300-win-x64" binaries instead of the installer, and found that the "packs/Microsoft.AspNetCore.App.Ref"-folder actually contains the older files (3.1.2), not the new ones.

Visual Studio Feedback System on 5/20/2020, 08:32 PM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Per Andersson on 5/24/2020, 01:59 AM:

And do note, the "installer" and the "binaries" packages have different "packsMicrosoft.AspNetCore.App.Ref" file versions, both tagged 3.1.2 though.

Kevin Pilch [MSFT] on 5/26/2020, 10:55 AM:

Hi - can you describe exactly how you are publishing, and what “refs” folder you mean?

It’s by design that the reference pack “Microsoft.AspNetCore.App.Ref” isn’t always updated. We normally try not to change the API surface area in servicing releases, and only ship an updated ref pack when we need to.

However, if you publish your app self-contained, you should be getting the implementation assemblies, not the reference assemblies in your publish output.

Per Andersson on 5/26/2020, 00:24 PM:

Hi,

I'm publish a "Framework-Dependent" ASP.NET Core 3.1 web application to a "Folder", and then simply copy the files to a server.

The "refs" folder contain the files needed for the app to be able to compile views at runtime, and is copied to the "publish" folder when I run "Build/Publish".

To enable it all I installed the nuget "Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation Version=3.1.4" and then added "services.AddRazorPages().AddRazorRuntimeCompilation()" to my "Startup" class.

This result in the "refs" folder being published along with the app files.

Now, when I do this using the latest VS 16.6.0 / SDK 3.1.300, the "refs" files are of an older version then when I'm using the previous VS 16.5.5 / SDK 3.1.202.

For example, the "Microsoft.AspNetCore.Antiforgery.dll" has the following properties;

With VS 16.6.0 / SDK 3.1.300

- File version 3.100.220.6801

- Product version 3.1.2

- Date 2020-01-18 17:35

With VS 16.5.5 / SDK 3.1.202

- File version 3.100.320.12812

- Product version 3.1.3

- Date 2020-02-29 04:25

So what I am asking is, how can it be that the "refs" folder files when using VS 16.6.0 / SDK 3.1.300 are older than when I use VS 16.5.5 / SDK 3.1.202?

One would expect they at least should be of the same product/file version than the previous SDK, or no, and it is okay that they suddenly are of an older version?

And even more confusing were when I found that the "refs" files in the downloadable "X64 binaries" package where newer than the one's in the "X64 installer" package.

The same sample file as above had the following properties in the SDK 3.1.300 "X64 binaries" package:

- File version 3.100.220.10506

- Product version 3.1.2

- Date 2020-02-05 23:22

Kevin Pilch [MSFT] on 5/28/2020, 03:24 PM:

Hi @Per Andersson, are you on GitHub? I'd like to migrate this to our GitHub repo so I can tag the relevant parties.

Per Andersson on 5/28/2020, 10:12 PM:

Hi @Kevin Pilch [MSFT] ... Great, and yes, I have an account with the same username/Microsoft account named "perason".

---

Original Solutions

(no solutions)

[Pilchie]

Tagging @dotnet/aspnet-build and @mmitche. This is the issue we've been discussing in email.

[Pilchie]

Also tagging @perandersson.

[perason]

Thanks ... I will follow it here

[wtgodbe]

So, what happened here was that we neglected to update the version of Microsoft.AspNetCore.App's ref-pack from 3.1.2 to 3.1.3 in the 3.1.300 SDK. This has been fixed for 3.1.301, which is shipping in June. For now, there are a couple of things you can try:

• Add direct PackageReferences in your proj file to the libraries that got downgraded
• Add the following workaround to your proj file:

<ItemGroup>
  <KnownFrameworkReference Update="Microsoft.AspNetCore.App">
    <TargetingPackVersion>3.1.3</TargetingPackVersion>
  </KnownFrameworkReference>
<ItemGroup>

The second is probably easier - it's essentially telling the 3.1.300 SDK to use the 3.1.3 AspNetCore targeting pack, rather than the one that comes bundled (which is 3.1.2)

[perason]

Thanks...that did the trick

[wtgodbe]

Closing as this has been answered