[fleet installer] Try to fix Gac Installer issue when older versions are already installed #6715
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Datadog ReportBranch report: ✅ 0 Failed, 250150 Passed, 2408 Skipped, 19h 43m 7.92s Total Time |
Execution-Time Benchmarks Report ⏱️Execution-time results for samples comparing the following branches/commits: Execution-time benchmarks measure the whole time it takes to execute a program. And are intended to measure the one-off costs. Cases where the execution time results for the PR are worse than latest master results are shown in red. The following thresholds were used for comparing the execution times:
Note that these results are based on a single point-in-time result for each branch. For full results, see the dashboard. Graphs show the p99 interval based on the mean and StdDev of the test run, as well as the mean value of the run (shown as a diamond below the graph). gantt
title Execution time (ms) FakeDbCommand (.NET Framework 4.6.2)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6715) - mean (69ms) : 66, 72
. : milestone, 69,
master - mean (68ms) : 66, 71
. : milestone, 68,
section CallTarget+Inlining+NGEN
This PR (6715) - mean (1,006ms) : 981, 1031
. : milestone, 1006,
master - mean (1,003ms) : 982, 1024
. : milestone, 1003,
gantt
title Execution time (ms) FakeDbCommand (.NET Core 3.1)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6715) - mean (102ms) : 100, 104
. : milestone, 102,
master - mean (102ms) : 99, 104
. : milestone, 102,
section CallTarget+Inlining+NGEN
This PR (6715) - mean (689ms) : 670, 708
. : milestone, 689,
master - mean (685ms) : 666, 703
. : milestone, 685,
gantt
title Execution time (ms) FakeDbCommand (.NET 6)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6715) - mean (89ms) : 87, 92
. : milestone, 89,
master - mean (89ms) : 87, 90
. : milestone, 89,
section CallTarget+Inlining+NGEN
This PR (6715) - mean (639ms) : 625, 653
. : milestone, 639,
master - mean (639ms) : 625, 654
. : milestone, 639,
gantt
title Execution time (ms) HttpMessageHandler (.NET Framework 4.6.2)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6715) - mean (190ms) : 185, 195
. : milestone, 190,
master - mean (189ms) : 185, 192
. : milestone, 189,
section CallTarget+Inlining+NGEN
This PR (6715) - mean (1,104ms) : 1080, 1128
. : milestone, 1104,
master - mean (1,104ms) : 1080, 1128
. : milestone, 1104,
gantt
title Execution time (ms) HttpMessageHandler (.NET Core 3.1)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6715) - mean (269ms) : 265, 273
. : milestone, 269,
master - mean (268ms) : 264, 271
. : milestone, 268,
section CallTarget+Inlining+NGEN
This PR (6715) - mean (872ms) : 834, 909
. : milestone, 872,
master - mean (870ms) : 834, 907
. : milestone, 870,
gantt
title Execution time (ms) HttpMessageHandler (.NET 6)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6715) - mean (261ms) : 257, 266
. : milestone, 261,
master - mean (261ms) : 257, 264
. : milestone, 261,
section CallTarget+Inlining+NGEN
This PR (6715) - mean (856ms) : 822, 890
. : milestone, 856,
master - mean (857ms) : 825, 889
. : milestone, 857,
|
Benchmarks Report for tracer 🐌Benchmarks for #6715 compared to master:
The following thresholds were used for comparing the benchmark speeds:
Allocation changes below 0.5% are ignored. Benchmark detailsBenchmarks.Trace.ActivityBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.AgentWriterBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.AspNetCoreBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.DbCommandBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.ElasticsearchBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.GraphQLBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.HttpClientBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.ILoggerBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.Log4netBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.NLogBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.RedisBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.SerilogBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.SpanBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.TraceAnnotationsBenchmark - Same speed ✔️ Same allocations ✔️Raw results
|
kevingosse
reviewed
Mar 6, 2025
tracer/src/Datadog.FleetInstaller/FusionApi/Fusion+CreateAssemblyEnum.cs
Outdated
Show resolved
Hide resolved
kevingosse
approved these changes
Mar 11, 2025
andrewlock
force-pushed
the
andrew/win-ssi/update-gac-uninstaller
branch
from
4690b10 to
4d48037
Compare
ddyurchenko
pushed a commit
that referenced
this pull request
Mar 31, 2025
…are already installed (#6715) ## Summary of changes Fixes the issue of removing old GAC entries when there are multiple assemblies in the GAC with the same name. ## Reason for change #6714 highlighted an issue with the GAC uninstall where we were _not_ removing the previous `Datadog.Trace` entries during uninstall. This attempts to work around that. ## Implementation details Use another `Fusion` API to enumerate all the "Datadog.Trace" assemblies, to get their fullnames (e.g. `Datadog.Trace, Version=3.12.0.0, Culture=neutral, PublicKeyToken=def86d061d0d2eeb, processorArchitecture=MSIL`). We then run the uninstall for _all_ of the GAC assemblies we find. As long as each assembly has been registered with a _different_ associated filepath (i.e. the associated native loader for the gac'd file), then we _should_ only ever remove a single file at most. The integration tests demonstrate this works, even if it's a bit messy. ## Test coverage Unskipped the previously skipped GAC tests, and they pass so 🤞 ## Other details Initially I wanted to use `CreateInstallReferenceEnum()` to enumerate the _actual_ references so that we could be sure we _only_ try to remove the correct reference, but I couldn't get that to work (Getting an HResult error 🤷♂️). The current approach appears to work though, so maybe we should just consider that an optimisation for later? 🤷♂️ I also haven't looked to see if we have any existing implementation of the API... Stacked on - #6714 --------- Co-authored-by: Kevin Gosse <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary of changes
Fixes the issue of removing old GAC entries when there are multiple assemblies in the GAC with the same name.
Reason for change
#6714 highlighted an issue with the GAC uninstall where we were not removing the previous
Datadog.Traceentries during uninstall. This attempts to work around that.Implementation details
Use another
FusionAPI to enumerate all the "Datadog.Trace" assemblies, to get their fullnames (e.g.Datadog.Trace, Version=3.12.0.0, Culture=neutral, PublicKeyToken=def86d061d0d2eeb, processorArchitecture=MSIL).We then run the uninstall for all of the GAC assemblies we find. As long as each assembly has been registered with a different associated filepath (i.e. the associated native loader for the gac'd file), then we should only ever remove a single file at most. The integration tests demonstrate this works, even if it's a bit messy.
Test coverage
Unskipped the previously skipped GAC tests, and they pass so 🤞
Other details
Initially I wanted to use
CreateInstallReferenceEnum()to enumerate the actual references so that we could be sure we only try to remove the correct reference, but I couldn't get that to work (Getting an HResult error 🤷♂️). The current approach appears to work though, so maybe we should just consider that an optimisation for later? 🤷♂️ I also haven't looked to see if we have any existing implementation of the API...Stacked on