1. 27 10月, 2015 7 次提交
    • K
      Remove equivalenceKey from CodeAction.Create overload · cbb049ff
      Kevin Pilch-Bisson 提交于
      Automatically calculate equivalence keys from nested actions.
      
      Fixes #5975.
      cbb049ff
    • P
      Merge pull request #6255 from pharring/BackgroundCompiler · aeee3243
      Paul Harrington 提交于
      Disable BackgroundCompiler on low VM
      aeee3243
    • K
      Merge pull request #6091 from KevinH-MS/ScriptingNamespace · a8bfa333
      Kevin Halverson 提交于
      [AskMode] Rename MS.CA.Scripting.CSharp to MS.CA.CSharp.Scripting...
      a8bfa333
    • K
      Merge pull request #6239 from KevinH-MS/return · a38c7ff2
      Kevin Halverson 提交于
      [AskMode] Allow return statements in scripts...
      a38c7ff2
    • M
      Merge pull request #6292 from mavasani/Issue6285 · 43943fd1
      Manish Vasani 提交于
      Fix VSIX based analyzers installed in the extensions hive
      
      Customer scenario: User installs any VSIX based analyzer into their extensions hive, but the analyzers and fixers from the installed extension don't work.
      
      Reason: While making the features layer portable, we changed the analyzer assembly loader for VSIX based analyzers to use the PEReader to get the assembly name for loading the assembly. Prior to that, we used to invoke the desktop API "AssemblyName.GetAssemblyName", which sets the CodeBase property of the returned assembly name to be full path of the assembly. Assembly.Load would attempt to load the ngen'ed image of the assembly, and if it doesn't exist then search will eventually fall back to loading the managed assembly at the CodeBase location. We lost the latter functionality when we made the above change, which causes the assembly loader to fail loading the assembly at the specified full path.
      
      Fix: Move the analyzer assembly loader to the non-portable VS diagnostic analyzer provider service. Any host which needs to support VSIX based analyzers must also implement the assembly loader for VSIX analyzers.
      
      Testing: Verified that assemblies from VSIX based analyzer extensions get loaded successfully and the diagnostics/code fixes work fine. Also added a unit test to verify that host analyzer manager can load assemblies from custom install paths - verified that test fails prior to this change.
      
      Fixes #6285 
      43943fd1
    • K
      Rename MS.CA.Scripting.CSharp to MS.CA.CSharp.Scripting... · aeea1b5a
      Kevin Halverson 提交于
      ...and update namespaces contained therein accordingly.
      aeea1b5a
    • K
      Allow return statements in scripts... · 588ee088
      Kevin Halverson 提交于
      588ee088
  2. 25 10月, 2015 5 次提交
    • J
      Merge pull request #6302 from jaredpar/pw · 4469c0bb
      Jared Parsons 提交于
      Remove PumpingWait
      4469c0bb
    • J
      Fix closed build break · 220d8250
      Jared Parsons 提交于
      220d8250
    • J
      Responded to PR feedback · 9e9c6d6e
      Jared Parsons 提交于
      9e9c6d6e
    • J
      Remove PumpingWait · bdc047b6
      Jared Parsons 提交于
      This removes PumpingWait from our test infrastructure and replaces it with proper await calls on the Task(s) in question.
      bdc047b6
    • M
      Fix VSIX based analyzers installed in the extensions hive. · 571f91ed
      Manish Vasani 提交于
      Customer scenario: User installs any VSIX based analyzer into their extensions hive, but the analyzers and fixers from the installed extension don't work.
      
      Reason: While making the features layer portable, we changed the analyzer assembly loader for VSIX based analyzers to use the PEReader to get the assembly name for loading the assembly. Prior to that, we used to invoke the desktop API "AssemblyName.GetAssemblyName", which sets the CodeBase property of the returned assembly name to be full path of the assembly. Assembly.Load would attempt to load the ngen'ed image of the assembly, and if it doesn't exist then search will eventually fall back to loading the managed assembly at the CodeBase location. We lost the latter functionality when we made the above change, which causes the assembly loader to fail loading the assembly at the specified full path.
      
      Fix: Move the analyzer assembly loader to the non-portable VS diagnostic analyzer provider service. Any host which needs to support VSIX based analyzers must also implement the assembly loader for VSIX analyzers.
      
      Testing: Verified that assemblies from VSIX based analyzer extensions get loaded successfully and the diagnostics/code fixes work fine. Also added a unit test to verify that host analyzer manager can load assemblies from custom install paths - verified that test fails prior to this change.
      
      Fixes #6285
      571f91ed
  3. 24 10月, 2015 14 次提交
  4. 23 10月, 2015 10 次提交
  5. 22 10月, 2015 4 次提交