Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IbcMerge failing because MS.CA.dll is used by another process #77941

Open
jjonescz opened this issue Apr 1, 2025 · 2 comments
Open

IbcMerge failing because MS.CA.dll is used by another process #77941

jjonescz opened this issue Apr 1, 2025 · 2 comments
Labels
Area-Infrastructure untriaged Issues and PRs which have not yet been triaged by a lead

Comments

@jjonescz
Copy link
Member

jjonescz commented Apr 1, 2025

Before closing this issue, please remove the workaround from code where this issue is linked.

@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged Issues and PRs which have not yet been triaged by a lead label Apr 1, 2025
@RikkiGibson
Copy link
Contributor

It feels like is a correctness issue in the build, which is causing IbcMerge to run multiple times concurrently on the same dll. Once we determine the root cause, it would be good to add some kind of speedbump to prevent such breaks from making it in in the future.

For example, maybe there is a change to our correctness checks we could make to detect the bad condition. Alternatively, maybe we could gate certain categories of changes on someone manually running the official build first. For example, there's a bot which complains when you modify public API--a bot might also complain when the structure of the build is modified in certain ways and ask an MSFT contributor to run an official build prior to merging.

This is all assuming it was a change on our side that broke things, which I don't think we are fully certain of yet.

@jjonescz
Copy link
Member Author

jjonescz commented Apr 2, 2025

Actually it might be good to fix this in arcade - currently the ApplyOptimizations target runs after CoreCompile even when the CoreCompile target itself is skipped (because outputs are up to date wrt inputs). That seems unnecessary and leads to these errors. The fact that we CoreCompile MS.CA.dll in our builds multiple times might be expected - the second time happens inside ResolveProjectReferences and is skipped which seems fine.

In fact, some arcade targets related to ApplyOptimizations have Inputs/Outputs that cause them to be skipped if they were already performed:

https://github.com/dotnet/arcade/blob/c614b14e5dfd8953450c293472d50078f0497adb/src/Microsoft.DotNet.Arcade.Sdk/tools/OptimizationData.targets#L37-L38

<Target Name="PostCompileBinaryModification"
          AfterTargets="CoreCompile"
          DependsOnTargets="_InitializeAssemblyOptimizationWithTargetAssembly;ApplyOptimizations"
          Condition="'$(IsWpfTempProject)' != 'true' and '$(EnableNgenOptimization)' == 'true' and '$(ApplyNgenOptimization)' != ''"
          Inputs="$(MSBuildAllProjects);@(IntermediateAssembly)"
          Outputs="@(IntermediateAssembly);$(PostCompileBinaryModificationSentinelFile)">

I think those same Inputs/Outputs should be added to the ApplyOptimizations target as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Infrastructure untriaged Issues and PRs which have not yet been triaged by a lead
Projects
None yet
Development

No branches or pull requests

2 participants