1. 20 4月, 2017 1 次提交
  2. 11 4月, 2017 1 次提交
  3. 22 3月, 2017 1 次提交
  4. 16 3月, 2017 1 次提交
  5. 14 3月, 2017 1 次提交
  6. 13 3月, 2017 1 次提交
  7. 10 3月, 2017 1 次提交
  8. 01 3月, 2017 2 次提交
  9. 08 2月, 2017 1 次提交
  10. 02 2月, 2017 4 次提交
  11. 12 1月, 2017 1 次提交
  12. 31 12月, 2016 4 次提交
  13. 29 12月, 2016 3 次提交
  14. 17 12月, 2016 3 次提交
  15. 15 12月, 2016 1 次提交
  16. 30 11月, 2016 1 次提交
    • J
      Centralize CopyNuGetImplementations · f6e3b30a
      Jared Parsons 提交于
      This setting controls binary deployment hence it needs to be centrally
      managed to help ensure we have a correct build.  Custom projects can
      continue to control this setting themselves.
      f6e3b30a
  17. 23 11月, 2016 1 次提交
    • J
      Remove the depedency projects · 5da46238
      Jared Parsons 提交于
      The dependency projects were added as a way to help unify our project.json references.  Instead of every project referencing the NuGet package, we had a dependency project which referenced it and everyone referenced that dependency project.  Due to the transitive nature of NuGet it would be roughly equivalent.
      
      This system had a number of downsides:
      
      1. There was no enforcement.  Even though dependency projects existed, there was no mechanism to force developers to use them.
      2. Getting the granularity correct was tricky.
      3. The projects themselves have special props / targets to get them to produce no output.  This can trip up MSBuild up to date checks.
      
      Since then though we've begun using RepoUtil to verify our NuGet reference correctness.  This removed the need for these projects and hence I'm removing them from our build.
      5da46238
  18. 22 11月, 2016 1 次提交
  19. 19 11月, 2016 2 次提交
  20. 18 11月, 2016 6 次提交
  21. 15 11月, 2016 1 次提交
    • J
      Ensure Visual Studio workspace events are raised on the UI thread · e2db2cc8
      Jason Malinowski 提交于
      Previously, we'd raise workspace events on whatever synchronization
      context created the workspace. If you created the VisualStudioWorkspace
      on a background thread, then this would mean we'd raise events there
      which is not expected by many parts of our codebase. This corrects that
      ensuring they're always raised where they should be. This also applies
      to all workspaces in Visual Studio, which has been a source of bugs
      when somebody had another workspace that they created themselves
      which broke expectations.
      
      While doing this I simplifed the APIs to clarify what they were being
      used for and also removed some FactoryFactories that were unnecessary.
      e2db2cc8
  22. 05 11月, 2016 1 次提交
  23. 04 11月, 2016 1 次提交