1. 09 7月, 2020 2 次提交
    • J
      Standardize our test references (#45690) · 6ebca394
      Jared Parsons 提交于
      This change standardizes the reference assemblies we use for compilation in our unit test to be the actual .NET Framework reference assemblies. 
      
      Prior to this change they were a mix of reference and implementation assemblies from non-RTM versions of the .NET Framework. In order to map the existing assemblies to their respective target framework version I worked with the servicing team and we mapped them to the closest possible TFM based on their file versions. The bulk of the change is essentially mechanically moving from names like `mscorlib.v4_30319_17929` to `Net451.mscorlib`.
      
      Unfortunately in several cases the non-RTM assemblies didn't cleanly map to a RTM TFM. This was particularly problematic when migrating the `v4_30319` references as this is a mix of a `net40` and `net451` versions. This caused issues in our code base because these references were freely mixed with actual `net40` and `net451` references in the code base. Most of the time this went unnoticed because the test didn't expose the gaps in the APIs. In a lot of cases though, particularly when mixing a version of `System.Core` that did or didn't have `ExtensionsAttribute`, this required some manual inspection on my part and a fix. In pretty much every case this was a straight forward fix but it did mean the change was less mechanical than I would have preferred.
      
      To make this change easier to review I've broken it up into three commits:
      
      1. The actual changes to `Roslyn.Test.Utilities` that move us to the new references.
      1. The changes to our test code which required more than a simple straight forward reference update or explicitly involved retargetting code. These are changes I think deserve stronger scrutiny than the more mechanical aspects of this PR.
      1. The mechanical changes to move from the old references to the new ones. This is the bulk of the change but is for the most part renames. 
      
      The benefits of this change are the following:
      
      1. Have our test more closely mirror customer scenarios by using official reference assemblies.
      1. Improve the readability of the tests by referring to assemblies by their target framework, which is familiar to most developers, instead of their file version, which is familiar to servicing team only.
      1. Reduces the build output size of Roslyn by **~5GB**
      
      The internal PR is here https://github.com/dotnet/roslyn-internal/pull/1954
      
      Note: I will be making more changes in this area in future PRs. But I wanted to keep the mechanical portion of this change into its own PR. Further PRs will be smaller but less mechanical. 
      6ebca394
    • S
      4a66393f
  2. 07 7月, 2020 1 次提交
  3. 06 7月, 2020 1 次提交
  4. 03 7月, 2020 1 次提交
  5. 02 7月, 2020 2 次提交
  6. 30 6月, 2020 4 次提交
  7. 26 6月, 2020 1 次提交
  8. 19 6月, 2020 1 次提交
  9. 15 6月, 2020 1 次提交
  10. 11 6月, 2020 1 次提交
  11. 10 6月, 2020 1 次提交
  12. 09 6月, 2020 2 次提交
  13. 08 6月, 2020 2 次提交
    • M
      Dogfood the new .NET analyzers NuGet package · 6fb3c507
      Manish Vasani 提交于
      Roslyn repo currently includes analyzer package references to sub-packages of FxCopAnalyzers package (Microsoft.CodeQuality.Analyzers and Microsoft.NetCore.Analyzers). Due to the high noise level for default enabled CA rules from these packages, we end up turning off majority of these rules for the repo in our ruleset files. This change switches the repo from FxCop analyzers package to .NET analyzers package (NOTE: we plan to ship the analyzer assemblies from this package in the .NET SDK soon). This helps us dogfood the experience from this new analyzer package, especially from the perspective of noise from default enabled analyzers, while also cleaning up our configuration files. Some more details below:
      
      - The new package has the same set of CA rules, but the legacy ones are now disabled by default.
      - There are a handful of rules which are enabled by default as IDE suggestions (Info severity): either as part of the triage of pre-existing CA rules OR recently added by the .NET runtime team.
      - There are even fewer set of rules which are enabled by default as warnings – all of these have been added by the .NET runtime team, none of the pre-existing rules are enabled as warnings in this package.
      
      The core dogfooding aspect would be:
      
      1. Enabled by default rules:
         1. Analyzer exception diagnostics (AD0001): absolute must to fix or disable these rules by default in the package.
         2. Noise from false positives: It would be a higher priority issue if the false positives are from a rule which is enabled as a build warning, but we should fix even false positives from info rules. We may also want to consider bumping these rules to lower severity or disabling them by default.
         3. Rules which had to be turned off for specific projects, say test projects. We should re-triage such rules and consider if they should be disabled by default.
      
      2. Disabled/Info rules which were escalated to Info/Warnings as we found these to be valuable and reliable: We can potentially re-triage each of these rules and consider if they are valuable enough to have its default severity/enabled state changed to benefit customers.
      6fb3c507
    • M
      4c1710dc
  14. 03 6月, 2020 1 次提交
  15. 02 6月, 2020 2 次提交
  16. 26 5月, 2020 1 次提交
  17. 21 5月, 2020 1 次提交
  18. 19 5月, 2020 2 次提交
  19. 18 5月, 2020 1 次提交
  20. 16 5月, 2020 1 次提交
  21. 14 5月, 2020 1 次提交
  22. 11 5月, 2020 1 次提交
  23. 09 5月, 2020 1 次提交
  24. 08 5月, 2020 1 次提交
  25. 07 5月, 2020 2 次提交
  26. 05 5月, 2020 1 次提交
  27. 04 5月, 2020 1 次提交
  28. 28 4月, 2020 1 次提交
  29. 25 4月, 2020 1 次提交
    • F
      Update System.Memory version (#43515) · 75b9ce96
      Forgind 提交于
      * Update System.Memory version
      
      This should automatically update System.Numerics.Vectors, which is needed by the MSBuild team to add a new dependency on System.Text.Json, which is used in adding support for solution filter files in MSBuild.
      
      * Update System.Buffers version
      
      System.Memory depends on it being updated.
      75b9ce96
  30. 24 4月, 2020 1 次提交