- [.NET Glossary](project/glossary.md)
- [.NET Filename Encyclopedia](project/dotnet-filenames.md)
-- [Porting to .NET Core](project/support-dotnet-core-instructions.md)
+- [Porting to .NET Core](https://docs.microsoft.com/en-us/dotnet/standard/analyzers/portability-analyzer)
- [.NET Standards (Ecma)](project/dotnet-standards.md)
- [CLR Configuration Knobs](../src/coreclr/src/inc/clrconfigvalues.h)
- [CLR overview](https://docs.microsoft.com/dotnet/standard/clr)
+++ /dev/null
-## dotnet/runtime
-
-### Libraries in NETStandard
-
-- ref
- - Default targetgroup should be NETCoreApp build
- - P2P references to other reference assembly CSProjs.
- - System.Runtime core assembly.
- - Cross-compiles for concrete frameworks (if different)
- - EG: exposes types/members not in NETStandard on NETCoreApp, but not on UWP
-- src
- - Default targetgroup should be NETCoreApp build
- - depends on System.Runtime?
- - Yes: P2P to ref CSProjs
- - No: P2P to implementation projects
- - **Issue:** what if dependency is not in NETStandard? EG: Buffers
- - P2P reference to pkgproj
- - Reference to NETStandard.dll facade for NETCoreApp
-- pkg
- - No individual package builds.
- - We will have a single package for all of NETCore.App's netstandard.library implementation. Below TBD.
- - framework split packages
- - ref\netcoreappN - all refs for NETCoreApp,Version=vN
- - runtime split packages
- - runtime\{RID}\lib\netcoreappN - all impl for NETCoreApp,Version=vN, cross-gen'ed for RID
-- tests
- - By default get all of NETStandard.Library for a specific version that they target (auto-referenced by targets)
- - Use P2P references to pkgproj for things not in NETStandard.Library
- - Implementation is automatically injected by targets.
-
-### Libraries above NETStandard
-- ref
- - Only required if component is inbox somewhere or has multiple implementations for same NETStandard version.
- - Build against NETStandard.Library package
- - P2P references to pkgproj for things not in NETStandard.Library
- - For builds that support older platforms (eg: netstandard1.0-1.6) we'll be building against the older contract-based NETStandard, we will need a story for this for build-from-source.
-- src
- - Build against NETStandard.Library package
- - P2P references to pkgproj for things not in NETStandard.Library
- - For builds that support older platforms (eg: netstandard1.0-1.6) we'll be building against the older contract-based NETStandard, we will need a story for this for build-from-source.
-- pkg
- - Not in NETCore.App: as today
- - In NETCore.App: package in NETCore.App package as above
- - If the library also ships in a package, it will also build a package as today. This package may or may-not include the same binaries as are used by NETCore.App, for instance if the library builds against older NETStandard versions.
-- tests
- - By default get all of NETStandard.Library for a specific version that they target (auto-referenced by targets)
- - Use P2P references for things not in NETStandard.Library
- - Implementation is automatically injected by targets.
-
-### NETStandard compatibility facade
-Provides compatibility between NETCore.App and libraries built against NETStandard.
-- ref
- - Should adapt supported NETStandard.dll to contract reference assemblies.
- - EG: `GenFacades -contracts:<netstandard.dll> -seeds:<allNetCoreAppReferenceAssemblies>`
-- src
- - Should adapt supported NETStandard.dll to implementation assemblies.
- - EG: `GenFacades -contracts:<netstandard.dll> -seeds:<allNetCoreAppImplementationAssemblies>`
-- pkg
- - No individual package builds.
- - Should be included in NETCoreApp package as above
-
-### Desktop compatibility facades
-- ref
- - Should adapt latest desktop surface to contract reference assemblies for anything that has type-overlap with desktop, including assemblies like Microsoft.Win32.Registry which are not in NETStandard.Library.
- - EG: `GenFacades -contracts:<desktopReferenceAssemblies> -seeds:<allNetCoreAppReferenceAssemblies>`
-- src
- - Should adapt latest desktop surface to netcore app implementation for anything that has type-overlap with desktop, including assemblies like Microsoft.Win32.Registry which are not in NETStandard.Library.
- - EG: `GenFacades -contracts:<desktopReferenceAssemblies> -seeds:<allNetCoreAppImplementationAssemblies>`
-- pkg
- - No individual package builds.
- - Should be included in NETCoreApp package as above
-
-### Native shims
-- pkg
- - No individual package builds.
- - As with libraries in NETStandard the shims will be included in the runtime specific packages for NETCoreApp
-
-## Transition
-
-### End goal
-
-- dotnet/runtime does not build any reference assemblies for NETStandard.
-- For every library in NETStandard.Library, the only configurations in dotnet/runtime are framework-specific. EG: netcoreapp3.0, net472
-- For every library in NETCore.App but not in NETStandard.Library there must be a framework-specific configuration for NETCoreApp1.2. Other configurations may exist to ship in a package, but those will not be built by folks building just NETCore.App.
If during the code review process a merge conflict occurs the area owner is responsible for its resolution. Pull requests should not be on hold due to the author's unwillingness to resolve code conflicts. GitHub makes this easier by allowing simple conflict resolution using the [conflict-editor](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-on-github).
## Merging Pull Requests
+
Anyone with write access can merge a pull request manually or by setting the [auto-merge](/labels/auto-merge) label when it satisfies all of the following conditions:
* The PR has been approved by at least one reviewer and any other objections are addressed.
* The PR successfully builds and passes all tests in the Continuous Integration (CI) system.
* You can trigger a rebuild by adding a comment like `/azp run <pipeline name>` or manually re-run only the failing lanes in Azure DevOps tab.
* Reach out to the infrastructure team for assistance on [Teams channel](https://teams.microsoft.com/l/channel/19%3ab27b36ecd10a46398da76b02f0411de7%40thread.skype/Infrastructure?groupId=014ca51d-be57-47fa-9628-a15efcc3c376&tenantId=72f988bf-86f1-41af-91ab-2d7cd011db47) (for corpnet users) or on [Gitter](https://gitter.im/dotnet/community) in other cases.
- * In rare cases the pull request can be merged with failing tests if the person merging it also creates tracking issue for flaky tests.
Please always **squash** the pull request unless there are special circumstances. Do so, even if the PR contains only one commit. It creates a simpler history than a Merge Commit. "Special circumstances" are rare, and typically mean that there are a series of cleanly separated changes that will be too hard to understand if squashed together, or for some reason we want to preserve the ability to bisect them.
+## Unrelated failure
+
+In case CI indicates failures which are **highly unlikely** to be caused by changes in the PR, the following actions should be taken:
+
+* An existing issue in the repository should be searched for. Usually the test method's or the test assembly's name (in case of a crash) are good parameters.
+* If there's an existing issue, a comment should be placed that includes a) the link to the build, b) the affected configuration (ie `netcoreapp-Windows_NT-Release-x64-Windows.81.Amd64.Open`) and c) the Error message and Stack trace. This is necessary as retention policies are in place that recycle _old_ builds. In case the issue is already closed, it should be reopened and labels should be updated to reflect the current failure state.
+* If there's no existing issue, an issue should be created with the same information outlined above.
+* In a follow-up Pull Request, the failing test(s) should be disabled with the corresponding issue number, e.g. `[ActiveIssue(x)]`, and the tracking issue should be labeled as `disabled-test`.
+* A comment should be placed in the original Pull Request that links to the created or updated issues.
+
+There are plenty of possible bugs, e.g. race conditions, where a failure might highlight a real problem and it won't manifest again on a retry. Therefore these steps should be followed for every iteration of the PR build, e.g. before retrying/rebuilding.
+
## Blocking Pull Request Merging
If for whatever reason you would like to move your pull request back to an in-progress status to avoid merging it in the current form, you can do that by adding [WIP] prefix to the pull request title.
## Old Pull Request Policy
+
From time to time we will review older PR's (> 1 month) and check them for relevance. If we find the PR is inactive or no longer applies, we will close it. As the PR owner, you can simply reopen it if you feel your closed PR needs our attention.
+++ /dev/null
-# How to correlate commits with builds
-
-Recently I checked in a change to one of our various dotnet repos (coreclr) and
-I wanted to figure out when the change would appear in our various NuGet
-packages and installers. I didn't know how the changes flowed through our
-build, setup, and publication processes so I asked around (thanks @dagood!) and
-wrote up what I learned. If you discover this doc is inaccurate or incomplete,
-kindly update it!
-
-## How Release works from 10,000 ft
-
-1. Every night an automated build runs on the source of each dotnet repo and
-produces some binaries that are placed in NuGet packages on MyGet. For example
-[this CoreCLR package](https://dotnet.myget.org/feed/dotnet-core/package/nuget/runtime.win-x64.Microsoft.NETCore.Runtime.CoreCLR)
-is one of the packages produced by the
-[CoreCLR repo](https://github.com/dotnet/coreclr).
-These packages are generally not intended for distribution to customers, they
-are only containers to exchange binaries.
-2. Every night a seperate automated build for the
-[core-setup](https://github.com/dotnet/core-setup) repo produces
-[installers](https://github.com/dotnet/core/blob/master/daily-builds.md)
-and the [Microsoft.NetCore.App NuGet package](https://dotnet.myget.org/feed/dotnet-core/package/nuget/Microsoft.NETCore.App).
-These packages aggregate the binaries that were built from many other repos
-and this is what customers use - though more often Preview and RTM builds
-instead of the less tested daily builds.
-The daily builds of installers and Microsoft.NetCore.App do not necessarily
-have the latest builds from each constituent repo, thus the build versions
-from individual repos may not match the build version of Microsoft.NetCore.App
-or an installer that aggregated them.
-
-## Our starting point
-
-In my case I had a git commit: [435a69a9aca037f348a09e00dffef8a0888682a7
-in the coreclr repo](https://github.com/dotnet/coreclr/commit/435a69a9aca037f348a09e00dffef8a0888682a7)
-and I wanted to know where this code had propagated to. Alternatively
-you may be starting from a particular package or installer and wondering
-what source it contains. Lets start exploring!
-
-
-## Where are the daily build NuGet packages published?
-
-For many of the dotnet repos such as CoreCLR the daily builds are posted to the
-[dotnet-core](https://dotnet.myget.org/gallery/dotnet-core) feed. Other repos or
-specific branches might publish elsewhere in which case hopefully you can find
-that in the repo docs or by searching [the gallery](https://dotnet.myget.org/gallery)
-for an appropriate sounding feed name.
-
-
-## What (intermediate) NuGet packages does a given repo produce?
-
-Whenever a dotnet repo publishes new builds it makes a commit in the
-[dotnet/versions repo](https://github.com/dotnet/versions) indicating which
-packages got published. For example during the night after I merged my
-example CoreCLR change
-[this commit](https://github.com/dotnet/versions/commit/cf8930fbe52e5eacf8ab0d7fb06f032d19cda5d5#diff-5f6099c37f777c410c4397b3f1e38870)
-was merged in dotnet/versions. Looking at
-[Last_Build_Packages.txt](https://github.com/dotnet/versions/blob/master/build-info/dotnet/coreclr/master/Last_Build_Packages.txt)
-which was modified in that commit you can see a list of NuGet packages that
-CoreCLR repo publishes.
-
-
-## What git commit was a NuGet package built from (answer via MyGet)?
-
-Pick an arbitrary NuGet package produced by your repo of interest and look
-for it on the MyGet [gallery](https://dotnet.myget.org/gallery). For example
-one of the [coreclr packages](https://dotnet.myget.org/feed/dotnet-core/package/nuget/runtime.win-x64.Microsoft.NETCore.Runtime.CoreCLR)
-produced by the [coreclr repo](https://github.com/dotnet/coreclr).
-
-Right in the description text there is an embedded git commit hash and lower
-on the page is the Package History section with links to every build of the
-package that has been published. For example the
-[2.2.0-preview1-26608-04](https://dotnet.myget.org/feed/dotnet-core/package/nuget/runtime.win-x64.Microsoft.NETCore.Runtime.CoreCLR/2.2.0-preview1-26608-04)
-build description says:
-
-> Internal implementation package not meant for direct consumption. Please do not reference directly. The .NET Core runtime,
-called CoreCLR, and the base library, called System.Private.CoreLib. It includes the garbage collector, JIT compiler, base .NET
-data types and many low-level classes. 311322beb96c5475fd7030fcd2f6e7ff14918853 When using NuGet 3.x this package
-requires at least version 3.4.
-
-This NuGet package has all the code from commit [311322beb96c5475fd7030fcd2f6e7ff14918853](https://github.com/dotnet/coreclr/commit/311322beb96c5475fd7030fcd2f6e7ff14918853)
-
-
-## What git commit was a NuGet package built from (answer via package inspection)?
-
-You can explore the contents of a NuGet package by changing the extension from
-.nupkg to .zip, then extract it with any tool that handles .zip. In the root
-of the extracted folder there is a version.txt file which shows the git
-commit hash.
-
-In the [Microsoft.NetCore.App NuGet package](https://dotnet.myget.org/feed/dotnet-core/package/nuget/Microsoft.NETCore.App)
-the file Microsoft.NETCore.App.versions.txt contains the git commit hashes for
-the corefx and coreclr builds that were aggregated as well.
-
-
-## What git commit was a particular binary built from?
-
-The git commit hash is appended to the version resource in many of our
-binaries. You can use any tool that views file versions such as a debugger
-or filever.
-
-
-## What repo build version has a particular commit I am looking for?
-
-There is no direct map from commits to build versions, instead you need to find
-an arbitrary NuGet package produced by the repo the commit is in (see above)
-and then search different package build versions to find the one that contains
-the commit. You can often make a good initial guess by noting the time the
-commit was merged and pick the next build after that.
-
-For example I wanted to find the first build from the CoreCLR repo that
-contained commit
-[435a69a9aca037f348a09e00dffef8a0888682a7](https://github.com/dotnet/coreclr/commit/435a69a9aca037f348a09e00dffef8a0888682a7).
-I arbitrarily chose
-[this package](https://dotnet.myget.org/feed/dotnet-core/package/nuget/runtime.win-x64.Microsoft.NETCore.Runtime.CoreCLR)
-that is created by the CoreCLR repo. I checked the build that was uploaded the
-evening after the commit
-[2.2.0-preview1-26608-04](https://dotnet.myget.org/feed/dotnet-core/package/nuget/runtime.win-x64.Microsoft.NETCore.Runtime.CoreCLR/2.2.0-preview1-26608-04).
-That package was built from commit
-[311322beb96c5475fd7030fcd2f6e7ff14918853](https://github.com/dotnet/coreclr/commit/311322beb96c5475fd7030fcd2f6e7ff14918853)
-(determined as above). The commit was more recent than mine so I know my
-change was included in CoreCLR build 2.2.0-preview1-26608-04.
-
-
-## What build of Microsoft.NetCore.App NuGet package has a particular constituent repo commit I am looking for (answer via MyGet)?
-
-1. Determine the first build from the repo that has the commit (see above)
-For example above I determined that commit
-[435a69a9aca037f348a09e00dffef8a0888682a7](https://github.com/dotnet/coreclr/commit/435a69a9aca037f348a09e00dffef8a0888682a7)
-in the coreclr repo first appears in the CoreCLR build version
-2.2.0-preview1-26608-04.
-
-2. In the [commit history of the core-setup repo](https://github.com/dotnet/core-setup/commits/master)
-look for commits that say 'Update your_repo_name to some_version'
-where some_version is at least as recent as the one that has your commit.
-[This one](https://github.com/dotnet/core-setup/commit/8a48d863ad01ccd0763b7f3fab487503f5b75625)
-updated CoreCLR to preview1-26609-02. Then you search the MyGet feed for the
-[Microsoft.NetCore.App package](https://dotnet.myget.org/feed/dotnet-core/package/nuget/Microsoft.NETCore.App)
-looking for one with an embedded git hash in the description text that is at
-least as recent. In this case
-[this package](https://dotnet.myget.org/feed/dotnet-core/package/nuget/Microsoft.NETCore.App/2.2.0-preview1-26610-01)
-was exactly at that commit.
-
-
-## What build of Microsoft.NetCore.App NuGet package has a particular constituent repo commit I am looking for (answer via inspecting a package)?
-
-If you have a particular Microsoft.NETCore.App NuGet package already downloaded
-you can look at Microsoft.NETCore.App.versions.txt in the root of the package
-to see the git hashes of various repos that were used to compose the build.
-
-
-## What build of the installers has a particular constituent repo commit I am looking for?
-
-1. Determine the first build of Microsoft.NetCore.App which has the commit
-(see above). For example I determined
-[Microsoft.NetCore.App 2.2.0-preview1-26610-01](https://dotnet.myget.org/feed/dotnet-core/package/nuget/Microsoft.NETCore.App/2.2.0-preview1-26610-01)
-contains coreclr commit
-[435a69a9aca037f348a09e00dffef8a0888682a7](https://github.com/dotnet/coreclr/commit/435a69a9aca037f348a09e00dffef8a0888682a7)
-
-2. Daily builds for both the runtime and the full SDK can be found
-[here](https://github.com/dotnet/core/blob/master/daily-builds.md). For the
-runtime build, pick the same version as the Microsoft.NetCore.App NuGet package
-you just determined in step (1). For the SDK if you download one of these in
-zip form you can browse to .\shared\Microsoft.NETCore.App and then build number
-of the M.N.A package is used as the subdirectory name. Make sure the version
-is recent enough to contain the changes you are looking for.
\ No newline at end of file
+++ /dev/null
-# Pull Request Policy
-
-In CoreFx we rely on the following policies before a Pull Request (PR) can be merged:
-
-1. Every PR needs to be **approved** by a team member with write access to the repository.
-2. Unless changes aren't protected by **Continuous Integration** (CI), e.g. Markdown edits, CI must have run recently, within 7 days unless no commits have been merged. In cases where other PRs have been merged into the same library since CI was run, it is desirable to re-run CI in order to get fresh results and avoid build breaks.
-3. All defined CI legs on the PR must have run and be **green**, except when [unrelated test failure](#unrelated-test-failure) happened. In rare circumstances, CI may not run, in which case the GitHub green check mark may exist to say that all legs were successful, but only a couple legs actually may have been run and completed; in such cases, PRs must not be merged.
-
-The aforementioned rules apply to both community and team members.
-
-## Unrelated test failure
-In case CI indicates test failures which are **highly unlikely** to be caused by changes in the Pull Request, the following actions should be taken:
-1. An existing issue in the repository should be searched for. Usually the test method's or the test assembly's name (in case of a crash) are good parameters.
-2. If there's an existing issue, a comment should be placed that includes a) the link to the build, b) the affected configuration (ie `netcoreapp-Windows_NT-Release-x64-Windows.81.Amd64.Open`) and c) the Error message and Stack trace. This is necessary as retention policies are in place that recycle _old_ builds. In case the issue is already closed, it should be reopened and labels should be updated to reflect the current failure state.
-3. If there's no existing issue, an issue should be created with the same information outlined above.
-4. In a follow-up Pull Request, the failing test(s) should be disabled with the corresponding issue number, e.g. `[ActiveIssue(x)]`, and the tracking issue should be labeled as `disabled-test`.
-5. A comment should be placed in the original Pull Request that links to the created or updated issues.
-
-The only time this can be skipped is if the issue is already being investigated, is already reproable locally, is already known to happen on the OS/version on which it failed, and additional ref counts on the issues / additional crash dumps / etc. are definitively known to not be necessary for the developer responsible for the issue. This is relatively rare.
-
-There are plenty of possible bugs, e.g. race conditions, where a failure might highlight a real problem and it won't manifest again on a retry. Therefore these steps should be followed for every iteration of the PR build, e.g. before retrying/rebuilding.
-
-## Infrastructure issues
-
-In the event that an infrastructure issue affects the PR build, @dnceng and/or team members should be contacted. Examples of infrastructure issues are **CI leg timeouts**, repository clone errors, permission denied errors, etc. In addition, the leg should be retried, unless retrying multiple times encounters the same infrastructure issue each time.
+++ /dev/null
-# Pull Request Builds
-
-As part of our Pull Requests we have some validation builds where we build the product and run tests on different Operating Systems and Build Configurations.
-
-### Build Matrix
-
-| Build | Framework | Builds Tests | Runs Tests |
-|:---|:---:|:---:|:---:|
-| Windows x86_Release | netcoreapp | X | X |
-| Windows x64_Debug | netcoreapp | X | X |
-| Windows NETFX_x86_Release | netfx | X | X |
-| Linux x64_Release | netcoreapp | X | X |
-| Linux arm64_Release | netcoreapp | X | X |
-| Linux arm_Release | netcoreapp | X | |
-| Linux musl_x64_Debug | netcoreapp | X | |
-| MacOS x64_Debug | netcoreapp | X | X |
-| Packaging All Configurations x64_Debug | all | X | X |
-
-Our build definitions are defined by some `.yml` files with the following structure:
-
-- Entrypoint `.azure-pipelines.yml`
-- Shared build steps `eng/pipelines/corefx-base.yml`
-- Helix step `eng/pipelines/helix.yml`
-- Windows Matrix `eng/pipelines/windows.yml`
-- Linux Matrix `eng/pipelines/linux.yml`
-- MacOS Matrix `eng/pipelines/macos.yml`
-
-## Available builds
-
-- corefx-ci (Runs by default on every commit)
-- corefx-outerloop-linux
-- corefx-outerloop-osx
-- corefx-outerloop-windows
-
-### Azure pipelines commands
-
-```
-/azp help (displays help message)
-/azp run (runs all builds listed above)
-/azp run <build name> (/azp run corefx-outerloop-linux)
-```
-
-`/azp` is a shortcut for `/AzurePipelines` which can be used as well.
-
-In order to use comment triggers, at the moment you need to be a `Collaborator` or `Member` of the repo.
-
-## How to look at a build failure
-
-First, you need to click in the `details` button on the right hand side of the build you're interested in looking at. That will redirect you to the `Checks` tab within that PR, which will have a summary of that build.
-
-To get to the actual build, you will need an extra step here. You have two options:
- 1. Click on `View more details on Azure Pipelines`:
- 2. Click on `errors / warnings` summary hyperlink.
-
-Once in the build UI you can look at a specific job, or step log, by clicking on them directly.
-
-## How to look at a test failure
-
-Use the Azure DevOps Test Explorer which lists all tests grouped by the different build configurations. You can filter and navigate through the results and look at stack traces, and detailed logs.
-
-## How to rerun builds
-
-In order to rerun a build, it can be done through comments, the checks tab through the `rerun` button, or in the build UI on the right top corner, under the `...` submenu you will find a `retry` button.
-
-Unfortunately, `rerun` button on checks tab and `retry` button in build's UI are only available for contributors that are part of the Microsoft organization.
-
-## Access a build binlog
-
-We publish binlogs as part of our PR builds to make weird build errors easier to diagnose. In order to find these, you can find them via the build UI:
-
- 1. If the build is still running, you can click on the `...` submenu and there will be an `Artifacts` entry.
- 2. If the build is done, on the top right corner, there will be a big blue button called `Artifacts`.
-
-Once you click under the `Artifacts` section, a popup will show, with multiple directories, one for each build leg. Under this directory, you will find every binlog produced as part of the build.
-
-# Known Issues
-
- 1. Multiline comments are not supported, so if you want to trigger multiple builds, you have to do it on separate comments. Also, everything after `/azp run` is considered the build name, so a comment trigger can't have anything after it. [See a real example](https://github.com/dotnet/corefx/pull/35322#issuecomment-4638363830).
- 2. Feature request: trigger multiple builds with one `/azp` call. I.e `/azp run corefx-ci, corefx-outerloop-osx`.
- 3. Feature request: `/azp help` doesn't list available builds for the repo.
- 4. Only an entire pipeline can be triggered through comments, triggering a single leg is not supported yet. `/azp run corefx-ci (macOS x64_Debug)` wouldn't work.
- 5. Rerunning a single leg while others are still running is not yet supported, you have to wait for all legs to finish before retrying an individual leg.
-
-All of this issues have been raised to Azure DevOps teams, expect @safern, to update the docs through PR to widely communicate new features coming.
+++ /dev/null
-# Making your libraries compatible with .NET Core and other .NET Platforms
-
-Want to make your libraries multi-platform? Want to see how much work is required to make your application compatible with other .NET platforms? The [**.NET Portability Analyzer**](http://github.com/microsoft/dotnet-apiport) is a tool that provides you with a detailed report ([example report](http://dotnet.github.io/port-to-core/Moq4_ApiPortabilityAnalysis.htm)) on how portable your code is across .NET platforms by analyzing assemblies. The Portability Analyzer is offered as a Visual Studio Extension and as a console app.
-
-## How to Use Portability Analyzer
-
-To begin using the .NET Portability Analyzer, download the extension from the Visual Studio Gallery. You can configure it in Visual Studio via *Tools* >> *Options* >> *.NET Portability Analyzer* and select your Target Platforms.
-
-
-
-To analyze your entire project, right-click on your project in the Solution Explorer and select *Analyze* >> *Analyze Assembly Portability*. Otherwise, go to the Analyze menu and select *Analyze Assembly Portability*. From there, select your project's executable or .dll.
-
-
-
-After running the analysis, you will see your .NET Portability Report. Only types that are unsupported by a target platform will appear in the list and you can review recommendations in the **Messages** tab in the **Error List**. You can also jump to problem areas directly from the **Messages** tab.
-
-
-
-Don't want to use Visual Studio? You can also use the Portability Analyzer from the Command Prompt. Download the command-line analyzer [here](http://github.com/microsoft/dotnet-apiport/releases).
-
-- Type the following command to analyze the current directory: `ApiPort.exe analyze -f . `
-- To analyze a specific list of .dlls type the following command: `ApiPort.exe analyze -f first.dll -f second.dll -f third.dll`
-
-Your .NET Portability Report will be saved as an Excel .xlsx file in your current directory. The **Details** tab in the Excel Workbook will contain more info.
-
-For more info on the .NET Portability Analyzer, read the [documentation](https://github.com/Microsoft/dotnet-apiport/blob/master/docs/HowTo/Introduction.md).
projects / platform / upstream / dotnet / runtime.git / commitdiff
