Reduce VSMEF008 false positives: lower severity, soften wording, add allow-list support

[Copilot]

VSMEF008 was too aggressive for VS SDK contexts where using a type identity as a contract name (e.g. SVsFullAccessServiceBroker → IServiceBroker) is a legitimate and common pattern, causing false Error-level diagnostics.

Changes

• Severity (Error → Warning): The static analysis cannot guarantee failure; it can only flag a potential issue.
• Message wording ("will fail" → "may fail"): Matches the reduced certainty of the diagnostic.
• Allow-list via AdditionalFiles: SDKs can register known-good type-identity-as-contract-name pairs to suppress the diagnostic for specific assignments.

Allow-list format

Add a file named vs-mef.ContractNamesAssignability.txt as an AdditionalFiles entry in your project:

<ItemGroup>
  <AdditionalFiles Include="vs-mef.ContractNamesAssignability.txt" />
</ItemGroup>

Each line uses the pattern MemberType <= ContractType (fully qualified names):

# VS SDK service broker pattern
Microsoft.VisualStudio.Shell.ServiceBroker.IServiceBroker <= Microsoft.VisualStudio.Shell.SVsFullAccessServiceBroker
Microsoft.VisualStudio.Shell.Interop.IAsyncServiceProvider <= Microsoft.VisualStudio.Shell.SAsyncServiceProvider
Microsoft.VisualStudio.Shell.Interop.IAsyncServiceProvider2 <= Microsoft.VisualStudio.Shell.SAsyncServiceProvider

Blank lines and lines starting with # are ignored.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• h8evsblobprodwus2120.vsblob.vsassets.io
  • Triggering command: /opt/hostedtoolcache/dotnet/dotnet /opt/hostedtoolcache/dotnet/dotnet exec --runtimeconfig /home/REDACTED/work/vs-mef/vs-mef/bin/Tests/Microsoft.VisualStudio.Composition.Analyzers.Tests/Release/net8.0/Microsoft.VisualStudio.Composition.Analyzers.Tests.runtimeconfig.json --depsfile /home/REDACTED/work/vs-mef/vs-mef/bin/Tests/Microsoft.VisualStudio.Composition.Analyzers.Tests/Release/net8.0/Microsoft.VisualStudio.Composition.Analyzers.Tests.deps.json /home/REDACTED/work/vs-mef/vs-mef/bin/Tests/Microsoft.VisualStudio.Composition.Analyzers.Tests/Release/net8.0/testhost.dll --port 45297 --endpoint 127.0.0.1:045297 --role client --parentprocessid 5433 --telemetryoptedin false (dns block)
  • Triggering command: /opt/hostedtoolcache/dotnet/dotnet /opt/hostedtoolcache/dotnet/dotnet exec --runtimeconfig /home/REDACTED/work/vs-mef/vs-mef/bin/Tests/Microsoft.VisualStudio.Composition.Analyzers.Tests/Release/net8.0/Microsoft.VisualStudio.Composition.Analyzers.Tests.runtimeconfig.json --depsfile /home/REDACTED/work/vs-mef/vs-mef/bin/Tests/Microsoft.VisualStudio.Composition.Analyzers.Tests/Release/net8.0/Microsoft.VisualStudio.Composition.Analyzers.Tests.deps.json /home/REDACTED/work/vs-mef/vs-mef/bin/Tests/Microsoft.VisualStudio.Composition.Analyzers.Tests/Release/net8.0/testhost.dll --port 34139 --endpoint 127.0.0.1:034139 --role client --parentprocessid 12784 --telemetryoptedin false (dns block)
  • Triggering command: /opt/hostedtoolcache/dotnet/dotnet /opt/hostedtoolcache/dotnet/dotnet exec --runtimeconfig /home/REDACTED/work/vs-mef/vs-mef/bin/Tests/Microsoft.VisualStudio.Composition.Analyzers.Tests/Release/net8.0/Microsoft.VisualStudio.Composition.Analyzers.Tests.runtimeconfig.json --depsfile /home/REDACTED/work/vs-mef/vs-mef/bin/Tests/Microsoft.VisualStudio.Composition.Analyzers.Tests/Release/net8.0/Microsoft.VisualStudio.Composition.Analyzers.Tests.deps.json /home/REDACTED/work/vs-mef/vs-mef/bin/Tests/Microsoft.VisualStudio.Composition.Analyzers.Tests/Release/net8.0/testhost.dll --port 43695 --endpoint 127.0.0.1:043695 --role client --parentprocessid 20365 --telemetryoptedin false (dns block)
• xofvsblobprodwus2114.vsblob.vsassets.io
  • Triggering command: /opt/hostedtoolcache/dotnet/dotnet dotnet build /home/REDACTED/work/vs-mef/vs-mef/src/Microsoft.VisualStudio.Composition.Analyzers/Microsoft.VisualStudio.Composition.Analyzers.csproj -c Release --no-restore (dns block)
  • Triggering command: /opt/hostedtoolcache/dotnet/dotnet dotnet build test/Microsoft.VisualStudio.Composition.Analyzers.Tests/Microsoft.VisualStudio.Composition.Analyzers.Tests.csproj -c Release (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>VSMEF008 false positives in VS SDK contexts</issue_title>
<issue_description>VSMEF008 makes a strong statement with a default severity of Error, based on an assumption of convention.
When we try to use the new analyzer in the VS repo, we see many of these errors:

error VSMEF008: The contract type "SVsFullAccessServiceBroker" is not assignable to the member type "IServiceBroker". The import will fail at runtime. (https://microsoft.github.io/vs-mef/analyzers/VSMEF008.html)
error VSMEF008: The contract type "SAsyncServiceProvider" is not assignable to the member type "IAsyncServiceProvider2". The import will fail at runtime. (https://microsoft.github.io/vs-mef/analyzers/VSMEF008.html)
error VSMEF008: The contract type "Host" is not assignable to the member type "TeamFoundationHost". The import will fail at runtime. (https://microsoft.github.io/vs-mef/analyzers/VSMEF008.html)

In fact, these are not errors (at least not the first two). It is perfectly legitimate to use a type identity as a contract name, even if that type identity is not assignable to the type that the exported object is expected to implement.

We have a few (non mutually exclusive) options here:

1. Reduce the severity of the diagnostic.
2. Reduce the strength of the wording from "The import will fail at runtime" to "The import may fail at runtime".
3. Allow use of AdditionalFiles like some of our other analyzers, so that an SDK can register allowed assignments with our analyzer so it will not report a diagnostic for known good cases.
   I propose the file naming pattern of vs-mef.ContractNamesAssignability.txt. Any AdditionalFiles with that filename will be parsed as a list of lines with this pattern:

   Microsoft.VisualStudio.IServiceBroker <= Microsoft.VisualStudio.Shell.SVsFullAccessServiceBroker
   Microsoft.VisualStudio.IAsyncServiceProvider <= Microsoft.VisualStudio.Shell.SAsyncServiceProvider
   Microsoft.VisualStudio.IAsyncServiceProvider2 <= Microsoft.VisualStudio.Shell.SAsyncServiceProvider
   

   These will be parsed as C# syntax names to form an allow list of assignments that the compiler cannot guarantee statically, and thus will suppress reporting of the VSMEF008 diagnostic when (for example) a MEF export with type identity Microsoft.VisualStudio.Shell.SAsyncServiceProvider is assigned to a variable, field, etc. of type Microsoft.VisualStudio.IAsyncServiceProvider.

IMO we should at least apply the first two of these options. Option 3 would be more expensive but goodness.</issue_description>

<agent_instructions>Implement all 3 of the options listed in the issue as a single change.</agent_instructions>

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

@AArnott @drewnoakes any thoughts?

• Fixes VSMEF008 false positives in VS SDK contexts #681

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[AArnott]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[AArnott]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).