- 28 1月, 2015 1 次提交
-
-
由 beep boop 提交于
-
- 27 1月, 2015 2 次提交
- 14 1月, 2015 2 次提交
-
-
由 RoslynTeam 提交于
-
由 jaredpar 提交于
Change Description: This change moves Roslyn off of our custom version of xUnit to an official release (xUnit 1.9.2): - Deletes all of the custom xUnit binaries from Closed\Tools\xUnit - Put a subset of the official 1.9.2 binaries with no name mangling into Closed\Tools\xUnit. - Rebuilt our custom xUnit GUI (named xunit.gui.custom) against 1.9.2 and put it in Closed\Tools\xUnit - Updated the targets file, RunTests.ps1 and Test.exe to refer to the updated binary names. - Changed the Roslyn unit tests to work on standard xUnit. The biggest part of the effort was the last part, getting the tests to run on standard xUnit. The main issue here was many assumed they would be executed on a single STA thread and as a result cached many thread affinitized values into static fields. Fixing this involved mostly finding the values and annotating them with [ThreadStatic]. This does mean that MEF composition will happen several times during an xUnit run where before it happened only once. That is unfortunate but doesn't seem to regress the suites in a significant way on my machine. Using a multithreaded MEF container isn't an option here because the services end up caching thread affinitized WPF values. ForegroudThreadAffinitizedObject was the other largest change. It's use of a static ctor to establish the foreground thread is dangerous and should be correctly addressed in a future change. For now I added a method for tests to reset the identified foreground thread. More changes will be coming here for our use of xUnit. But they should be smaller and more targetted (deleting the extra sources, a better build story for the GUI, etc ...). Note: Why 1.9.2 instead of 2.0? We have several uses of custom xUnit extensibility that is not easily portable to 2.0. Best path forward is to delete that extensibility since it isn't really adding much and move us directly onto 2.0 in a later check in. (changeset 1395675)
-
- 24 12月, 2014 1 次提交
-
-
由 angocke 提交于
***NO_CI*** (changeset 1384854)
-
- 11 11月, 2014 1 次提交
-
-
由 Sam Harwell 提交于
-
- 02 11月, 2014 1 次提交
-
-
由 KevinRansom 提交于
-
- 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)
-
- 02 10月, 2014 1 次提交
-
-
由 AlekseyTs 提交于
Create a project for a vbcsc2ui.dll to hold resource used by vbc2.exe and csc2.exe. (changeset 1346108)
-
- 10 9月, 2014 1 次提交
-
-
由 RoslynTeam 提交于
messages. The new native client is written in C++11 to be more maintainable and forward-looking. The native client is a static library, which is now linked into the csc2 and vbc2 projects instead of having a single csc2.cpp file which is shared between the two projects and built for each based on a preprocessor definition. The MSBuildTask is also configured to use csc2/vbc2 and feature no extra code for Roslyn, which will prevent us from having to maintain both a native and a managed version of the client. (changeset 1325415)
-
- 02 7月, 2014 3 次提交
-
-
由 shyamn 提交于
In order to validate warning ids that can appear within #Disable directives in VB, we need to generate an ErrorFacts helper that will tell us precisely whether or not the specified id is a valid VB warning id (similar to what C# uses to do corresponding validation within #pragmas). This change adds a simple ErrorFacts generator tool that will be invoked as part of building VB. The implementation is identical to the ErrorFacts generator for C#. (changeset 1287001)
-
由 angocke 提交于
-
由 TomasMatousek 提交于
rcsc to csc rcsi to csi rcsc2 to csc2 rvbc to vbc rvbi to vbi rvbc2 to vbc2 (changeset 1285266)
-
- 20 6月, 2014 2 次提交
-
-
由 VSadov 提交于
-
由 TomasMatousek 提交于
Splits Microsoft.CodeAnalysis, Microsoft.CodeAnalysis.CSharp and Microsoft.CodeAnalysis.VisualBasic into portable and desktop assemblies. Existing Core\Source, CSharp\Source and VisualBasic\Source directories are renamed to Core\Portable, CSharp\Portable and VisualBasic\Portable. New sibling Desktop folders are added and non-portable source is moved there. "System.Runtime" references has to be removed in order for the portable project system magic to automatically add facade references. (changeset 1281686)
-
- 11 6月, 2014 1 次提交
-
-
由 JoshVarty 提交于
-
- 19 4月, 2014 1 次提交
-
-
由 acasey 提交于
Fix DiagnosticAnalyzer project GUIDs and add missing build configurations for the Visualizer projects. (changeset 1234903)
-
- 18 4月, 2014 1 次提交
-
-
由 acasey 提交于
CR: VSadov; GNamboo (changeset 1234211)
-
- 12 4月, 2014 1 次提交
-
-
由 nslottow 提交于
Added the first diagnostic analyzer (+tests) which will eventually analyze Roslyn.sln. It produces the following diagnostics: RS0001: Use SpecializedCollections.EmptyEnumerable<T>() instead of allocating an array of length 0 or using System.Linq.Enumerable.Empty<T>() RS0002: Use SpecializedCollections.SingletonEnumerable<T>() instead of allocating an array of length 1. In order to get RS0002 completely correct, analyzers need to be able to do data flow analysis, so there are a few skipped tests for now. In the process of implementing the unit tests, I also pulled the diagnostic analyzer test base into a separate project, DiagnosticsTestUtilities. I updated the analyzer test base to provide output formatted to be immediately usable in test cases, similar to the compiler diagnostics tests. (changeset 1229264)
-
- 08 4月, 2014 1 次提交
-
-
由 RoslynTeam 提交于
-
- 05 4月, 2014 1 次提交
-
-
由 nslottow 提交于
Moved FxCop diagnostic analyzer, test, and setup projects into Diagnostics\FxCop folder. Renamed the FxCop analyzer test assembly so as not to be confused with Roslyn.Diagnostics.Analyzers.UnitTests. Added Roslyn diagnostic analyzer projects to Roslyn.sln. (changeset 1223294)
-
- 28 3月, 2014 2 次提交
-
-
由 jeremymeng 提交于
This reverts commit 0f498ba6.
-
由 jeremymeng 提交于
-
- 27 3月, 2014 1 次提交
-
-
由 angocke 提交于
-
- 23 3月, 2014 1 次提交
-
-
由 kayleh 提交于
Removing unused solution configurations from Roslyn.sln. (changeset 1211259)
-
- 20 3月, 2014 1 次提交
-
-
由 KirillOsenkov 提交于
-
- 19 3月, 2014 1 次提交
-
-
由 Pilchie 提交于
-