diff options
| author | Richard Lander <rlander@microsoft.com> | 2015-06-01 21:33:41 -0700 |
|---|---|---|
| committer | Richard Lander <rlander@microsoft.com> | 2015-06-01 21:40:54 -0700 |
| commit | 01cf43dfe666aa09b430ce72762e71e6da5f23e4 (patch) | |
| tree | d4e33890382aecdefd5c30bbce1a4365a5ce45c9 | |
| parent | 2ff687cd797c2d7304673ebcf4c7f630eefbcd81 (diff) | |
| download | coreclr-01cf43dfe666aa09b430ce72762e71e6da5f23e4.tar.gz coreclr-01cf43dfe666aa09b430ce72762e71e6da5f23e4.tar.bz2 coreclr-01cf43dfe666aa09b430ce72762e71e6da5f23e4.zip | |
Re-work wiki as Repo docs
29 files changed, 367 insertions, 204 deletions
diff --git a/Developer-Guide.md b/Developer-Guide.md deleted file mode 100644 index c0e0a7ce76..0000000000 --- a/Developer-Guide.md +++ /dev/null @@ -1,52 +0,0 @@ -Intro to CoreCLR -================ - -CoreCLR is a self-contained .NET runtime that implements [ECMA 335](https://github.com/dotnet/coreclr/blob/master/Documentation/dotnet-standards.md). It is can be ported to multiple architectures and/or platforms. It support a variety of installation options, having no specific deployment requirements itself. - -Project Goals and Priorities -============================ - -Microsoft published CoreCLR to GitHub, with the following goals: - -- Establish a high-quality open source .NET implementation, with [CoreCLR](https://github.com/dotnet/coreclr) and [CoreFX](https://github.com/dotnet/corefx). -- Port CoreCLR to Linux and OS X (already supported on Windows). -- Support the community extending CoreCLR in various ways (e.g. [FreeBSD support](https://github.com/dotnet/coreclr/issues/455)). - -The project has the following priorities, set by the .NET Team: - -- x64 is the priority chip to support. x86 and ARM32 will follow. -- Windows, Linux and OS X support have the same priority. -- Porting is a higher priority (at this time) than new features. - -Contributing -============ - -Please read [Contributing](https://github.com/dotnet/coreclr/wiki/Contributing) to .NET Core before making your first contribution. - -Building the repository -======================= - -The CoreCLR repo can be built from a regular, non-admin command prompt. The build produces CoreCLR (multiple native binaries), the mscorlib managed library and the accompanying tests. The repo can be built for the following platforms, using the provided instructions. - -| Chip | Windows | Linux | OS X | -| :---- | :-----: | :---: | :--: | -| x64 | ●| ◒| ◒ | -| x86 | ◯| ◯| ◯| -| ARM32 | ◯ | ◯| ◯ | -| | [Instructions][Windows-instructions] | [Instructions][Linux-instructions] | [Instructions][OSX-instructions] | - -[Windows-instructions]: https://github.com/dotnet/coreclr/blob/master/Documentation/windows-instructions.md -[Linux-instructions]: https://github.com/dotnet/coreclr/blob/master/Documentation/linux-instructions.md -[OSX-instructions]: https://github.com/dotnet/coreclr/blob/master/Documentation/osx-instructions.md - -The CoreCLR build and test suite is a work in progress, as are the [building and testing instructions](https://github.com/dotnet/coreclr/blob/master/Documentation/README.md#product-instructions). The .NET Core team and the community are improving Linux and OS X support on a daily basis are and adding more tests for all platforms. See [CoreCLR Issues](https://github.com/dotnet/coreclr/issues) to find out about specific work items or report issues. - -Understanding the TFS-Git Mirror -================================ - -The Microsoft team maintains a Microsoft-internal TFS server of CoreCLR. An automated system is used to flow changes in/out of GitHub. The mirroring infrastructure uses the following hint files to mirror a given TFS folder into GitHub and back: - -1. `.gitmirror` - any folder containing this file will **only** have its contained files mirrored. Subfolders are **not** mirrored. -2. `.gitmirrorall` - any folder containing this file will have all of its files **and** subfolders mirrored recursively. The subfolders do not need to have any hint files. - -Thus, if you add a new folder to be included as part of the CoreCLR build, it will also need to have one of the two hint files mentioned above.
\ No newline at end of file diff --git a/Documentation/README.md b/Documentation/README.md index e31fd87c24..2e7a1c1737 100644 --- a/Documentation/README.md +++ b/Documentation/README.md @@ -3,6 +3,12 @@ Documents Index This repo includes several documents that explain both high-level and low-level concepts about the .NET runtime. These are very useful for contributors, to get context that can be very difficult to acquire from just reading code. +Learn about .NET Core +==================== + +- [Brief Intro to .NET Core](dotnetcore-intro.md) +- [[WIP] Official .NET Core Docs](http://dotnet.readthedocs.org) + Get .NET Core ============= @@ -11,6 +17,23 @@ Get .NET Core - [Get .NET Core DNX SDK on Linux](get-dotnetcore-dnx-linux.md) - [Get .NET Core (Raw) on Windows](get-dotnetcore-windows.md) +Project Docs +============ + +- [Developer Guide](developer-guide.md) +- [Project priorities](project-priorities.md) +- [Contributing to .NET Core](contributing.md) +- [Contributing Workflow](contributing-workflow.md) +- [Performance Guidelines](performance-guidelines.md) +- [Garbage Collector Guidelines](garbage-collector-guidelines.md) + +Coding Guidelines +================= + +- [CLR Coding Guide](clr-code-guide.md) +- [CLR JIT Coding Conventions](clr_jit_coding_conventions.md) +- [Cross Platform Performance and Eventing Design](cross-platform-performance-and-eventing.md) + Build CoreCLR from Source ========================= @@ -18,8 +41,9 @@ Build CoreCLR from Source - [Building CoreCLR on Linux](linux-instructions.md) - [Building CoreCLR on OS X](osx-instructions.md) - [Building CoreCLR on Windows](windows-instructions.md) -- [Debugging CoreCLR](debugging-instructions.md) -- [Testing CoreCLR Changes](test-instructions.md) +- [Debugging CoreCLR on Windows](windows-debugging-instructions.md) +- [Testing Changes on Windows](windows-test-instructions.md) +- [Testing with CoreFX](testing-with-corefx.md) - [Creating a Custom DNX](custom-dnx-instructions.md) Book of the Runtime @@ -41,17 +65,6 @@ Book of the Runtime - [Implementing Profilability](profilability.md) - [What Every Dev needs to Know About Exceptions in the Runtime](exceptions.md) -.NET Runtime Specs -================== - -- [CLR Coding Guide](clr-code-guide.md) -- [.NET Standards (Ecma)](dotnet-standards.md) -- [Cross Platform Performance and Eventing Design](cross-platform-performance-and-eventing.md) - -RyuJIT Specs -============= -- [CLR JIT Coding Conventions](CLR_JIT_Coding_Conventions.md) - Decoder Rings ============= @@ -61,6 +74,9 @@ Decoder Rings Other Information ================= +- [CoreFX Repo documentation](https://github.com/dotnet/corefx/tree/master/Documentation) +- [Porting to .NET Core](https://github.com/dotnet/corefx/blob/master/Documentation/support-dotnet-core-instructions.md) +- [.NET Standards (Ecma)](dotnet-standards.md) - [CLR Configuration Knobs](clr-configuration-knobs.md) - [MSDN Entry for the CLR](http://msdn.microsoft.com/library/8bs2ecf4.aspx) - [Wikipedia Entry for the CLR](http://en.wikipedia.org/wiki/Common_Language_Runtime) diff --git a/Documentation/contributing-workflow.md b/Documentation/contributing-workflow.md new file mode 100644 index 0000000000..aabc6f5c00 --- /dev/null +++ b/Documentation/contributing-workflow.md @@ -0,0 +1,106 @@ +Contribution Workflow +===================== + +You can contribute to .NET Core with issues and PRs. Simply filing issues for problems you encounter is a great way to contribute. Contributing implementations is greatly appreciated. + +Getting Started +=============== + +If you are looking at getting your feet wet with some simple (but still beneficial) changes, check out _up for grabs_ issues on the [CoreCLR](https://github.com/dotnet/coreclr/labels/up for grabs) and [CoreFX](https://github.com/dotnet/corefx/labels/up for grabs) repos. + +For new ideas, please always start with an issue before starting development of an implementation. See [project priorities](project-priorities.md) to understand the Microsoft team's approach to engagement on general improvements to the product. + +You do not need to file an issue for trivial changes (e.g. typo fixes). Just create a PR for those changes. + +Making a change +=============== + +Make a quality change. Consider and document (preferably with tests) as many usage scenarios as you can to ensure that your change will work correctly in the miriad of ways it might get used. + +There are several issues to keep in mind when making a change. + +Managed Code Compatibility +-------------------------- +Please review [Breaking Changes](https://github.com/dotnet/corefx/blob/master/Documentation/breaking-changes.md) before making changes to managed code. Please pay the most attention to changes that affect the [Public Contract](https://github.com/dotnet/corefx/blob/master/Documentation/breaking-changes.md#bucket-1-public-contract). + +Typos +----- +Typos are embarrassing! We will accept most PRs that fix typos. In order to make it easier to review your PR, please focus on a given component with your fixes or on one type of typo across the entire repository. If it's going to take >30 mins to review your PR, then we will probably ask you to chunk it up. + +Coding Style Changes +-------------------- + +We intend to bring dotnet/corefx in to full conformance with the style guidelines described in [Coding Style](https://github.com/dotnet/corefx/blob/master/Documentation/coding-style.md). We plan to do that with tooling, in a holistic way. In the meantime, please: + +* **DO NOT** send PRs for style changes. +* **DO** give priority to the current style of the project or file you're changing even if it diverges from the general guidelines. + +Commit Messages +--------------- + +Please format commit messages as follows (based on this [excellent post](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)): + +``` +Summarize change in 50 characters or less + +Provide more detail after the first line. Leave one blank line below the +summary and wrap all lines at 72 characters or less. + +If the change fixes an issue, leave another blank line after the final +paragraph and indicate which issue is fixed in the specific format +below. + +Fix #42 +``` + +Also do your best to factor commits appropriately, i.e not too large with unrelated +things in the same commit, and not too small with the same small change applied N +times in N different commits. If there was some accidental reformatting or whitespace +changes during the course of your commits, please rebase them away before submitting +the PR. + +PR - CI Process +=============== + +The [dotnet continuous integration](http://dotnet-ci.cloudapp.net/) (CI) system will automatically perform the required builds and run tests (including the ones you are expected to run) for PRs. Builds and test runs must be clean. + +If the CI build fails for any reason, the PR issue will be updated with a link that can be used to determine the cause of the failure. + +There is currently minimal test coverage for Linux and OS X builds that can be used by the dotnet CI. We are working to improve that so that more issues can be caught in CI, as is the case with Windows. + +PR Feedback +=========== + +Microsoft team and community members will provide feedback on your change. Community feedback is highly valued. You will often see the absence of team feedback if the community has already provided good review feedback. + +1 or more Microsoft team members will review every PR prior to merge. They will often reply with "LGTM, modulo comments". That means that the PR will be merged once the feedback is resolved. "LGTM" == "looks good to me". + +There are lots of thoughts and [approaches](https://github.com/antlr/antlr4-cpp/blob/master/CONTRIBUTING.md#emoji) for how to efficiently discuss changes. It is best to be clear and explicit with your feedback. Please be patient with people who might not understand the finer details about your approach to feedback. + +Suggested Workflow +================== + +We use and recommend the following workflow: + +1. Create an issue for your work. + - You can skip this step for trivial changes. + - Reuse an existing issue on the topic, if there is one. + - Get agreement from the team and the community that your proposed change is a good one. + - If your change adds a new API, follow the [API Review Process](https://github.com/dotnet/corefx/blob/master/Documentation/api-review-process.md). + - Clearly state that you are going to take on implementing it, if that's the case. You can request that the issue be assigned to you. Note: The issue filer and the implementer don't have to be the same person. +2. Create a personal fork of the repository on GitHub (if you don't already have one). +3. Create a branch off of master (`git checkout -b mybranch`). + - Name the branch so that it clearly communicates your intentions, such as issue-123 or githubhandle-issue. + - Branches are useful since they isolate your changes from incoming changes from upstream. They also enable you to create multiple PRs from the same fork. +4. Make and commit your changes. + - Please following our commit messages guidance, below. +5. Add new tests corresponding to your change, if applicable. +6. Build the repository with your changes. + - Make sure that the builds are clean. + - Make sure that the tests are all passing, including your new tests. +7. Create a pull request (PR) against the upstream repository's **master** branch. + - Push your changes to your fork on GitHub (if you haven't already). + +Note: It is OK for your PR to include a large number of commits. Once your change is accepted, you will be asked to squash your commits into one or some appropriately small number of commits before your PR is merged. + +Note: It is OK to create your PR as "[WIP]" on the upstream repo before the implementation is done. This can be useful if you'd like to start the feedback process concurrent with your implementation. State that this is the case in the initial PR comment. diff --git a/Documentation/contributing.md b/Documentation/contributing.md new file mode 100644 index 0000000000..34b67c1859 --- /dev/null +++ b/Documentation/contributing.md @@ -0,0 +1,110 @@ +Contributing to .NET Core +========================= + +The .NET Core team maintains several guidelines for contributing to the .NET Core repos, which are provided below. Many of these are straightforward, while others may seem subjective. A .NET Core team member will be happy to explain why a guideline is defined as it is. + +Contribution Guidelines +======================= + +- [Contribution Bar](#contribution-bar) describes the bar that the team uses to accept changes. +- [Contributing Ports](#contributing-ports) describes the slightly different bar for contributing changes that enable .NET Core to run on other OSes and chips. +- [Mscorlib Contributions](#contributing-to-mscorlib-library) describes contributing to the mscorlib library. +- [General Contribution Guidance](#general-contribution-guidance) describes general contribution guidance, including more subjective stylistic guidelines. +- [DOs and DON'Ts](#dos-and-donts) provides a partial checklist summary of contributing guidelines, in classic framework guidlines do/don't style. +- [Contributor License Agreement (CLA)](#contributor-license-agreement) describes the requirement and process of signing a Contributor License Agreement (CLA). +- [Contribution Workflow](contributing-workflow.md) describes the workflow that the team uses for considering and accepting changes. +- [Garbage Collection Guidelines](garbage-collector-guidelines.md) for changes that affect the GC. +- [Performance Guidelines](performance-guidelines.md) for changes in performance critical code or that otherwise affect performance. + +Contribution "Bar" +================== + +Project maintainers will merge changes that align with [project priorities](project-priorities.md) and/or improve the product significantly for a broad set of apps. Proposed must also satisfy the published [guidelines for .NET Core](#contribution-guidelines). + +Maintainers will not merge changes that have narrowly-defined benefits, due to compatibility risk. The CoreCLR codebase is used by several Microsoft products (e.g. Windows Phone, ASP.NET 5, .NET Framework 4.6) to enable execution of managed code. Changes to the open source codebase can become part of these products, but are first reviewed and tested to ensure they are correct for those products and will not inadvertently break applications. We may revert changes if they are found to be breaking. + +Contributing Ports +================== + +We encourage ports of CoreCLR to other platforms. Linux and OS X ports are in progress and have a lot of momentum behind them. There is also interest in a [FreeBSD port](https://github.com/dotnet/coreclr/issues/455) (and OpenBSD and NetBSD). + +Ports have a weaker contribution bar, since they do not contribute to compatibility risk with existing Microsoft products on Windows. For ports, we are primarily looking for functionaly correct implementations. + +Contributing to mscorlib library +================================ + +Most managed code changes should be made in the [CoreFX](https://github.com/dotnet/corefx) repo. We have moved and are continuing to move many mscorlib types to CoreFX. Please use the following general rule-of-thumb for choosing the right repo to make your change (start by creating an issue): + +- The type or concept doesn't yet exist in .NET Core -> choose CoreFX. +- The type exists in both CoreCLR and CoreFX repo -> choose CoreFX. +- The type exists in CoreCLR only -> choose CoreCLR. +- In doubt -> choose CoreFX. + +Please see [Breaking Changes](https://github.com/dotnet/corefx/blob/master/Documentation/breaking-changes.md) to understand our requirements on changes that could impact compatibility. Please pay the most attention to changes that affect the [Public Contract](https://github.com/dotnet/corefx/blob/master/Documentation/breaking-changes.md#bucket-1-public-contract). We will not accept changes that break compatibility. + +General Contribution Guidance +============================= + +There are several issues to keep in mind when making a change. + +Managed Code Compatibility +-------------------------- +Please review [Breaking Changes](https://github.com/dotnet/corefx/blob/master/Documentation/breaking-changes.md) before making changes to managed code. Please pay the most attention to changes that affect the [Public Contract](https://github.com/dotnet/corefx/blob/master/Documentation/breaking-changes.md#bucket-1-public-contract). + +Typos +----- +Typos are embarrassing! We will accept most PRs that fix typos. In order to make it easier to review your PR, please focus on a given component with your fixes or on one type of typo across the entire repository. If it's going to take >30 mins to review your PR, then we will probably ask you to chunk it up. + +Commit Messages +--------------- + +Please format commit messages as follows (based on this [excellent post](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)): + +``` +Summarize change in 50 characters or less + +Provide more detail after the first line. Leave one blank line below the +summary and wrap all lines at 72 characters or less. + +If the change fixes an issue, leave another blank line after the final +paragraph and indicate which issue is fixed in the specific format +below. + +Fix #42 +``` + +Also do your best to factor commits appropriately, i.e not too large with unrelated +things in the same commit, and not too small with the same small change applied N +times in N different commits. If there was some accidental reformatting or whitespace +changes during the course of your commits, please rebase them away before submitting +the PR. + +DOs and DON'Ts +============== + +* **DO** follow our [coding style](https://github.com/dotnet/corefx/blob/master/Documentation/coding-style.md) (C# code-specific) +* **DO** give priority to the current style of the project or file you're changing even if it diverges from the general guidelines. +* **DO** include tests when adding new features. When fixing bugs, start with + adding a test that highlights how the current behavior is broken. +* **DO** keep the discussions focused. When a new or related topic comes up + it's often better to create new issue than to side track the discussion. +* **DO** blog and tweet (or whatever) about your contributions, frequently! + +* **DO NOT** send PRs for style changes. +* **DON'T** surprise us with big pull requests. Instead, file an issue and start + a discussion so we can agree on a direction before you invest a large amount + of time. +* **DON'T** commit code that you didn't write. If you find code that you think is a good fit to add to .NET Core, file an issue and start a discussion before proceeding. +* **DON'T** submit PRs that alter licensing related files or headers. If you believe there's a problem with them, file an issue and we'll be happy to discuss it. +* **DON'T** add API additions without filing an issue and discussing with us first. See [API Review Process](https://github.com/dotnet/corefx/blob/master/Documentation/api-review-process.md). + +Contributor License Agreement +============================= + +You must sign a [.NET Foundation Contribution License Agreement (CLA)](http://cla2.dotnetfoundation.org) before your PR will be merged. This a one-time requirement for projects in the .NET Foundation. You can read more about [Contribution License Agreements (CLA)](http://en.wikipedia.org/wiki/Contributor_License_Agreement) on wikipedia. + +However, you don't have to do this up-front. You can simply clone, fork, and submit your pull-request as usual. + +When your pull-request is created, it is classified by a CLA bot. If the change is trivial, i.e. you just fixed a typo, then the PR is labelled with `cla-not-required`. Otherwise it's classified as `cla-required`. In that case, the system will also also tell you how you can sign the CLA. Once you signed a CLA, the current and all future pull-requests will be labelled as `cla-signed`. + +Signing the CLA might sound scary but it's actually super simple and can be done in less than a minute. diff --git a/Documentation/cross-platform-performance-and-eventing.md b/Documentation/cross-platform-performance-and-eventing.md index d77aafda3f..f55da62df9 100644 --- a/Documentation/cross-platform-performance-and-eventing.md +++ b/Documentation/cross-platform-performance-and-eventing.md @@ -285,4 +285,4 @@ We expect that the following assumptions will hold for the majority of developer - Enable Linux traces to be analyzed using PerfView / TraceEvent on Windows. - Evaluate options for viewing Linux traces on OS X. -- Enable more advanced performance data collection for runtime components on OS X via CLR in-box events and EventSource.
\ No newline at end of file +- Enable more advanced performance data collection for runtime components on OS X via CLR in-box events and EventSource. diff --git a/Documentation/custom-dnx-instructions.md b/Documentation/custom-dnx-instructions.md index 888f13dbd9..3cfd7904ef 100644 --- a/Documentation/custom-dnx-instructions.md +++ b/Documentation/custom-dnx-instructions.md @@ -3,7 +3,7 @@ Creating a Custom DNX These instructions will lead you through creating a custom [DNX](https://github.com/aspnet/dnx) using an official DNX and the results of CoreCLR build. The same approach can be be used with the CoreFX build; however, that part isn't explored with these instructions. CoreFX is a bit harder, too, since you need to worry more about dependencies. -These instructions are specific to Windows and assume that you've just completed the [Windows installation instructions](https://github.com/dotnet/coreclr/wiki/Windows-instructions). They use the same demo `C:\coreclr-demo` directory and assume the same artifacts. The same general idea will work on OS X and Linux once .NET Core is supported more broadly on those OSes. +These instructions are specific to Windows and assume that you've just completed the [Windows installation instructions](windows-instructions.md). They use the same demo `C:\coreclr-demo` directory and assume the same artifacts. The same general idea will work on OS X and Linux once .NET Core is supported more broadly on those OSes. Introduction to DNX =================== @@ -54,7 +54,7 @@ Both commands will install a default DNX, which on Windows, is x86 and hosted on Trying out DNX ============== -As stated above, these instructions assume that you've just completed the [Windows installation instructions](https://github.com/dotnet/coreclr/wiki/Windows-instructions), which included a "Hello World" demo. +As stated above, these instructions assume that you've just completed the [Windows installation instructions](windows-instructions.md), which included a "Hello World" demo. You need one extra file for the demo to work, which is project.json. Add it beside HelloWorld.cs. @@ -159,4 +159,4 @@ You should re-generate crossgen images for your DNX to provide the best performa You should now have a working custom CoreCLR x64 DNX. Give it a try. - C:\coreclr-demo>dnx . run
\ No newline at end of file + C:\coreclr-demo>dnx . run diff --git a/Documentation/dac-notes.md b/Documentation/dac-notes.md index 5596eab196..0a1a804fb3 100644 --- a/Documentation/dac-notes.md +++ b/Documentation/dac-notes.md @@ -210,4 +210,4 @@ Whenever you add a new feature, you will need to consider its debuggability need DACizing ensures that code in the engine will work correctly with the DAC. It is important to use the DAC correctly to marshal values from the target to the host. Target addresses used incorrectly from the host (or vice versa) may reference unmapped addresses. If addresses are mapped, the values will be completely unrelated to the values expected. As a result, DACizing mostly involves ensuring that we use PTR types for all values that the DAC needs to marshal. Another major task is to ensure that we do not allow invasive code to execute in DAC builds. In practice, this means that we must sometimes refactor code or add DACCESS\_COMPILE preprocessor directives. We also want to be sure that we add the appropriate SUPPORTS\_DAC contract. The use of this contract signals to developers that the function works with the DAC. This is important for two reasons: 1. If we later call it from some other SUPPORTS\_DAC function, we know that it is DAC-safe and we don't need to worry about DACizing it. -2. If we make modifications to the function, we need to make sure that they are DAC-safe. If we add a call to another function from this one, we also need to ensure that it is DAC-safe or that we only make the call in non-DAC builds.
\ No newline at end of file +2. If we make modifications to the function, we need to make sure that they are DAC-safe. If we add a call to another function from this one, we also need to ensure that it is DAC-safe or that we only make the call in non-DAC builds. diff --git a/Documentation/developer-guide.md b/Documentation/developer-guide.md new file mode 100644 index 0000000000..c35236d0a9 --- /dev/null +++ b/Documentation/developer-guide.md @@ -0,0 +1,28 @@ +Developer Guide +=============== + +This guide provides instructions (mostly as links) on how to build the repo and implement improvements. It will expand over time. + +Building the repository +======================= + +The CoreCLR repo can be built from a regular, non-admin command prompt. The build produces CoreCLR (multiple native binaries), the mscorlib managed library and the accompanying tests. The repo can be built for the following platforms, using the provided instructions. + +| Chip | Windows | Linux | OS X | +| :---- | :-----: | :---: | :--: | +| x64 | ●| ◒| ◒ | +| x86 | ◯| ◯| ◯| +| ARM32 | ◯ | ◯| ◯ | +| | [Instructions](windows-instructions.md) | [Instructions](linux-instructions.md) | [Instructions](osx-instructions.md) | + +The CoreCLR build and test suite is a work in progress, as are the [building and testing instructions](README.md). The .NET Core team and the community are improving Linux and OS X support on a daily basis are and adding more tests for all platforms. See [CoreCLR Issues](https://github.com/dotnet/coreclr/issues) to find out about specific work items or report issues. + +Understanding the TFS-Git Mirror +================================ + +The Microsoft team maintains a Microsoft-internal TFS server of CoreCLR. An automated system is used to flow changes in/out of GitHub. The mirroring infrastructure uses the following hint files to mirror a given TFS folder into GitHub and back: + +1. `.gitmirror` - any folder containing this file will **only** have its contained files mirrored. Subfolders are **not** mirrored. +2. `.gitmirrorall` - any folder containing this file will have all of its files **and** subfolders mirrored recursively. The subfolders do not need to have any hint files. + +Thus, if you add a new folder to be included as part of the CoreCLR build, it will also need to have one of the two hint files mentioned above. diff --git a/Documentation/dotnet-standards.md b/Documentation/dotnet-standards.md index a1ab94ac7a..452c703f0a 100644 --- a/Documentation/dotnet-standards.md +++ b/Documentation/dotnet-standards.md @@ -66,4 +66,4 @@ Shared Source CLI (SSCLI) - [Wikipedia entry on SSCLI](http://en.wikipedia.org/wiki/Shared_Source_Common_Language_Infrastructure) - [The Microsoft Shared Source CLI Implementation](https://msdn.microsoft.com/library/ms973879.aspx) - [Shared Source Common Language Infrastructure 2.0 Release ](http://www.microsoft.com/en-us/download/details.aspx?id=4917) -- [Shared Source CLI 2.0 Infrastructure 2.0 Release - 3rd party provided on GitHub](https://github.com/gbarnett/shared-source-cli-2.0)
\ No newline at end of file +- [Shared Source CLI 2.0 Infrastructure 2.0 Release - 3rd party provided on GitHub](https://github.com/gbarnett/shared-source-cli-2.0) diff --git a/Documentation/dotnetcore-intro.md b/Documentation/dotnetcore-intro.md new file mode 100644 index 0000000000..31b1575f8c --- /dev/null +++ b/Documentation/dotnetcore-intro.md @@ -0,0 +1,4 @@ +Intro to .NET Core +================== + +.NET Core is a self-contained .NET runtime and framework that implements [ECMA 335](dotnet-standards.md). It can be (and has been) ported to multiple architectures and platforms. It support a variety of installation options, having no specific deployment requirements itself. diff --git a/Documentation/exceptions.md b/Documentation/exceptions.md index 560d2571e0..daa684bf8b 100644 --- a/Documentation/exceptions.md +++ b/Documentation/exceptions.md @@ -296,4 +296,4 @@ Miscellaneous There are actually a lot of macros involved in EX_TRY. Most of them should never, ever, be used outside of the macro implementations. -One set, BEGIN_EXCEPTION_GLUE / END_EXCEPTION_GLUE, deserves special mention. These were intended to be transitional macros, and were to be replaced with more appropriate macros in the Whidbey project. Of course, they worked just fine, and so they weren't all replaced. Ideally, all instances will be converted during a "cleanup" milestone, and the macros removed. In the meantime, any CLR dev tempted to use them should resist, and instead write EX_TRY/EX_CATCH/EX_CATCH_END or EX_CATCH_HRESULT.
\ No newline at end of file +One set, BEGIN_EXCEPTION_GLUE / END_EXCEPTION_GLUE, deserves special mention. These were intended to be transitional macros, and were to be replaced with more appropriate macros in the Whidbey project. Of course, they worked just fine, and so they weren't all replaced. Ideally, all instances will be converted during a "cleanup" milestone, and the macros removed. In the meantime, any CLR dev tempted to use them should resist, and instead write EX_TRY/EX_CATCH/EX_CATCH_END or EX_CATCH_HRESULT. diff --git a/Garbage-Collector-Contributions.md b/Documentation/garbage-collector-guidelines.md index 5301a05e68..66d4c69b9f 100644 --- a/Garbage-Collector-Contributions.md +++ b/Documentation/garbage-collector-guidelines.md @@ -1,4 +1,5 @@ -# Introduction # +Garbage Collector Requirements +============================== The garbage collector is an integral part of the .NET runtime. Changes to the .NET runtime can have significant effects on program correctness and performance. As such, GC has strong implementation and testing requirements. @@ -33,4 +34,4 @@ A functional test run executes the same code as a stress run, but only runs for Instructions for running stress are located in the repo at tests\src\GC\Stress\stress_run_readme.txt. ## Performance Testing ## -Coming soon.
\ No newline at end of file +Coming soon. diff --git a/Documentation/jit-testing.md b/Documentation/jit-testing.md index df9b69d01a..63c6a63dd9 100644 --- a/Documentation/jit-testing.md +++ b/Documentation/jit-testing.md @@ -167,6 +167,3 @@ register allocation stress, volatile stress, randomized block layout, etc. ### Bring up custom testing frameworks and tools. We should invest in things like random program or IL generation tools. - - - diff --git a/Documentation/method-descriptor.md b/Documentation/method-descriptor.md index 91bcb49e01..0e1bca096b 100644 --- a/Documentation/method-descriptor.md +++ b/Documentation/method-descriptor.md @@ -339,4 +339,3 @@ NDirectImportPrecode looks like this on x86: mov eax,pMethodDesc mov eax,eax // dummy instruction that marks the type of the precode jmp NDirectImportThunk // loads P/Invoke target for pMethodDesc lazily - diff --git a/Performance-Requirements.md b/Documentation/performance-guidelines.md index bc1e42d433..addaa3fe8f 100644 --- a/Performance-Requirements.md +++ b/Documentation/performance-guidelines.md @@ -1,7 +1,9 @@ -# Introduction # +Performance Requirements +======================== + The .NET runtime supports a wide variety of high performance applications. As such, performance is a key design element for every change. This guidance is designed to share how we collect data and analyze the performance of the runtime. -CoreFX performance guidance is available [here](https://github.com/dotnet/corefx/wiki/Performance). +You may also want to read about [CoreFX performance guidelines](https://github.com/dotnet/corefx/blob/master/Documentation/performance-guidelines.md). # Design Phase # Make sure to address performance during the design phase of any change. It is much easier to tweak a design to fit performance goals and requirements before implementation has started. @@ -49,4 +51,4 @@ Capturing a trace using PerfView will allow you to: PerfView is available at the [Microsoft Download Center](http://www.microsoft.com/en-us/download/details.aspx?id=28567 "Microsoft Download Center"). The help documentation is quite substantial and can help you get started. Clicking the blue links throughout PerfView's UI will also take you to the appropriate help topic. It is also recommended that you watch the [PerfView Tutorial Videos](http://channel9.msdn.com/Series/PerfView-Tutorial). # Additional Help # -If you have questions, run into any issues, or would like help with any performance related topics, please feel free to post a question. Someone from the .NET performance team will be happy to help.
\ No newline at end of file +If you have questions, run into any issues, or would like help with any performance related topics, please feel free to post a question. Someone from the .NET performance team will be happy to help. diff --git a/Documentation/profilability.md b/Documentation/profilability.md index 2c5bf79bcf..528c3f1e07 100644 --- a/Documentation/profilability.md +++ b/Documentation/profilability.md @@ -237,4 +237,4 @@ Wrapper around the profiler's implementation of ICorProfilerCallback is located ProfToEEInterfaceImpl.\* ----------------------- -Implementation of ICorProfilerInfo is located at [src\vm\ProfToEEInterfaceImpl.\*](https://github.com/dotnet/coreclr/tree/master/src/vm).
\ No newline at end of file +Implementation of ICorProfilerInfo is located at [src\vm\ProfToEEInterfaceImpl.\*](https://github.com/dotnet/coreclr/tree/master/src/vm). diff --git a/Documentation/profiling.md b/Documentation/profiling.md index dd6208476d..b66e236cdd 100644 --- a/Documentation/profiling.md +++ b/Documentation/profiling.md @@ -510,4 +510,4 @@ This can be accomplished by some simple synchronization. #### Initializing the Runtime -If the profiler has its own thread on which it will be calling ICorProfilerInfo functions, it needs to ensure that it calls one such function before doing any thread suspensions. This is because the runtime has per-thread state that needs to be initialized with all other threads running to avoid possible deadlocks.
\ No newline at end of file +If the profiler has its own thread on which it will be calling ICorProfilerInfo functions, it needs to ensure that it calls one such function before doing any thread suspensions. This is because the runtime has per-thread state that needs to be initialized with all other threads running to avoid possible deadlocks. diff --git a/Documentation/project-priorities.md b/Documentation/project-priorities.md new file mode 100644 index 0000000000..bb49427227 --- /dev/null +++ b/Documentation/project-priorities.md @@ -0,0 +1,27 @@ +.NET Core Goals and Priorities +============================== + +Microsoft published .NET Core to GitHub, with the following goals and priorities. + +Goals +----- + +- Establish a high-quality open source .NET implementation, with [CoreCLR](https://github.com/dotnet/coreclr) and [CoreFX](https://github.com/dotnet/corefx). +- Port CoreCLR to Linux and OS X (already supported on Windows). +- Support the community extending CoreCLR in various ways (e.g. [FreeBSD support](https://github.com/dotnet/coreclr/issues/455)). + +Priorities +---------- + +The project has the following priorities, set by the .NET Team: + +- x64 is the priority chip to support. x86 and ARM32 will follow. +- Windows, Linux and OS X support have the same priority. +- Porting is a higher priority (at this time) than new features. + +Microsoft Team Engagement +------------------------- + +The Microsoft team will engage on incoming PRs and issues that align with these goals and priorities. The team will also try to engage on other issues as time allows. + +The community is encouraged to create a broad range of issues. There may be a significant group of developers that are interested in the same topic. If a strong community viewpoint establishes itself on an issue outside of the core priority, then the team will likely engage on the issue. Engagement does not mean that the Microsoft team will necessarily build a feature, but discuss merits and implementation approaches. diff --git a/Documentation/test-instructions.md b/Documentation/test-instructions.md deleted file mode 100644 index 9ba2e13e3b..0000000000 --- a/Documentation/test-instructions.md +++ /dev/null @@ -1,65 +0,0 @@ -Testing CoreCLR -=============== - -These instructions will lead you through testing CoreCLR on Windows. The tests are not fully supported on Linux and OS X and will be updated when they are. - -Building and running tests -========================== - -**Building Tests** - -In a clean command prompt, issue the following command: - - C:\git\coreclr>tests\buildtest.cmd clean - -**buildtest /?** will list supported parameters. - -**Note:** The above command (or building from the repo_root) must be done once, at the least, to ensure that all test dependencies are initialized correctly. - -In Visual Studio, open `<repo_root>\tests\src\AllTestProjects.sln`, build all the test projects or the one required. - -**Running Tests** - -In a clean command prompt: `<repo_root>\tests\runtest.cmd` - -**runtest /?** will list supported parameters. - -This will generate the report named as `TestRun_<arch>_<flavor>.html` (e.g. `TestRun_x64__release.html`) in the current folder. It will also copy all the test dependencies to the folder passed at the command line. - -**Investigating Test Failures** - -Upon completing a test run, you may find one or more tests have failed. - -The output of the Test will be available in Test reports directory, but the default the directory would be something like is `<repo_root>\binaries\tests\x64\debug\Reports\Exceptions\Finalization`. - -There are 2 files of interest: - -- `Finalizer.output.txt` - Contains all the information logged by the test. -- `Finalizer.error.txt` - Contains the information reported by CoreRun.exe (which executed the test) when the test process crashes. - -**Rerunning a failed test** - -If you wish to re-run a failed test, please follow the following steps: - -1. Set an environment variable, `CORE_ROOT`, pointing to the path to product binaries that was passed to runtest.cmd. The command to set this environment variable is also specified in the test report for a failed test. -2. Next, run the failed test, the command to which is also present in the test report for a failed test. It will be something like `<repo_root>\binaries\tests\x64\debug\Exceptions\Finalization\Finalizer.cmd`. - -If you wish to run the test under a debugger (e.g. [WinDbg](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551063(v=vs.85).aspx)), append `-debug <debuggerFullPath>` to the test command. For example: - - - <repo_root>\binaries\tests\x64\debug\Exceptions\Finalization\Finalizer.cmd -debug <debuggerFullPath> - -**Modifying a test** - -If test changes are needed, make the change and build the test project. This will binplace the binaries in test binaries folder (e.g. `<repo_root>\binaries\tests\x64\debug\Exceptions\Finalization`). At this point, follow the steps to re-run a failed test to re-run the modified test. - -**Authoring Tests (in VS)** - -1. Use an existing test such as `<repo_root>\tests\src\Exceptions\Finalization\Finalizer.csproj` as a template and copy it to a new folder under `<repo_root>\tests\src`. -2. Add the project of the new test to `<repo_root>\tests\src\AllTestProjects.sln` in VS -3. Add source files to this newly added project. -4. Indicate the success of the test by returning `100`. -5. Add the .NET CoreFX contract references, as required, via the Nuget Package Manager in Visual Studio. *Make sure this does not change the csproj. If it does, then undo the change in the csproj.* -6. Add any other projects as a dependency, if needed. -7. Build the test. -8. Follow the steps to re-run a failed test to validate the new test.
\ No newline at end of file diff --git a/Validating-changes.md b/Documentation/testing-with-corefx.md index 68b0654457..c1894a25f7 100644 --- a/Validating-changes.md +++ b/Documentation/testing-with-corefx.md @@ -1,17 +1,15 @@ -We have ported very few of our CoreCLR and mscorlib tests to the repo. When we do, this topic will grow. Until then, the following technique is a good sanity test for your changes. - -Validating your changes using CoreFX -==================================== +Testing with CoreFX +=================== It may be valuable to use CoreFX tests to validate your changes to CoreCLR or mscorlib. In order to do this you need to create a file called `localpublish.props` under the `<repo root>\packages` folder. The contents of the file should look like this (make sure to update the version to the current version of the CoreCLR package used by CoreFx): - <Project ToolsVersion="12.0" DefaultTargets="Build" - xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> + <Project ToolsVersion="12.0" DefaultTargets="Build" + xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <ItemGroup> - <LocalPackages Include="$(PackagesBinDir)"> + <LocalPackages Include="$(PackagesBinDir)"> <PackageName>Microsoft.DotNet.CoreCLR</PackageName> <PackageVersion>1.0.2-prerelease</PackageVersion> <InstallLocation><corefx repo root>\packages</InstallLocation> @@ -21,4 +19,4 @@ The contents of the file should look like this (make sure to update the version Once this file is there, subsequent builds of the CoreCLR repo will install the CoreCLR package into the location specified by `InstallLocation`. -To run tests, follow the procedure for running tests in CoreFX.
\ No newline at end of file +To run tests, follow the procedure for running tests in CoreFX. diff --git a/Documentation/threading.md b/Documentation/threading.md index 5fd9456e05..ef2d3cd682 100644 --- a/Documentation/threading.md +++ b/Documentation/threading.md @@ -207,4 +207,4 @@ This thread is responsible for unloading AppDomains. This is done on a separate, ThreadPool Threads ------------------ -The CLR's ThreadPool maintains a collection of managed threads for executing user "work items." These managed threads are bound to native threads owned by the ThreadPool. The ThreadPool also maintains a small number of native threads to handle functions like "thread injection," timers, and "registered waits."
\ No newline at end of file +The CLR's ThreadPool maintains a collection of managed threads for executing user "work items." These managed threads are bound to native threads owned by the ThreadPool. The ThreadPool also maintains a small number of native threads to handle functions like "thread injection," timers, and "registered waits." diff --git a/Documentation/validating-changes.md b/Documentation/validating-changes.md deleted file mode 100644 index f610081886..0000000000 --- a/Documentation/validating-changes.md +++ /dev/null @@ -1,27 +0,0 @@ -Validating CoreCLR Changes -========================== - -We have ported very few of our CoreCLR and mscorlib tests to the repo. When we do, this topic will grow. Until then, the following technique is a good sanity test for your changes. - -Validating your changes using CoreFX -==================================== - -It may be valuable to use CoreFX tests to validate your changes to CoreCLR or mscorlib. - -In order to do this you need to create a file called `localpublish.props` under the `<repo root>\packages` folder. -The contents of the file should look like this (make sure to update the version to the current version of the CoreCLR package used by CoreFx): - - <Project ToolsVersion="12.0" DefaultTargets="Build" - xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> - <ItemGroup> - <LocalPackages Include="$(PackagesBinDir)"> - <PackageName>Microsoft.DotNet.CoreCLR</PackageName> - <PackageVersion>1.0.2-prerelease</PackageVersion> - <InstallLocation><corefx repo root>\packages</InstallLocation> - </LocalPackages> - </ItemGroup> - </Project> - -Once this file is there, subsequent builds of the CoreCLR repo will install the CoreCLR package into the location specified by `InstallLocation`. - -To run tests, follow the procedure for running tests in CoreFX.
\ No newline at end of file diff --git a/Documentation/virtual-stub-dispatch.md b/Documentation/virtual-stub-dispatch.md index 717c8f568f..85c545949c 100644 --- a/Documentation/virtual-stub-dispatch.md +++ b/Documentation/virtual-stub-dispatch.md @@ -185,4 +185,4 @@ Physical Architecture For dispatch token and map implementation details, please see [clr/src/vm/contractImpl.h](https://github.com/dotnet/coreclr/blob/master/src/vm/contractimpl.h) and [clr/src/vm/contractImpl.cpp](https://github.com/dotnet/coreclr/blob/master/src/vm/contractimpl.cpp). -For virtual stub dispatch implementation details, please see [clr/src/vm/virtualcallstub.h](https://github.com/dotnet/coreclr/blob/master/src/vm/virtualcallstub.h) and [clr/src/vm/virtualcallstub.cpp](https://github.com/dotnet/coreclr/blob/master/src/vm/virtualcallstub.cpp).
\ No newline at end of file +For virtual stub dispatch implementation details, please see [clr/src/vm/virtualcallstub.h](https://github.com/dotnet/coreclr/blob/master/src/vm/virtualcallstub.h) and [clr/src/vm/virtualcallstub.cpp](https://github.com/dotnet/coreclr/blob/master/src/vm/virtualcallstub.cpp). diff --git a/Documentation/windows-debugging-instructions.md b/Documentation/windows-debugging-instructions.md new file mode 100644 index 0000000000..de1d0a4def --- /dev/null +++ b/Documentation/windows-debugging-instructions.md @@ -0,0 +1,24 @@ +Debugging CoreCLR on Windows +============================ + +1. Perform a build of the repo. +2. Open <repo_root>\binaries\Cmake\CoreCLR.sln in VS. +3. Right click the INSTALL project and choose ‘Set as StartUp Project’ +4. Bring up the properties page for the INSTALL project +5. Select Configuration Properties->Debugging from the left side tree control +6. Set Command=`$(SolutionDir)..\product\$(Platform)\$(Configuration)\corerun.exe` + 1. This points to the folder where the built runtime binaries are present. +7. Set Command Arguments=`<managed app you wish to run>` (e.g. HelloWorld.exe) +8. Set Working Directory=`$(SolutionDir)..\product\$(Platform)\$(Configuration)` + 1. This points to the folder containing CoreCLR binaries. +9. Press F11 to start debugging at wmain in corerun (or set a breakpoint in source and press F5 to run to it) + 1. As an example, set a breakpoint for the EEStartup function in ceemain.cpp to break into CoreCLR startup. + +Steps 1-8 only need to be done once, and then (9) can be repeated whenever you want to start debugging. The above can be done with Visual Studio 2013. + +Debugging Mscorlib and/or managed application +============================================= + +To step into and debug managed code of Mscorlib.dll (or the managed application being executed by the runtime you built), using Visual Studio, is something that will be supported with Visual Studio 2015. We are actively working to enable this support. + +Until then, you can use [WinDbg](https://msdn.microsoft.com/en-us/library/windows/hardware/ff551063(v=vs.85).aspx) and [SOS](https://msdn.microsoft.com/en-us/library/bb190764(v=vs.110).aspx) (an extension to WinDbg to support managed debugging) to step in and debug the generated managed code. This is what we do on the .NET Runtime team as well :) diff --git a/Test-instructions.md b/Documentation/windows-test-instructions.md index d1aee5ab87..1935ce550c 100644 --- a/Test-instructions.md +++ b/Documentation/windows-test-instructions.md @@ -1,7 +1,5 @@ -These instructions will lead you through testing CoreCLR on Windows. The tests are not fully supported on Linux and OS X and will be updated when they are. - -Building and running tests -========================== +Building and running tests on Windows +===================================== **Building Tests** @@ -59,4 +57,4 @@ If test changes are needed, make the change and build the test project. This wil 5. Add the .NET CoreFX contract references, as required, via the Nuget Package Manager in Visual Studio. *Make sure this does not change the csproj. If it does, then undo the change in the csproj.* 6. Add any other projects as a dependency, if needed. 7. Build the test. -8. Follow the steps to re-run a failed test to validate the new test.
\ No newline at end of file +8. Follow the steps to re-run a failed test to validate the new test. @@ -47,13 +47,10 @@ Some of the best ways to contribute are to try things out, file bugs, and join i Looking for something to work on? The list of [up-for-grabs issues](https://github.com/dotnet/coreclr/issues?q=is%3Aopen+is%3Aissue+label%3Aup-for-grabs) is a great place to start. -Please checkout the wiki to read the [contribution guidelines][Contributing Guide] for .NET Core and the deverloper guide for general information. +Please read the following documents to get started. -* [Contributing Guide][Contributing Guide] -* [Developer Guide](https://github.com/dotnet/coreclr/wiki/Developer-Guide) - -[.NET Foundation forums]: http://forums.dotnetfoundation.org/ -[Contributing Guide]: https://github.com/dotnet/coreclr/wiki/Contributing +* [Contributing Guide](Documentation/contributing.md) +* [Developer Guide](Documentation/developer-guide.md) License ------- @@ -95,14 +95,14 @@ goto CheckVS :: Check presence of VS if defined VS%__VSProductVersion%COMNTOOLS goto CheckVSExistence echo Visual Studio 2013 Community (free) is a pre-requisite to build this repository. -echo See: https://github.com/dotnet/coreclr/wiki/Developer-Guide#prerequisites +echo See: https://github.com/dotnet/coreclr/blob/master/Documentation/developer-guide.md#prerequisites exit /b 1 :CheckVSExistence :: Does VS 2013 or VS 2015 really exist? if exist "!VS%__VSProductVersion%COMNTOOLS!\..\IDE\devenv.exe" goto CheckMSBuild echo Visual Studio 2013 Community (free) is a pre-requisite to build this repository. -echo See: https://github.com/dotnet/coreclr/wiki/Developer-Guide#prerequisites +echo See: https://github.com/dotnet/coreclr/blob/master/Documentation/developer-guide.md#prerequisites exit /b 1 :CheckMSBuild @@ -120,7 +120,7 @@ set _msbuildexe="%ProgramFiles(x86)%\MSBuild\14.0\Bin\MSBuild.exe" set UseRoslynCompiler=true :CheckMSBuild14 if not exist %_msbuildexe% set _msbuildexe="%ProgramFiles%\MSBuild\14.0\Bin\MSBuild.exe" -if not exist %_msbuildexe% echo Error: Could not find MSBuild.exe. Please see https://github.com/dotnet/coreclr/wiki/Developer%%20Guide for build instructions. && exit /b 1 +if not exist %_msbuildexe% echo Error: Could not find MSBuild.exe. Please see https://github.com/dotnet/coreclr/blob/master/developer-guide.md for build instructions. && exit /b 1 :: All set to commence the build @@ -141,7 +141,7 @@ of previous version to "%VSINSTALLDIR%" and then resume build. :: DIA SDK not included in Express editions echo Visual Studio 2013 Express does not include the DIA SDK. ^ You need Visual Studio 2013 Community (free). -echo See: https://github.com/dotnet/coreclr/wiki/Developer-Guide#prerequisites +echo See: https://github.com/dotnet/coreclr/blob/master/Documentation/developer-guide.md#prerequisites exit /b 1 :GenVSSolution diff --git a/tests/buildtest.cmd b/tests/buildtest.cmd index 7a13474c27..2f44f53d34 100644 --- a/tests/buildtest.cmd +++ b/tests/buildtest.cmd @@ -97,7 +97,7 @@ if not exist %_msbuildexe% set _msbuildexe="%ProgramFiles%\MSBuild\12.0\Bin\MSBu :MSBuild14 if not exist %_msbuildexe% set _msbuildexe="%ProgramFiles(x86)%\MSBuild\14.0\Bin\MSBuild.exe" if not exist %_msbuildexe% set _msbuildexe="%ProgramFiles%\MSBuild\14.0\Bin\MSBuild.exe" -if not exist %_msbuildexe% echo Error: Could not find MSBuild.exe. Please see https://github.com/dotnet/coreclr/wiki/Developer%%20Guide for build instructions. && exit /b 1 +if not exist %_msbuildexe% echo Error: Could not find MSBuild.exe. Please see https://github.com/dotnet/coreclr/blob/master/Documentation/developer-guide.md for build instructions. && exit /b 1 ::Building Native part of Tests setlocal @@ -143,7 +143,7 @@ REM setlocal to prepare for vsdevcmd.bat setlocal :: Set the environment for the managed build- Vs cmd prompt call "!VS%__VSProductVersion%COMNTOOLS!\VsDevCmd.bat" -if not defined VSINSTALLDIR echo Error: build.cmd should be run from a Visual Studio Command Prompt. Please see https://github.com/dotnet/coreclr/wiki/Developer%%20Guide for build instructions. && exit /b 1 +if not defined VSINSTALLDIR echo Error: build.cmd should be run from a Visual Studio Command Prompt. Please see https://github.com/dotnet/coreclr/blob/master/Documentation/developer-guide.md for build instructions. && exit /b 1 :BuildTests diff --git a/tests/runtest.cmd b/tests/runtest.cmd index 0963bc0486..c9232c90d6 100644 --- a/tests/runtest.cmd +++ b/tests/runtest.cmd @@ -45,12 +45,12 @@ set _msbuildexe="%ProgramFiles(x86)%\MSBuild\14.0\Bin\MSBuild.exe" set UseRoslynCompiler=true :CheckMSBuild14 if not exist %_msbuildexe% set _msbuildexe="%ProgramFiles%\MSBuild\14.0\Bin\MSBuild.exe" -if not exist %_msbuildexe% echo Error: Could not find MSBuild.exe. Please see https://github.com/dotnet/corefx/wiki/Developer%%20Guide for build instructions. && exit /b 1 +if not exist %_msbuildexe% echo Error: Could not find MSBuild.exe. Please see https://github.com/dotnet/corefx/blob/master/Documentation/developer-guide.md for build instructions. && exit /b 1 :: Set the environment for the build- Vs cmd prompt call "!VS%__VSProductVersion%COMNTOOLS!\VsDevCmd.bat" -if not defined VSINSTALLDIR echo Error: runtest.cmd should be run from a Visual Studio Command Prompt. Please see https://github.com/dotnet/coreclr/wiki/Developer%%20Guide for build instructions. && exit /b 1 +if not defined VSINSTALLDIR echo Error: runtest.cmd should be run from a Visual Studio Command Prompt. Please see https://github.com/dotnet/coreclr/blob/master/Documentation/developer-guide.md for build instructions. && exit /b 1 if not defined __BuildArch set __BuildArch=x64 |