The Microsoft.DotNet.Archive library used to be in the dotnet/cli repo. However, with https://github.com/dotnet/cli/pull/7645, the library was moved to a new repo https://github.com/dotnet/dotnet-cli-archiver. The library was then consumed in the dotnet/cli repo using a NuGet package.
However, this new repo was never added to source-build. Thus when we build the CLI during source-build, it means we are using the pre-built assembly from the NuGet package, and not building the assembly from source.
We should add this new repo to source-build.
/cc @livarcocc @dleeapho
The RepoToolset dotnet-cli-archiver uses is very old. I filed https://github.com/dotnet/dotnet-cli-archiver/issues/12 to track getting it up to date for source-build. @livarcocc can you find the right person to work on that?
FYI @tmat
We'll continue to use the prebuilt for 2.1.1 servicing.
Two options: add the additional archive to source-build or add conditional build to not produce lzma, since we don't use it in source-build.
What's the plan for lzma in 3.0? Is it expected to be unpacked at build-time and users will only see a pre-populated NuGetFallbackFolder? Or will it will include an lzma that will be unpacked at first-run?
What's the plan for lzma in 3.0?
I believe it will not be there for 3.0. I think it is already removed in the 3.0 branches. /cc @nguerrera @dsplaisted @livarcocc
Correct, no lzma in 3.0. 馃帀
Our prebuilt elimination push is targeting release/2.1 so this issue captures our intent to eliminate cli-archiver from the prebuilts in 2.1
(But I am still trying to determine if there will be any offline packages. There may be some, but the set would be small and it would not be handled by lzma. As of now, there are none, but plans aren't final.)
Most helpful comment
Correct, no lzma in 3.0. 馃帀