Introduce pre-caching into installer #10037
Conversation
|
As I mentioned to @wli3, this likely is not the best project. I'm thinking of changing it to a solution that references all the dotnet new ___ projects, builds them, and creates a set of caches—one for each—that the user can read in and combine. I could also combine them into one cache, though that can be cleaner or more efficient depending on how I do it—the easiest method would be to create a cache per project, then call RAR again, reading in all the caches and outputting them to a single cache that we actually keep. It's a little inefficient, though. Also, I expect this to fail until dotnet/msbuild#6311 has been merged. |
| <SampleProjectForResolveAssemblyReferenceCache Include="$(RepoRoot)\TestAssets\TestProjects\RARPreCacheProject\**\*.*" /> | ||
| </ItemGroup> | ||
| <Copy SourceFiles="@(SampleProjectForResolveAssemblyReferenceCache)" DestinationFiles="$(RepoRoot)\artifacts\bin\redist\$(Configuration)\RARPreCacheProject\%(RecursiveDir)%(FileName)%(Extension)" /> | ||
| <Exec Command="$(RepoRoot)\artifacts\bin\redist\$(Configuration)\dotnet\dotnet.exe msbuild $(RepoRoot)\artifacts\bin\redist\$(Configuration)\RARPreCacheProject\RARPreCacheProject.csproj /t:ResolveAssemblyReferences /p:AssemblyInformationCacheOutputPath=$(SdkInternalLayoutPath)sdk\$(Version)\SDKPrecomputedAssemblyReferences.cache" /> |
There was a problem hiding this comment.
There should be a better existing property for
And you should only run this on a windows leg
There was a problem hiding this comment.
Not you mention it, I think it's equivalent to $(SdkInternalLayoutPath)dotnet.exe. I can change it to that.
Why only on a windows leg? I think it should work for any OS.
|
Also: the change that (I think) will make this work is here. |
Other layout path was correct on debug but apparently wrong on Release.
This seems to be included as part of the sdk.
This makes it a double slash, which escapes it, causing a FileNotFound exception on linux
…e-precomputed-rar-cache
| <ItemGroup> | ||
| <AssembliesToResolve Include="$(RedistLayoutPath)\**\*.dll" Exclude="$(RedistLayoutPath)\**\native\**\*.dll" /> | ||
| </ItemGroup> | ||
| <ResolveAssemblyReference AssemblyFiles="@(AssembliesToResolve)" Silent="false" AssemblyInformationCacheOutputPath="$(RedistLayoutPath)sdk\$(Version)\SDKPrecomputedAssemblyReferences.cache" SearchPaths="{RawFileName}" /> |
There was a problem hiding this comment.
The stage 2 MSBuild engine isn't expected to work on ARM, so we can't use the full stage 2 MSBuild as I originally had it. Using the stage 2 tasks assembly (which is what matters) with the stage 0 engine could work, but it isn't great to be intentionally using different versions of the same product in a single call.
This goes a different route and just updates the stage 0 sdk to the minimum we would need to make the cache. Reading the cache is harder—I don't believe that will work with either the stage 0 or stage 2 sdk at this point. It needs dotnet/msbuild#6395 at minimum and dotnet/msbuild#6393 if you installed to Program Files or another folder that requires special write privileges. Fortunately, reading the cache should only happen with the stage 2 sdk, so we won't need a second PR to update the stage 0 sdk again afterwards.
The last viable route we could have gone is to use the stage 0 SDK to build a project that finds the stage 2 tasks assembly and uses that to call RAR. That's a viable option, but it's more complicated (read: I tried for a few hours and didn't get it to work) and slower, and all it would achieve is not needing to update the stage 0 SDK. I don't think updating the stage 0 SDK is bad, so I prefer the current PR.
Let me know if any part of that was confusing 🙂 Long answer to a short question.
|
I approve since this change looks harmless and I don't want to block you due to my OOF. But that is all? I expect a call to stage 2 at least |
Context The precomputed cache from dotnet/installer#10037 lives in Program Files after it's installed on a new computer. Program Files can only be accessed with admin privileges, which not all users have and those that have generally wouldn't expect. This permits reading the precomputed cache even without admin rights. Changes Made new FileStream(stateFile, FileMode.Open) opens the file as if you had read/write access but only actually grants you read permissions. It still requires administrator privileges, however, if a file requires administrator privileges to write to. This removes that requirement.
I can almost guarantee this doesn't work, but opening anyway so you can take a look.