- 17 12月, 2016 1 次提交
-
-
由 Tanner Gooding 提交于
-
- 19 10月, 2016 1 次提交
-
-
由 Ravi Chande 提交于
This reverts commit 63872019.
-
- 18 10月, 2016 1 次提交
-
-
由 Andy Gocke 提交于
This package now only supports the TFM. This is because the purpose of the package to layout a .NET Core executable, which requires the netcoreapp references, including CoreCLR itself. There are also numerous references that are now provided by inheritance from the compiler itself, so those references have been removed from the Microsoft.Net.Compilers.netcore nuspec. Fixes #12674
-
- 15 9月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 14 7月, 2016 1 次提交
-
-
由 Jason Malinowski 提交于
This works around #12458. The warnings are annoying and also break the project system in slightly bad ways.
-
- 24 6月, 2016 1 次提交
-
-
由 gafter 提交于
-
- 09 6月, 2016 1 次提交
-
-
由 Tomas Matousek 提交于
-
- 01 6月, 2016 1 次提交
-
-
由 Tomas Matousek 提交于
-
- 26 2月, 2016 1 次提交
-
-
由 Andy Gocke 提交于
This reverts commit 760e1204.
-
- 17 2月, 2016 2 次提交
-
-
由 David Kean 提交于
This reverts commit e2fc5135.
-
由 Andy Gocke 提交于
Synchronize all corefx references to -23504 and bring in the xunit coreclr test runner.
-
- 14 12月, 2015 1 次提交
-
-
由 Andy Gocke 提交于
-
- 03 12月, 2015 1 次提交
-
-
由 Jason Malinowski 提交于
These projects are executable projects, and already have runtime sections to get all the right assets deployed. Stating a supports section is redundant
-
- 12 11月, 2015 1 次提交
-
-
由 Andy Gocke 提交于
-
- 07 11月, 2015 1 次提交
-
-
由 Jared Parsons 提交于
-
- 04 11月, 2015 1 次提交
-
-
由 Neal Gafter 提交于
-
- 31 10月, 2015 1 次提交
-
-
由 Andy Gocke 提交于
These references are needed because they are sometimes dynamically loaded at runtime
-
- 29 10月, 2015 1 次提交
-
-
由 Andy Gocke 提交于
-
- 23 10月, 2015 1 次提交
-
-
由 Andy Gocke 提交于
-
- 17 10月, 2015 1 次提交
-
-
由 David Kean 提交于
Csc and Csi are portable projects targeting 5.0 portable without support clauses, this confuses portable as it doesn't know the projects target and warns when they reference other portable projects. This also enables package validation to ensure that these projects will never reference a package that doesn't work on its given targets.
-
- 16 10月, 2015 1 次提交
-
-
由 Paul Harrington 提交于
-
- 15 10月, 2015 1 次提交
-
-
由 Andy Gocke 提交于
-
- 10 10月, 2015 1 次提交
-
-
由 Tanner Gooding 提交于
Updating System.Reflection.Metadata to 1.1.0-alpha-0015 and System.Collections.Immutable to 1.1.37.0
-
- 09 10月, 2015 4 次提交
-
-
由 Tanner Gooding 提交于
Revert "Updating System.Reflection.Metadata to 1.1.0-alpha-0015 and System.Collections.Immutable to 1.1.37.0" This reverts commit d78dbb97.
-
由 Tanner Gooding 提交于
Updating System.Reflection.Metadata to 1.1.0-alpha-0015 and System.Collections.Immutable to 1.1.37.0
-
由 Tanner Gooding 提交于
Reverting System.Collections.Immutable back to 1.1.36 until we can upgrade System.Reflection.Metadata simultaneously
-
由 Tanner Gooding 提交于
Updating Microsoft.DiaSymReader to v1.0.6, Microsoft.DiaSymReader.Native to v1.2.0, and System.Collections.Immutable to v1.1.37
-
- 04 10月, 2015 1 次提交
-
-
由 Andy Gocke 提交于
-
- 29 9月, 2015 1 次提交
-
-
由 Andy Gocke 提交于
After updating to the latest CoreCLR NuGet packages we no longer need to be copying binaries from a drop share to run. This change adds a csc.sh and a vbc.sh so we can run on the CoreRun host on Linux like we do on Windows. The change also eliminates some cruft from the cibuild like the semaphore restore.
-
- 24 9月, 2015 2 次提交
-
-
由 Andy Gocke 提交于
-
由 Andy Gocke 提交于
Adds a new type, CoreClrAnalyzerAssemblyLoader, that is responsible for finding and loading analyzer assemblies on CoreCLR. This is used in the CscCore and VbcCore CoreCLR-targeting projects.
-
- 23 9月, 2015 2 次提交
-
-
由 Andy Gocke 提交于
-
由 Andy Gocke 提交于
Some of the references were outdated and some of the NuGet packages were incorrectly authored. With the new references we don't need to do any extra work to copy over the CoreCLR runtime -- it's copied as a reference by NuGet 3 without any extra work.
-
- 18 9月, 2015 1 次提交
-
-
由 Andy Gocke 提交于
Rogjt mpw we build a boostrap version of csc and vbc and bootstrap with those running on Mono. This commit switches us to build a CoreCLR compatible csc and then running the boostrap on CoreCLR Right now the full set of Linux CoreCLR runtime assemblies is not available on NuGet, so we substitute with some assemblies we stash in our NuGet ZIP package.
-
- 03 9月, 2015 1 次提交
-
-
由 Andy Gocke 提交于
-
- 27 8月, 2015 1 次提交
-
-
由 Tomas Matousek 提交于
-
- 14 8月, 2015 1 次提交
-
-
由 Andy Gocke 提交于
Once System.Runtime.Loader is referenced in the project.json files a facade is correctly copied to the output directory, so AssemblyLoadContext can be loaded even if the assembly it's located in changes.
-
- 13 8月, 2015 1 次提交
-
-
由 Andy Gocke 提交于
On CoreCLR we will always be unable to fetch the default encoding and the 1252 encoding will be unavailable unless we reference System.Text.Encoding.CodePages. However, we don't want to take a dependency on this assembly on desktop 4.5 so we now use AssemblyLoadContext to try to detect whether or not we are running on CoreCLR and, if so, reflection load the necessary assemblies to get hold of the necessary types.
-
- 07 8月, 2015 1 次提交
-
-
由 Richard L Ford 提交于
This change solves a number of problems that were resulting in problems compiling Roslyn with Roslyn on the CoreClr. I believe these problems were being masked by catching exceptions. The motivation for the changes is to be able to run Roslyn building Roslyn on Clr using the LLILC jit. LLILC cannot currently produce code to catch exceptions so it is important to avoid needless throwing of exceptions. 1. CoreClr was raising FileNotFound exceptions when trying to load the following assemblies: ``` System.Threading.Overlapped System.Threading.ThreadPool ``` I added references to these in src/Compilers/CSharp/CscCore/project.json. 2. System.Runtime in the version previously referenced in project.son had a reference to Internal.Uri. This is no longer the current module (it has been replaced by System.Private.Uri). So I changed the version number used in project.json from 22816 to 23109. 3. The path in these ruleset files: * src/Compilers/Core/CodeAnalysisRules.ruleset * src/Compilers/CSharp/CSharpCodeAnalysisRules.ruleset * src/Compilers/VisualBasic/BasicCodeAnalysisRules.ruleset was "..\..\Tools\Microsoft.CodeAnalysis.Toolset.Open\Rulesets\Roslyn.ruleset" which is not the current location of Roslyn.ruleset. It now is in "..\..\..\build\Rulesets\Roslyn.ruleset". The incorrect path was causing an exception to be thrown. 4. On the CoreClr csc uses a NoOpAnalyzerAssemblyLoader which just returns null when asked to get the assembly. This was causing a null reference exception. I added a null check to just return in this case. 5. The VbcCore project.json was updated to match CscCore.
-
- 05 8月, 2015 1 次提交
-
-
由 Andy Gocke 提交于
-