1. 17 6月, 2017 6 次提交
  2. 16 6月, 2017 10 次提交
  3. 15 6月, 2017 7 次提交
  4. 14 6月, 2017 5 次提交
    • I
      9e3f773f
    • H
      more renames · 599dc55f
      Heejae Chang 提交于
      599dc55f
    • H
    • J
      Merge pull request #20188 from jaredpar/fix-settings · aa51be5b
      Jared Parsons 提交于
      Move language settings after SDK import
      aa51be5b
    • J
      Move language settings after SDK import · c144ec6d
      Jared Parsons 提交于
      The new SDK unconditionally sets a number of MSBulid properties
      including many that we depend on in Roslyn.  This is a break from the
      old MSBuild behavior which respected initial values.
      
      https://github.com/dotnet/sdk/issues/752
      
      The behavior in 2.0 is changing to go back to the old model of
      respecting initial values.  Roslyn though continues to often use the SDK
      installed with Visual Studio.  That can be a variety of values from 2.0
      prebuilds, to various drops of 1.0.
      
      As a result the success / failure of our build can depend a lot on which
      version of VS is installed and by consequence which new SDK comes with
      it.  Subtle differences in the SDK can change the values we end up
      compiling with in our project.  We've been guarding against this
      by directly re-setting values we knew to be overidden in some version
      of the SDK.
      
      Now though I'm worried this isn't an adequete solution for the following
      reasons.
      
      - Just this week I got new warnings in the build by using a new VS
      - The Microbuild lab is aggressively grabbing new builds of VS which
      means the VS SDK is also potentially changing.
      
      After some thought I decided to simply move all of our langauge specific
      settings after we import the core targets.  Given that we
      unconditionally set the values it becomes irrelevant what the SDK does
      or does not respect.
      c144ec6d
  5. 13 6月, 2017 10 次提交
  6. 11 6月, 2017 1 次提交
  7. 10 6月, 2017 1 次提交