log 2019/08/25
commits
Merge branch 'master' into merge/release/3.0-to-master · aspnet/EntityFrameworkCore@0b87c81 · GitHub
EntityFrameworkCore の master を merge/release/3.0-to-master branch に merge 。
netcoreapp のバージョンは 3.0 じゃなく、5.0 が使われているのを初めて知った。
KnownAppHostPack, KnownFrameworkReference という見慣れないタグが使われているのが気になった。
以下あたりの PR で追加されている。
- Refactor targeting pack downloads, and framework version selection by dsplaisted · Pull Request #2887 · dotnet/sdk · GitHub
- Support ASP.NET Core PackageReference when targeting .NET Core 3.0 or higher by dsplaisted · Pull Request #2738 · dotnet/sdk · GitHub
Merge branch 'release/3.0' => 'master' (#17408) · aspnet/EntityFrameworkCore@c3636f2 · GitHub
EntityFrameworkCore の release/3.0 branch が master に merge。
ただ、これは頻繁に行われているので、別にこれでリリースされるとかではない。
release/3.0 branch が merge/release/3.0-preview9-to-release/3.0 branch に merge。
いくつかの依存 package は preview9 から rc1 になっている。
'release/3.0-preview9' branch が 'release/3.0' に merge。
Merge branch 'release/3.0' => 'master' (#17413) · aspnet/EntityFrameworkCore@7f30d52 · GitHub
release/3.0 が master に merge。
Merge branch 'master' into merge/release/3.0-to-master · aspnet/AspNetCore-Tooling@5d8aea3 · GitHub
AspNetCore-Tooling の master を merge/release/3.0-to-master branch に merge 。
netcoreapp のバージョンは EF Core と同じく。
テストコードを見ていると、EF Core と AspNetCore-Tooling はどちらも Xunit を使っているが assertion lib に EF Core は FluentAssertion を使っているのが見て取れた。（全体的にかどうかは分からないが）
Merge branch 'release/3.0' => 'master' (#1014) · aspnet/AspNetCore-Tooling@dd8d708 · GitHub
AspNetCore-Tooling の release/3.0 branch が master に merge。
AspNetCore-Tooling の release/3.0 branch が merge/release/3.0-preview9-to-release/3.0 branch に merge。
いくつかの依存 package は preview9 から rc1 になっている。
で、今度は release/3.0-preview9 branch が master に merge。
Drop 'en-us' loc segment from URLs + doc nits (#13410) · aspnet/AspNetCore@460f9b6 · GitHub
ドキュメントの URL に不要な en-us セグメントが入っていたのを消したのと、些細なドキュメントの修正。
nits は些細な修正みたいな意味らしい。
以下の PR に対する修正。
Statement about View compilation is not correct · Issue #13895 · aspnet/AspNetCore.Docs · GitHub
Views のコンテンツがリクエストされるまでコンパイルされないというのは、少なくとも deploy される環境では正しくなく [projectname].Views.dll が生成されるはず、という issue が発端。
3.0 preview からは、以下の記事にあるように runtime compilation は opt-in になっている。
ASP.NET Core での Razor ファイルのコンパイル | Microsoft Docs
2.2、2.1 でも微妙に挙動が異なりますが、開発環境では true になるよう。
ASP.NET Core での Razor ファイルのコンパイル | Microsoft Docs
結局、このセクションでコンパイルに関して言及する必要無いのではというので削除された模様。
以下のドキュメントの話。
Cache in-memory in ASP.NET Core | Microsoft Docs
sliding expiration と absolute expiration についての部分で、手直しが行われている。
sliding expiration は指定された interval の間に request が無ければ cache から消えるが、逆にアクセスが頻繁にありすぎると、cache のデータが stale なものになる可能性が出てくる。
よって abosolute expiration と組み合わせて、一定時間で確実に cache から消える状態に（つまり上限の時間を決める）することで、鮮度を保てる。
確かに新しい文章の方が理解しやすい。
