1. 25 1月, 2017 3 次提交
  2. 18 1月, 2017 1 次提交
  3. 14 1月, 2017 1 次提交
    • A
      Disallow extract method when extraction region contains local function (#16021) · 8788a88a
      Andy Gocke 提交于
      Temporarily marks data flow analysis over a region which contains local
      functions as "failed." The current implementation is incorrect, so data
      flow analysis should mark the result as bad rather than knowingly give
      an incorrect result.
      
      This change also causes extract method to emit a warning when extracting
      over a region which involves local functions.
      
      Fixes #15532, #16116, #8719, #8718, #8717
      8788a88a
  4. 12 1月, 2017 1 次提交
  5. 11 1月, 2017 2 次提交
  6. 10 1月, 2017 6 次提交
  7. 07 1月, 2017 5 次提交
  8. 06 1月, 2017 4 次提交
  9. 05 1月, 2017 1 次提交
  10. 04 1月, 2017 3 次提交
  11. 02 1月, 2017 1 次提交
  12. 01 1月, 2017 1 次提交
  13. 31 12月, 2016 4 次提交
  14. 30 12月, 2016 1 次提交
    • J
      Fix our use of suppressParent in project.json · a2027115
      Jared Parsons 提交于
      TLDR: This change removes our use of suppressParent which should not be used
      
      The core problem in our build setup which lead to the use of suppressParent is having
      the same reference DLL introduced by different NuGet packages.  These packages differed
      in name and version from each other.  The most notable example is the reference DLL for Microsoft.VisualStudio.Language.NavigateTo.Interfaces.dll which is contained in 3
      different NuGet packages:
      
      - RoslynDependencies.Microsoft.VisualStudio.Language.NavigateTo.Interfaces 14.0
      - Roslyn.Microsoft.VisualStudio.Language.NavigateTo.Interfaces 15.0 preview 5
      - Microsoft.VisualStudio.Language.NavigateTo.Interfaces 15.0 RC
      
      The differing names is a problem because when resolving conflicts NuGet doesn't consider
      the referenced DLL versions at all (by design).  Instead it is only concerned with
      handling conflicts between packages of the same name.
      
      These packages have different name and hence NuGet never attempts to do any conflict
      resolution between them.  It will consider each package to be a separate entity and
      pass on their assets to MSBuild.  This means that MSBuild will eventually be handed the
      same DLL with 3 different versions and consequently begins issuing MSB3277 errors.
      
      The suppressParent entries in the project.json file suppressed this error because it
      essentially removes the listed package from the transitive graph.  Hence it never appeared
      in referenced projects, only a single DLL was passed to MSBuild and compilations
      progressed.
      
      This is the wrong approach to fixing that problem because it's subverting both the
      depenedncy conflict resolution aspects of NuGet / MSBuild and causing us to create
      incomplete deployments in our unit test directories.  This is fighting the tooling
      instead of leveraging it.
      
      The more robust approach to solving this problem is to have a reference DLL always
      distributed through the same NuGet package.  This allows NuGet to handle the version
      conflicts using standard conflict rules and resulting in only a single DLL being passed
      to MSBuild.
      
      In the past this has been a blocker because we often need DLLs at versions that aren't
      available on NuGet.  Going forward we will be working with the VSSDK to remedy that
      problem.  Short term though we are simply going to upload ad-hoc packages with the correct
      name to the roslyn-tools feed using the pre-release moniker -alpha.  This ensures we
      don't have any conflicts with official packages on NuGet.org.
      
      There are a few cases this change doesn't completely address that I want to call
      out:
      
      - Types moved between the MS.VS.Shell.Immutable and MS.VS.Shell.Framework DLLs between
        Dev14 and Dev15.  To prevent a lot of duplicate type errors the MS.VS.Shell.Immutable
        DLLs need to be removed from the compile graph, but not the runtime graph, in our
        Next projects.
      - GraphModel is an adhoc package created by us that doesn't have an existing NuGet
        package to pattern off of and it's not obvious how such a package would be
        laid out if it existed.  The Dev15 packages also include this as a reference by
        default which causes a confilct with our packages.  As such I've used "include: none"
        for now to work around the problem until a final NuGet package is decided on.
      a2027115
  15. 29 12月, 2016 3 次提交
  16. 28 12月, 2016 3 次提交