- 23 12月, 2016 6 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
- 22 12月, 2016 4 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 Jonathon Marolf 提交于
* moving naming styles types into the workspace layer. Teaching abstract options serialization service about naming styles. * Implementing naming styles support for editorconfig * responding to david's PR feedback * responding to Jason's feedback * responding to Jason's feedback part 2 * addressing the latest set of comments from David * addressing Jason's comments * addressing Kevin's comments
-
- 21 10月, 2016 1 次提交
-
-
由 David Poeschl 提交于
This reverts commit 9f30b914.
-
- 20 10月, 2016 2 次提交
-
-
由 David Poeschl 提交于
This reverts commit 12ce69e2. Reverting this because it is causing VSI test failures, especially around Razor.
-
由 David Poeschl 提交于
This change also introduces Specification and Style management (deleting and editing). Also, fixes #14358
-
- 13 9月, 2016 1 次提交
-
-
由 Jason Malinowski 提交于
-
- 10 9月, 2016 2 次提交
-
-
由 Jason Malinowski 提交于
Now that feature names aren't used for serialization anymore, we can just get rid of the constants and use the containing type name. Also, update more options to use nameof where appropriate.
-
由 Jason Malinowski 提交于
Now that we have an API for associating persistence information, we can put that information on all our options we persist today. We'll consume this in a future commit.
-
- 24 8月, 2016 1 次提交
-
-
由 Balaji Krishnan 提交于
and plumb them through the UI, persistence, analyzer/fixer and other parts of the system. update the simplifier to use the new options. update codegen features as necessary.
-
- 26 5月, 2016 1 次提交
-
-
由 Brett V. Forsgren 提交于
-
- 01 3月, 2016 1 次提交
-
-
由 David Poeschl 提交于
Implements #7064 This change includes: - An analyzer and codefix for enforcing naming styles and fixing symbol names to comply with a chosen & configurable set of naming rules. - A set of Enforcement Levels that can be applied to different naming rules. - A mechanism for linking from a lightbulb preview to the option that caused the related diagnostic to be created (could be moved to a different PR or release) - Moving of the "Formatting" options pages under the Code Style node.
-
- 27 2月, 2016 2 次提交
-
-
由 Brett V. Forsgren 提交于
-
由 Brett V. Forsgren 提交于
-
- 05 6月, 2015 1 次提交
-
-
由 Tomas Matousek 提交于
-
- 15 1月, 2015 1 次提交
-
-
由 jaredpar 提交于
-
- 14 1月, 2015 1 次提交
-
-
由 RoslynTeam 提交于
-
- 07 10月, 2014 1 次提交
-
-
由 jasonmalinowski 提交于
This change splits the Workspaces layer into two parts, mirroring the Portable/Desktop split that the compilers did. The core parts of the Workspaces layer (managing documents and projects, formatting, some refactoring, code fixes) is kept in the portable subset, with a few non-portable pieces remaining, notably MSBuild support. This change has a major impact on how MEF now works in Roslyn. Traditional MEF (“MEFv1”) is not portable, and so we must move the Workspaces layer over to using the Microsoft.Composition NuGet package (“MEFv2”) which is. The APIs are distinct in that each has its own namespace, but the concepts are more or less identical. It requires some care though: the workspaces layer is simple in that it only references MEFv2, but higher layers have to reference both versions to use metadata attributes. Exports using metadata attributes from the editor (say, ContentTypeAttribute) must use MEFv1 attributes to export, whereas exports for the workspaces layer must use MEFv2 attributes. The rule is subtle and yet simple, and so a diagnostic is provided which catches any offenses to prevent confusion. This also has some impact in how we create MEF hosts: if you wish to host just the base workspaces layer, we can use MEFv2 to compose everything. The HostServices implementation (MefV1HostServices) that consumes a MEFv1 ExportProvider. If you’re in Visual Studio, you can use this implementation to get the full set of host services provided in Visual Studio. Otherwise, most of the changes in here are minor: we react to some APIs that have been moved/renamed in the portable subset we are targeting, and also align our various exception helper utilities with the compiler’s precedent. (changeset 1349276)
-
- 29 5月, 2014 1 次提交
-
-
由 Basoundr_ms 提交于
Introduce option to prefer Intrinsic Predefined Type keyword instead of Expanded Syntax in Member Access Expression. The default value is True. Option set to True: class Program { static void M() { var local = int.MaxValue; } } Option set to False: class Program { static void M() { var local = System.Int32.MaxValue; } } (changeset 1265497)
-
- 23 5月, 2014 1 次提交
-
-
由 Basoundr_ms 提交于
Introduce option to prefer intrinsic type keyword over expanded type. The default option is to prefer the intrinsic keyword Eg: 1. With the option enabled[default] class Program { private int _member; static void M(int argument) { int local; } } 2. With option disabled class Program { private System.Int32 _member; static void M(System.Int32 argument) { System.Int32 local; } } (changeset 1260681)
-
- 24 4月, 2014 1 次提交
-
-
由 jasonmalinowski 提交于
Without this, the option service couldn't distinguish between the two, and so it was loading the feature-specific option serializers for non-feature-specific options. This not only was a waste of resources (the VB serializers don't need to be loaded if all you have is C# open), but also risked deadlocks due to the subtleties in how serializers in VS must be created. (changeset 1238958)
-
- 10 4月, 2014 1 次提交
-
-
由 chandera 提交于
Initial work to add options pages that allow users to adjust simplification options. (changeset 1226565)
-
- 19 3月, 2014 1 次提交
-
-
由 Pilchie 提交于
-