Repository navigation
Remove crossgen'ed IL assemblies and then rename NI assemblies to the same as the corresponding IL images. - #2484
Conversation
|
Hi Dongbo Wang (@daxian-dbw), I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
TTYL, MSBOT; |
|
Mike Richmond (@mirichmo) could you please review this? It's tightly related to the new dotnet.core package adoption. This alternative is also suggested by the CoreCLR team. |
There was a problem hiding this comment.
Do I understand this right? Given a.dll and a.ni.dll we are 1) deleting a.dll and then 2) renaming a.ni.dll to a.dll?
There was a problem hiding this comment.
Reading the code that's what appears to be going on, and AFAIK that's what we (unfortunately) need to do; but I'm not quite sure if the comment made sense.
We should document this (and the crossgen procedure in general) in the docs/building/internals.md documentation.
There was a problem hiding this comment.
Sure we should do that. And I will update this comment to make it easy to understand.
… same as the corresponding IL images. This is to make sure: 1. The dependency existence check by powershell.exe will pass for all TPAs. 2. CoreCLR by default will load the NI images even though it's using names of the IL images.
31eff0e to
7843281
Compare
|
The comment is updated to make it easy to understand. |
| Write-Verbose "PowerShell Ngen assemblies have been generated. Deploying ..." -Verbose | ||
| foreach ($assemblyName in $psCoreAssemblyList) { | ||
| # Remove the IL assembly and its symbols. | ||
| $assemblyPath = Join-Path $PublishPath $assemblyName |
There was a problem hiding this comment.
It is a minor naming thing, but can you rename $assemblyPath and $symbolsPath to $assemblyFile and $symbolFile? In my mind, a name that ends in "path" implies that it is a path to a directory, not a file.
There was a problem hiding this comment.
By quickly looking at build.psm1, the pattern that *Path points to a file is used in many places, such as $outputBufferFilePath, $wixHeatExePath and $wixCandleExePath, and $AssemblyPath is used in 11 places in Start-CrossGen, all indicating the path to an assembly. We also have 8 cmdlets in powershell having -FilePath parameter. So I think it's fine to use *Path points to either a file or a directory, as long as it's clear in the context.
… same as the corresponding IL images. (PowerShell#2484) * Remove crossgen'ed IL assemblies and then rename NI assemblies to the same as the corresponding IL images. This is to make sure: 1. The dependency existence check by powershell.exe will pass for all TPAs. 2. CoreCLR by default will load the NI images even though it's using names of the IL images. * Update the comment to make it easy to understand
This is to make sure:
When the legacy APIs like "GetAssemblies" are back, we probably want to retire PSALC (to what extent is still unknown) and solely depend on the CoreCLR default load context, and this is the way to make sure the CoreCLR default load context will load the NI images produced in our post-build.