- 01 3月, 2017 2 次提交
-
-
由 Heejae Chang 提交于
-
由 Heejae Chang 提交于
-
- 08 2月, 2017 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 02 2月, 2017 4 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
- 12 1月, 2017 1 次提交
-
-
由 David Poeschl 提交于
Related to #9960
-
- 31 12月, 2016 4 次提交
-
-
由 Tanner Gooding 提交于
-
由 Tanner Gooding 提交于
-
由 Tanner Gooding 提交于
-
由 Tanner Gooding 提交于
Ensure that all *.*proj, *.props, and *.targets files are prefixed with the xml and copyright elements
-
- 29 12月, 2016 3 次提交
-
-
由 Tanner Gooding 提交于
-
由 Tanner Gooding 提交于
-
由 Tanner Gooding 提交于
-
- 17 12月, 2016 3 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 Tanner Gooding 提交于
-
由 CyrusNajmabadi 提交于
-
- 15 12月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 30 11月, 2016 1 次提交
-
-
由 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.
-
- 23 11月, 2016 1 次提交
-
-
由 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.
-
- 22 11月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 19 11月, 2016 2 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
- 18 11月, 2016 6 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
- 15 11月, 2016 1 次提交
-
-
由 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.
-
- 05 11月, 2016 1 次提交
-
-
由 Beep boop 提交于
-
- 04 11月, 2016 1 次提交
-
-
由 Jared Parsons 提交于
-
- 02 11月, 2016 1 次提交
-
-
由 Jared Parsons 提交于
-
- 31 10月, 2016 1 次提交
-
-
由 Jared Parsons 提交于
-
- 28 10月, 2016 1 次提交
-
-
由 Jared Parsons 提交于
-
- 26 10月, 2016 1 次提交
-
-
由 Jared Parsons 提交于
-
- 25 10月, 2016 2 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
- 24 10月, 2016 1 次提交
-
-
由 Jared Parsons 提交于
-