- 21 7月, 2017 1 次提交
-
-
由 Manish Vasani 提交于
-
- 20 7月, 2017 1 次提交
-
-
由 Manish Vasani 提交于
The [change](https://github.com/dotnet/roslyn/commit/6be56fadb4c417c4b6af0bf62f1242e41c8dd124) to move analyzers to 2.5 version broke analyzers in the branch - they are laid out differently in the new nuget package. Build targets are unable to find the props for importing the analyzers and silently bail out executing them. This PR fixes the following: 1. Fix the props file path in Imports.Targets 2. Move to a newer analyzer package which has an important [bug fix](https://github.com/dotnet/roslyn-analyzers/pull/1255) 3. Report a build error if analyzer props file does not exist 4. Fix the public API errors (mostly due to duplicate entries in shipped and unshipped files). 5. Fix one instance of RS0014 (Do not use Enumerable methods on indexable collections. Instead use the collection directly) introduced recently in the code. 6. Add suppression for one instance of CA1802 in WellKnownAttributeData.cs that fixed the signing issue.
-
- 10 7月, 2017 1 次提交
-
-
由 Sam Harwell 提交于
This change is required for accurate handling of comments, per dotnet/roslyn#2773.
-
- 28 6月, 2017 3 次提交
-
-
由 Jared Parsons 提交于
The NuGetPackageToIncludeInVsix element is used to make the NuGet assets we use in a VSIX very explicit. It depended on the nuget items having the metadata element NuGetPackageId. The 1.X New SDK no longer has this piece of metadata and hence we had to pick a new approach. After some discussion decided to simply look for the assets which are coming out of the NuGet packages folders that we expect. It's essentially the same check. Needed to encode this in an MSBuild task though as the MSBuild transforms can't handle that level of complexity.
-
由 Jared Parsons 提交于
The warning B40057 used to be suppressed at a global level in PCL / Desktop projects. The SDK does not suppress this warning and hence converting to the new SDK caused this to show up. Previously a number of developers fixed this problem individually. The correct solution is to suppress it globally as was done previously.
-
由 Jared Parsons 提交于
Couple of changes to make it possible to build all desktop projects on new SDK - Use new RunResolvePackageDependencies target - Use LangaugeTargets to allow WPF / VSIX to be built
-
- 27 6月, 2017 1 次提交
-
-
由 Manish Vasani 提交于
Enable few more rules and fix issues identified these rules. Also added issue IDs for the disabled rules due to lack of a fixer/fix all experience.
-
- 24 6月, 2017 1 次提交
-
-
由 Kevin Halverson 提交于
-
- 22 6月, 2017 1 次提交
-
-
由 Kevin Halverson 提交于
-
- 14 6月, 2017 1 次提交
-
-
由 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.
-
- 09 6月, 2017 1 次提交
-
-
由 Jason Malinowski 提交于
This is a workaround for dotnet/project-system#2160 where AdditionalFileItemNames isn't quite behaving correctly with the IDE. This can be reverted once that bug is fixed.
-
- 24 5月, 2017 1 次提交
-
-
由 Julien Couvreur 提交于
* Update toolset compilers to 2.3.0-beta2-61716-09. Use LangVersion=7.1 * Revert LangVersion for VB. Follow-up issue #19610
-
- 20 5月, 2017 1 次提交
-
-
由 Julien Couvreur 提交于
-
- 11 5月, 2017 4 次提交
-
-
由 Jonathon Marolf 提交于
-
由 Jonathon Marolf 提交于
-
由 Jonathon Marolf 提交于
-
由 Manish Vasani 提交于
Re-enable roslyn analyzers on Roslyn.sln and update public api file for an IOperation API change merged yesterday (#19278).
-
- 04 5月, 2017 2 次提交
-
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
The VS SDK team is interested in tracking down the deployment errors that we are seeing when deploying as a part of build. This change adds an option to make it easy to excercise that code path in builds. Going to use this option to quickly toggle to the build based deployment in order to mass test their fixes.
-
- 02 5月, 2017 2 次提交
-
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
The Net20 framework projects were accidentally depending on 3.5 framework in order to build. This is due to how they generate resources. By default when generating resources for a 2.0 framework project the MSBuild task from 3.5 was being used. This is not installed by default with Visual Studio and only through the 3.5 framework. This went unnoticed when moving to the new SDK because all of the Jenkins machines and @jaredpar machines have it installed. Setting the `$(GenerateResourceMSBuildRuntime)` property to CurrentRuntime will use the GenerateResource task from the current version of MSBuild. This is how resources were being generated before the migration.
-
- 01 5月, 2017 10 次提交
-
-
由 Jared Parsons 提交于
-
由 Andy Gocke 提交于
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
The content produced by NuGet restore is independent of build configuration. Hence it needs to be stored in a folder that is accessible to both Debug and Release. This didn't work with the present structure of our Obj directory because it put project folders under configuration directories. That mean there is no common parent for a project across all configurations. To fix this we need to change our Obj structure: - Old: `Obj\<Configuration>\<Project Name>` - New: `Obj\<Project Name>\<Configuration>`
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
This changes our NuGet download and commits us to package reference elements.
-
- 29 4月, 2017 1 次提交
-
-
由 Jason Malinowski 提交于
My motivation for doing this is to pick up the new PublicAPI checker that understands type forwards. In doing so I disabled a bunch of new warnings that are either broken or not really applicable to Roslyn. One new warning (don't rethrow exceptions with throw ex;) seemed useful enough to keep on so I left it on and fixed the one offense in the codebase.
-
- 22 4月, 2017 1 次提交
-
-
由 Jared Parsons 提交于
Based on discussions with SDK team, attempting to switch to using `$(OutputPath)` for controlling our output directory instead of `$(OutDir)`. This is how the SDK recommends teams do it and need to validate whether this will work for us or not.
-
- 20 4月, 2017 1 次提交
-
-
由 Sam Harwell 提交于
-
- 11 4月, 2017 1 次提交
-
-
由 Andy Gocke 提交于
-
- 08 4月, 2017 1 次提交
-
-
由 Andy Gocke 提交于
-
- 30 3月, 2017 1 次提交
-
-
由 Jared Parsons 提交于
The motivation for this change is to simplify our build and develop steps. Previously our compiler builds included files generated into the Obj folder during previous phases of the build. This meant that in order to open Roslyn.sln successfully the code needed to be built first. Not ideal. The generated code involved is rarely changed. But in order to build the generators themselves must be built and run as a part of every build. This is doable but adds unncessary overhead to development and complicates our build files a bit. This approach checks in the generated files which should have the following benefits: - Roslyn.sln can be open after a restore - Build process is simplified and marginally faster for many operations - Generated code now participates in GitLink
-
- 25 3月, 2017 1 次提交
-
-
由 Jared Parsons 提交于
Removes our reliance on the machine installed reference assemblies. Preferring the ones which we bring with us to the machine for both Windows and Linux.
-
- 14 3月, 2017 1 次提交
-
-
由 Jared Parsons 提交于
-
- 10 3月, 2017 1 次提交
-
-
由 Andy Gocke 提交于
-