##Python
-Python is used in the build system. We are currently using python 2.7.9, althoughw
+Python is used in the build system. We are currently using python 2.7.9, although
any recent (2.4+) version of Python should work, including Python 3.
- Install [Python](https://www.python.org/downloads/) for Windows.
- Add its location (e.g. C:\Python*\) to the PATH environment variable.
--- /dev/null
+
+# Editing and Debugging
+
+If you are editing on the Windows Operating system, Using Visual Studio 2015 is a good option for editing
+the code in this repository. You can of course also use the editor of your choice. One further option
+is to use [VSCode](https://code.visualstudio.com/) which is a light weight, cross-platform tool that like
+Visual Studio, is optimized for development workflow (code editing and debugging) but works on more platforms
+(in particular OSX and Linux)
+
+[VSCode](https://code.visualstudio.com/) has built-in support for syntax highlighting and previewing
+markdown (`*.md`) files that GIT repositories like this one use for documentation. If you want to modify
+the docs, VSCode is a good choice. See [Markdown and VSCOde](https://code.visualstudio.com/Docs/languages/markdown)
+for more on VSCode support and [Mastering Markdown](https://guides.github.com/features/mastering-markdown/) for
+more on Markdown in general.
+
+# Visual Studio Solutions
+
+The repository has a number of Visual Studio Solutions files (`*.sln`) that are useful for editing parts of
+what are in the repository. In particular
+
+ * `src\mscorlib\System.Private.CorLib.sln` - This solution is for all managed (C#) code that is defined
+ in the runtime itself. This is all class library support of one form or another.
+ * `bin\obj\Windows_NT.<Arch>.<BuildType>\CoreCLR.sln` - this solution contains most native (C++) projects
+ associated with the repository, including
+ * `coreclr` - This is the main runtime DLL (the GC, class loader, interop are all here)
+ * `corjit` - This is the Just In Time (JIT) compiler that compiles .NET Intermediate language to native code.
+ * `corerun` - This is the simple host program that can load the CLR and run a .NET Core application
+ * `crossgen` - This is the host program that runs the JIT compiler and produces .NET Native images (`*.ni.dll`)
+ for C# code.
+
+Thus opening one of these two solution files (double clicking on them in Explorer) is typically all you need
+to do most editing.
+
+Notice that the CoreCLR solution is under the 'bin' directory. This is because it is created as part of the build.
+Thus you can only launch this solution after you have built at least once.
+
+* See [Debugging](../building/debugging-instructions.md)
+
+### Interacting with GIT in Visual Studio
+
+Most interactions with GIT can be done from within Visual Studio. See the following for more details.
+* [Setting up with a fork with Visual Studio 2015](https://github.com/Microsoft/perfview/blob/master/documentation/OpenSourceGitWorkflow.md)
+
+# See Also
+
+Before you make modifications, you probably want to learn more about the general architecture of .NET Core.
+See the following docs for more.
+
+ * [Documentation on the .NET Core Runtime](../README.md)
```bat
%HOMEPATH%\.nuget\packages\Microsoft.NETCore.Runtime.CoreCLR\1.2.0-beta-24521-02
```
-which should mke things work (but is fragile, confirm wile file timestamps that you are getting the version you expect)
+which should make things work (but is fragile, confirm wile file timestamps that you are getting the version you expect)
-## Step 8.1 Quick updates in place.
+## Step 8.1 (Optional) Quick updates in place.
The 'dotnet publish' step in step 6 above creates a directory that has all the files necessary to run your app
including the CoreCLR and the parts of CoreFX that were needed. You can use this fact to skip some steps if
you wish to update the DLLs. For example typically when you update CoreCLR you end up updating one of two DLLs
-* Coreclr.dll - Most modifications (with the exception of the JIT compiler and tools) that are C++ code update
+* coreclr.dll - Most modifications (with the exception of the JIT compiler and tools) that are C++ code update
this DLL.
* System.Private.CoreLib.dll - If you modified C# it will end up here.
* System.Private.CoreLib.ni.dll - the native image (code) for System.Private.Corelib. If you modify C# code
-you will want to update both of these together in the target installation.
+you will want to update both of these together in the target installation.
Thus after making a change and building, you can simply copy the updated binary from the `bin\Product\<OS>.<arch>.<flavor>`
directory to your publication directory (e.g. `helloWorld\bin\Debug\netcoreapp1.0\win7-x64\publish`) to quickly
-deploy your new bits.
-
+deploy your new bits. You can build just the .NET Library part of the build by doing (debug, for release add 'release qualifier)
+(on Linux / OSX us ./build.sh)
+```bat
+ .\build skiptests skipnative
+```
+Which builds System.Private.CoreLib.dll AND System.Private.CoreLib.ni.dll (you will always want both) if you modify
+C# code. If you wish to only compile the coreclr.dll you can do
+ ```bat
+ .\build skiptests skipmscorlib
+```
+Note that this technique does not work on .NET Apps that have not been published (that is you have not created
+a directory with all DLLs needed to run the all) That is because the runtime is either fetched from the system-wide
+location that dotnet.exe installed, OR it is fetched from the local nuget package cache (which is where your
+build was put when you did a 'dotnet restore' and had a dependency on your particular runtime). In theory you
+could update these locations in place, but that is not recommended since they are shared more widely.
### Using your Runtime For Real.
* Need to **log a issue** or Provide Feedback? See then [Issues and Feedback Page](Documentation/workflow/IssuesFeedbackEngagement.md) page.
* Want to **chat** with other members of the CoreCLR community? See the [Chat Section](Documentation/workflow/IssuesFeedbackEngagement.md#Chat-with-the-CoreCLR-community) page.
* Need a **current build** or **test results** of the CoreCLR repository? See the [Official and Daily Builds](Documentation/workflow/OfficalAndDailyBuilds.md) page.
+ * If you want powerful search of the source code for both CoreClr and CoreFx see [.NET Source Code Index](https://source.dot.net)
## What Can you Make from this Repository?
See [Executing .NET Core Apps with CoreRun.exe](Documentation/workflow/UsingCoreRun.md) for details on using
this technique.
+## Editing and Debugging
+
+Typically users run through the build and use instructions first with an unmodified build, just to familiarize
+themselves with the procedures and to confirm that the instructions work. After that you will want to actually
+make modifications and debug any issues those modifications might cause. See the following links for more.
+
+ * [Editing and Debugging](Documentation/workflow/EditingAndDebugging.md) and
+ * [Documentation on the .NET Core Runtime](Documentation/README.md)
+
## Running Tests
After you have your modification basically working, and want to determine if you have broken anything it is
@if not defined _echo @echo off
setlocal EnableDelayedExpansion EnableExtensions
+echo Starting Build at %TIME%
set __ThisScriptFull="%~f0"
set __VSToolsRoot=%VS140COMNTOOLS%
:: Note that the msbuild project files (specifically, dir.proj) will use the following variables, if set:
REM ===
REM =========================================================================================
-echo %__MsgPrefix%Repo successfully built.
+echo %__MsgPrefix%Repo successfully built. Finished at %TIME%
echo %__MsgPrefix%Product binaries are available at !__BinDir!
if %__BuildTests% EQU 1 (
echo %__MsgPrefix%Test binaries are available at !__TestBinDir!
projects / platform / upstream / coreclr.git / commitdiff