-
Notifications
You must be signed in to change notification settings - Fork 386
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
Unable to instrument module because : Input string was not in a correct format #998
Comments
After debugging into this, I found the problem. We have a few classes that put generic params in the file name with curly braces like so (it's a shared file several projects inport):
This causes a problem with the code in public void Verbose(string format, params object[] args)
{
EqtTrace.Verbose($"[coverlet]{format}", args);
} We can rename our files to workaround this, but it might be good to scrub the |
Of note, SA1649 when enabled expects file names for generic classes to either elide the type param(s) or use |
Hi @heaths thanks a lot for the investigation. We should fix with a replace. |
Using VSTest integration, we generate coverage reports for our primarily netstandard2.0-targeting assemblies. However, for a subset of assemblies (seemingly the first in a directory listing per service directory, e.g. in https://github.com/azure/azure-sdk-for-net: Azure.Core under sdk/core and Azure.Security.KeyVault.Administration in sdk/keyvault) diagnostic lots on the CI (Azure Pipelines) show something like:
This is from build https://dev.azure.com/azure-sdk/public/_build/results?buildId=629023&view=logs&j=1e00682f-6081-5348-8da2-7d601664b2e3&t=4f3e1a81-cacf-5ad2-6e75-5049507bfdad (should be retained for ~30 days).
Running the same commands (just different source path) locally yields the expected results, e.g. Azure.Core is covered, as is Azure.Security.KeyVault.Administration.
Looking at other issues here, it seems the
FormatException
that's being thrown (based on the error message) is most often from targeting < netstandard2.0, but our baseline already is netstandard2.0. Our common root dependency, Azure.Core, targets net461 and netstandard2.0 (for those few rare classes in net461 that aren't actually in netstandard2.0) but, either way, should work according to other issue conversations herein.We are using the latest GA for Microsoft.NET.Test.Sdk, 16.8.0.
Update: setting
/p:ContinuousIntegrationBuild=true
on the local repro (same command line as CI otherwise; that property is set via targets in CI based on$TF_BUILD
) repro'd locally. I'll attempt to debug into the problem.The text was updated successfully, but these errors were encountered: