Fix duplicate stringTable elements in instrumentation manifest

[Copilot]

Update logic in GetManifestForRegisteredProvider to ensure that it does not emit XML with duplicate string ids in the string table. This is done by keeping track of the set of previously written string ids so that the code only writes each string definition once.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>instrumentation manifest - duplicate stringTable elements</issue_title>
<issue_description>The stringTable in the instrumentation manifest generated by GetManifestForRegisteredProvider() can have duplicate elements.

e.g. Microsoft-JScript provider's manifest includes -

<string id="map_MethodAddressRangeMapJITLoopBody" value="JITLoopBody" />        
<string id="map_MethodAddressRangeMapJITLoopBody" value="JITLoopBody" />        
<string id="map_MethodAddressRangeMapJITLoopBody" value="JITLoopBody" />        
<string id="map_MethodAddressRangeMapJITLoopBody" value="JITLoopBody" />        
<string id="map_MethodAddressRangeMapJITLoopBody" value="JITLoopBody" />        
<string id="map_MethodAddressRangeMapJITLoopBody" value="JITLoopBody" />        
<string id="map_MethodAddressRangeMapJITLoopBody" value="JITLoopBody" />        
<string id="map_MethodAddressRangeMapJITLoopBody" value="JITLoopBody" />
```</issue_description>

## Comments on the Issue (you are @copilot in this section)

<comments>
</comments>

• Fixes instrumentation manifest - duplicate stringTable elements #1069

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[brianrob]

@copilot, please address these comments.

Also, please add a new unit test that validates that the fix works. Use a provider that is known to exist on all machines, such as "Microsoft-Windows-DotNETRuntime". Please make sure that there are duplicates before the change and that after the change there aren't any duplicates. You don't need to keep a copy of the old code to ensure that there are duplicates each time - just do this check once so that we know we're dealing with a manifest that previously produced duplicates.

[brianrob]

Replace new string.Format calls with string interpolation.

[Copilot]

Replaced string.Format calls with string interpolation in commit a0fb478.

[Copilot]

@copilot, please address these comments.

Also, please add a new unit test that validates that the fix works. Use a provider that is known to exist on all machines, such as "Microsoft-Windows-DotNETR...

Addressed the string interpolation comment and added a new unit test GetManifestForRegisteredProvider_NoDuplicateStringTableEntries that validates no duplicate string IDs exist in the generated manifest. The test uses Microsoft-Windows-DotNETRuntime provider and is marked as Windows-only using [WindowsFact] since GetManifestForRegisteredProvider requires Windows TDH APIs. See commit a0fb478.

[marklio]

Seems reasonable. I don't know the scenario here, but it seems like something you'd want some amount of friction to prevent in the first place, but this seems like a reasonable backstop for the bad data.

[brianrob]

Seems reasonable. I don't know the scenario here, but it seems like something you'd want some amount of friction to prevent in the first place, but this seems like a reasonable backstop for the bad data.

Thanks. This actually isn't a case of bad data. It's just that the way the code was written, each time we found a usage of a particular string key, we'd also emit the value into the string table. Because we didn't keep track of if we'd written the value into the string table, we'd write it multiple times if the key was used multiple times, which is a totally valid scenario.