Movatterモバイル変換


[0]ホーム

URL:


Wayback Machine
331 captures
04 Feb 2015 - 03 Jul 2025
SepOCTMar
Previous capture14Next capture
201820192020
success
fail
COLLECTED BY
Organization:Internet Archive
The Internet Archive discovers and captures web pages through many different web crawls.At any given time several distinct crawls are running, some for months, and some every day or longer.View the web archive through theWayback Machine.
Content crawled via theWayback Machine Live Proxy mostly by the Save Page Now feature on web.archive.org.

Liveweb proxy is a component of Internet Archive’s wayback machine project. The liveweb proxy captures the content of a web page in real time, archives it into a ARC or WARC file and returns the ARC/WARC record back to the wayback machine to process. The recorded ARC/WARC file becomes part of the wayback machine in due course of time.
TIMESTAMPS
loading
The Wayback Machine - https://web.archive.org/web/20191014104939/https://github.com/dotnet/coreclr
Skip to content
Sign in Sign up

/coreclr

All your code in one place

Over 40 million developers use GitHub together to host and review code, project manage, and build software together across more than 100 million projects.

Sign up for free See pricing for teams and enterprises
CoreCLR is the runtime for .NET Core. It includes the garbage collector, JIT compiler, primitive data types and low-level classes.
C#C++CAssemblyCMakeRoffOther
Branch:master
Clone or download

Clone with HTTPS

Use Git or checkout with SVN using the web URL.

Launching GitHub Desktop...

If nothing happens,download GitHub Desktop and try again.

Launching GitHub Desktop...

If nothing happens,download GitHub Desktop and try again.

Launching Xcode...

If nothing happens,download Xcode and try again.

Launching Visual Studio...

If nothing happens,download the GitHub extension for Visual Studio and try again.

Permalink
TypeNameLatest commit messageCommit time
Failed to load latest commit information.
DocumentationUpdate Jit formatting link (#27171)Oct 13, 2019
crossClean up our CMake scripts using features introduced between 3… (#26980)Oct 7, 2019
engRun tests on Alpine 3.10. (#27093)Oct 11, 2019
scriptsRemove native test build from build.sh (#26176)Aug 22, 2019
srcReplace primitive Array fcalls with managed implementations (#27123)Oct 14, 2019
testsMerge pull request#27114from erozenfeld/Fix27027Oct 11, 2019
.editorconfigUpdate coreclr's .editorconfig to match corefx's (#26214)Aug 16, 2019
.gitattributesAdd Word2Vec Benchmark Harness (#17350)Apr 5, 2018
.gitignoreSwitch NuGet package build to use Arcade instead of BuildTools (#24619)May 21, 2019
.gitmirrorselectiveRename gitmirrorfileNov 11, 2016
CMakeLists.txtClean up our CMake scripts using features introduced between 3… (#26980)Oct 7, 2019
CODE_OWNERS.TXTUpdate CODE_OWNERS.TXT (#17114)Mar 22, 2018
CONTRIBUTING.mdCreate CONTRIBUTING.md (#6386)Jul 22, 2016
Directory.Build.propsTell the compiler to emit nullable attributes for public API only (#2…Jun 26, 2019
Directory.Build.targets[master] Update dependencies from dotnet/arcade (#24333)May 24, 2019
LICENSE.TXTUpdate License and add 3PN notices (#10117)Mar 12, 2017
NuGet.configUpdate dependencies fromhttps://dev.azure.com/dnceng/internal/_git/d…Jun 25, 2019
PATENTS.TXTAdd additional data to PATENTS.TXTNov 18, 2015
README.mdTypos (#19737)Aug 29, 2018
THIRD-PARTY-NOTICES.TXTUpdating Math.Round and MathF.Round to be IEEE compliant so that the …Aug 5, 2019
all.locprojInitial commit to populate CoreCLR repoJan 30, 2015
build-packages.cmdStop using %~dp0 in build scripts after args processing (#24842)May 30, 2019
build-packages.shUse Arcade for native versioning (#24785)May 29, 2019
build-test.cmdReuse managed test components across all *nix flavors (#26581)Sep 26, 2019
build-test.shReuse managed test components across all *nix flavors (#26581)Sep 26, 2019
build.cmdClean up our CMake scripts using features introduced between 3… (#26980)Oct 7, 2019
build.shFix publishing crossgen2 on macOSSep 17, 2019
clean.cmdManually update the dependencies.props and move S.P.Corelib to use La…Feb 15, 2019
clean.shRemove run.exe and config.json (#21608)Jan 31, 2019
clr.featuredefines.propsDelete unnecessary locale arguments (#24624)May 17, 2019
clrdefinitions.cmakeClean up our CMake scripts using features introduced between 3… (#26980)Oct 7, 2019
clrfeatures.cmakeUpdate to AutoTrace (#24936)Jun 4, 2019
cmake_msbuild.cmdUse arcade's version of dotnet to build (#22755)Mar 2, 2019
configurecompiler.cmakeClean up our CMake scripts using features introduced between 3… (#26980)Oct 7, 2019
configureoptimization.cmakeUnify Unix arm compiler optimization options (#26299)Aug 28, 2019
crosscomponents.cmakeRemove more JIT LEGACY_BACKEND tendrilsMay 23, 2018
definitionsconsistencycheck.cmakeMove intermediate file into intermediate dir (#5981)Jun 28, 2016
dependencies.propsRemove buildtools (#26108)Sep 17, 2019
dir.common.propsRemove buildtools (#26108)Sep 17, 2019
dir.propsFix duplicate imports in managed product build (#25174)Jun 15, 2019
dir.traversal.targetsRespond to PR feedbackFeb 14, 2017
dotnet-download.ps1Refactor dotnet download code in init-tools.cmd (#10527)Apr 1, 2017
dotnet.cmdRemove BuildTools from product build (#24841)May 30, 2019
dotnet.shAdd source-build hook for dotnet install (#24929)Jun 10, 2019
enablesanitizers.shFix asan false-positive errors: (#15563)Jan 25, 2018
functions.cmakeClean up our CMake scripts using features introduced between 3… (#26980)Oct 7, 2019
generateexportedsymbols.awkChange [:space:] to [[:space:]] in awk scripts (#25670)Jul 17, 2019
generateredefinesfile.awkChange [:space:] to [[:space:]] in awk scripts (#25670)Jul 17, 2019
generateversionscript.awkAdd prefix to DAC's PAL exports for alpine (#18873)Jul 13, 2018
global.jsonUpdate to minimum CMake version of 3.14 (#26777)Oct 1, 2019
init-distro-rid.shFix generation of RID on distros that do not set VERSION_ID (#25034)Jun 22, 2019
init-dotnet.cmdRemove BuildTools from product build (#24841)May 30, 2019
init-dotnet.shChange how build.sh/build.cmd parse the PGO and IBC versionsJun 12, 2019
pgosupport.cmakeClean up our CMake scripts using features introduced between 3… (#26980)Oct 7, 2019
run-cppcheck.shNetBSD: Add support for retrieving the number of available CPUsJan 21, 2016
sanitizerblacklist.txtReduce clr startup noise when using Clang sanitizersJan 21, 2016
setup_vs_tools.cmdSupport building with VS2019 Preview (#22525)Feb 12, 2019
sync.cmdManually update the dependencies.props and move S.P.Corelib to use La…Feb 15, 2019
sync.shFix sync.sh syntax error (#22883)Feb 27, 2019
verify-so.shFix shared library dependencies verification on some platforms (#8349)Nov 29, 2016

README.md

.NET Core Common Language Runtime (CoreCLR)

This repository contains the complete source code for the runtime of.NET Core.If you are new to .NET Core start with theAbout .NETthat quickly points you to.NET Core Tutorials.

.NET Core is best thought of as 'agile .NET'. Generally speaking it is the same astheDesktop .NET Frameworkdistributed as part of the Windows operating system, but it is a cross platform(Windows, Linux, macOS) and cross architecture (x86, x64, ARM) subset that can be deployedas part of the application (if desired), and thus can be updated quickly to fix bugs or add features.

If You Just Want to Use .NET Core

Most users don't need to build .NET Core from source since there is already a built and tested version for any supported platform.You can get the latestreleased version of the .NET Core SDK by following the instructions onthe.NET Core Getting Started page.If you need the most up to date (daily) version of this .NET Core installer you can get it from thelatest Installers of .NET Core and .NET Core SDK.If you want one of our official releases, you can get the download from thedownload archive page.

Are you Here for Something Besides the Source Code?

In addition to providing the source code, this repository also acts as a useful nexus for thingsrelated to .NET Core including:

What Can you Make from this Repository?

.NET Core relies heavily on theNuGet package manager,which is a system to package, distribute and version software components. Seehttps://www.nuget.org/for more information on NuGet. For now it is enough to know NuGet is a system thatbundles components into*.nupkg files (which are ZIP archives) and these packages can be 'published'either through a local file system path or by a URL (e.g.https://www.nuget.org/). There are then tools(e.g. nuget.exe, Visual Studio, dotnet.exe) that based on a configuration file (.csproj) knowhow to search these publishing locations and pull down consistent set of packages for theapplication.

In concrete terms, this repository is best thought of as the source code for the following NuGet package:

  • Microsoft.NETCore.Runtime.CoreCLR - Represents the object allocator, garbage collector (GC), classloader, type system, interop and the most fundamental parts of the .NET class library (e.g.System.Object, System.String ...)

It also contains the source code for the following closely related support packages.

  • Microsoft.NETCore.Jit - The Just In Time (JIT) compiler for the.NET Intermediate language (IL)
  • Microsoft.NETCore.ILAsm - An assembler for the.NET Intermediate language (IL)
  • Microsoft.NETCore.ILDAsm - A disassembler (Pretty printer) for the.NET Intermediate language (IL)
  • Microsoft.NETCore.TestHost - This contains the corehost.exe program, which is a small wrapperthat uses the .NET Runtime to run IL DLLs passed to it on the command line.
  • Microsoft.TargetingPack.Private.CoreCLR - A set of assemblies that represent the compile time surfacearea of the class library implemented by the runtime itself.

Relationship with theCoreFX Repository

By itself, theMicrosoft.NETCore.Runtime.CoreCLR package is actually not enough to do much.One reason for this is that the CoreCLR package tries to minimize the amount of the class library that it implements.Only types that have a strong dependency on the internal workings of the runtime are included (e.g,System.Object,System.String,System.Threading.Thread,System.Threading.Tasks.Task and most foundational interfaces).Instead most of the class library is implemented as independent NuGet packages that simply use the .NET Coreruntime as a dependency. Many of the most familiar classes (System.Collections,System.IO,System.Xml andso on), live in packages defined in thedotnet/corefx repository.

But the main reason you can't do much with CoreCLR is thatALL of the types in the class libraryLOOKlike they are defined by the CoreFX framework and not CoreCLR. Any library code defined herelives in a single DLL calledSystem.Private.CoreLib.dll and as its name suggests is private (hidden).Instead for any particular PUBLIC type defined in CoreCLR, we found the 'right' package in CoreFX where it naturallybelongs and use that package as itspublic publishing point. That 'facade' package then forwards referencesto the (private) implementation inSystem.Private.CoreLib.dll defined here.For example theSystem.Runtime package defined in CoreFX declares the PUBLIC name for types likeSystem.Object andSystem.String. Thus from an applications point of view these types live inSystem.Runtime.dll.However,System.Runtime.dll (defined in the CoreFX repo) forwards references ultimately toSystem.Private.CoreLib.dllwhich is defined here.

Thus in order to run an application, you need BOTH theMicrosoft.NETCore.Runtime.CoreCLR NuGet package(defined in this repository) as well as packages for whatever you actually reference that were definedin the CoreFX repository (which at a minimum includes theSystem.Runtime package). You also need somesort of 'host' executable that loads the CoreCLR package as well as the CoreFX packages and starts your code (typicallyyou usedotnet.exe for this).

These extra pieces are not defined here, however you don't need to build them in order to use the CoreCLRNuGet package you create here. There are already versions of the CoreFX packages published onhttps://www.nuget.org/ so you can have your test application's project file specify the CoreCLR youbuilt and it will naturally pull anything else it needs from the official locationhttps://www.nuget.org/ tomake a complete application. More on this in theUsing Your Build page.


Setting up your GIT Clone of the CoreCLR Repository

The first step in making a build of the CoreCLR Repository is to clone it locally. If you already knowhow to do this, just skip this section. Otherwise if you are developing on Windows you can seeSetting Up A Git Repository In Visual Studio 2017for instructions on setting up. This link uses a different repository as an example, but the issues (do you fork or not) andthe procedure are equally applicable to this repository.


Building the Repository

The build depends on Git, CMake, Python and of course a C++ compiler. Once these prerequisites are installedthe build is simply a matter of invoking the 'build' script (build.cmd orbuild.sh) at the base of therepository.

The details of installing the components differ depending on the operating system. See the followingpages based on your OS. There is no cross-building across OS (only for ARM, which is built on X64).
You have to be on the particular platform to build that platform.

The build has two main 'buildTypes'

  • Debug (default)- This compiles the runtime with additional runtime checks (asserts). These checks slowruntime execution but are really valuable for debugging, and is recommended for normal development and testing.
  • Release - This compiles without any development time runtime checks. This is what end users will use butcan be difficult to debug. Pass 'release' to the build script to select this.

In addition, by default the build will not only create the runtime executables, but it will alsobuild all the tests. There are quite a few tests so this does take a significant amount of timethat is not necessary if you want to experiment with changes. You can skip buildingthe tests by passing the 'skiptests' argument to the build script.

Thus to get a build as quickly as possible type the following (using\ as the directory separator, use/ on Unix machines)

    .\build skiptests

which will build the Debug flavor which has development time checks (asserts), or

    .\build release skiptests

to build the release (full speed) flavor. You can find more build options with build by using the -? or -help qualifier.

Using Your Build

The build places all of its generated files under thebin directory at the base of the repository. Thereis abin\Log directory that contains log files generated during the build (most useful when the build fails).The actual output is placed in a directory like this

  • bin\Product\Windows_NT.x64.Release

There are two basic techniques for using your new runtime.

  1. Use dotnet.exe and NuGet to compose an application. SeeUsing Your Build forinstructions on creating a program that uses your new runtime by using the 'dotnet' command line interface.

  2. Use corerun.exe to run an application using unpackaged Dlls. This repository also defines a simple host calledcorerun.exe that does NOT take any dependency on NuGet. Basically it has to be told where to get all thenecessary DLLs you actually use, and you have to gather them together 'by hand'. This is the technique thatall the tests in the repo use, and is useful for quick local 'edit-compile-debug' loop (e.g. preliminary unit testing).SeeUsing corerun To Run .NET Core Application for details on usingthis technique.

Editing and Debugging

Typically users run through the build and use instructions first with an unmodified build, just to familiarizethemselves with the procedures and to confirm that the instructions work. After that you will want to actuallymake modifications and debug any issues those modifications might cause. See the following links for more.

Running Tests

After you have your modification basically working, and want to determine if you have broken anything it istime to run tests. SeeRunning .NET Core Tests for more.

Contributing to Repository

Looking for something to work on? The listofup-for-grabs issues is a great place to start.

Please read the following documents to get started.

This project has adopted the code of conduct defined by theContributor Covenantto clarify expected behavior in our community. For more information, see the.NET Foundation Code of Conduct.


Related Projects

As noted above, the CoreCLR Repository does not contain all the source code that makes up the .NET Core distribution.Here is a list of the other repositories that complete the picture.

  • dotnet/corefx - Source for the most common classes in the .NET Framework library.
  • dotnet/core-setup - Source code for the dotnet.exe program and the policy logicto launch basic .NET Core code (hostfxr, hostpolicy) which allow you to say 'dotnet SOME_CORE_CLR_DLL' to run the app.
  • dotnet/cli repo - Source for build time actions supported by dotnet.exe Command line Interface (CLI).Thus this is the code that runs when you do 'dotnet build', 'dotnet restore' or 'dotnet publish'.
  • dotnet/core-docs - Master copy of documentation forhttp://docs.microsoft.com/en-us/dotnet/

See Also

Important Blog Entries

License

.NET Core (including the coreclr repo) is licensed under theMIT license.

You can’t perform that action at this time.

[8]ページ先頭

©2009-2025 Movatter.jp