You've already forked linux-packaging-mono
Imported Upstream version 5.2.0.175
Former-commit-id: bb0468d0f257ff100aa895eb5fe583fb5dfbf900
This commit is contained in:
Xamarin Public Jenkins (auto-signing)
parent
4bdbaf4a88
commit
966bba02bb
@@ -1,52 +0,0 @@
|
||||
# Building Tests Against Packages
|
||||
|
||||
## Usage Scenarios
|
||||
|
||||
### Build the product locally and then test what you've built
|
||||
|
||||
In this scenario, you produce a product build, including packages, then generate test project.json's which reference the locally built package versions and finally build tests compiling against the local packages.
|
||||
|
||||
1. Build the product and packages
|
||||
- ```Build.cmd -BuildTests=false```
|
||||
2. Generate Test project.json files
|
||||
- ```sync.cmd -t -- /p:"SkipCleanPackages=true" /p:"PackagesDrops=[ProjectDir]bin/packages/[Release|Debug]/"```
|
||||
- /p:SkipCleanPackages=true is required for release branches where the packages folder is cleaned during every build.
|
||||
3. Build Tests against packages
|
||||
- ```build-tests.cmd -BuildTestsAgainstPackages -- /p:"PackagesDrops=[ProjectDir]bin/packages/[Release|Debug]/"```
|
||||
- -BuildTestsAgainstPackages tells the build to use the project.json files you generated in the "Generate Test project.json files" step
|
||||
- /p:"PackagesDrops=[ProjectDir]bin/packages/[Release|Debug]/" tells the build to use the packages from your local build drop.
|
||||
|
||||
### Download product from an Azure blob
|
||||
|
||||
This scenario skips the product build step, and instead downloads packages from Azure blob storage
|
||||
|
||||
1. Sync product from Azure
|
||||
- ```sync.cmd -ab -AzureAccount=dotnetbuildoutput -AzureToken=******** -Container=[Azure container name] -- /p:"DownloadDirectory=[ProjectDir]Packages\AzureTransfer" /p:"SkipCleanPackages=true"```
|
||||
2. Generate Test project.json files
|
||||
- ```sync.cmd -t -- /p:"SkipCleanPackages=true" /p:"PackagesDrops=[ProjectDir]Packages/AzureTransfer/[Release|Debug]/"```
|
||||
- /p:SkipCleanPackages=true is required for release branches where the packages folder is cleaned during every build.
|
||||
3. Build Tests against packages
|
||||
- ```build-tests.cmd -BuildTestsAgainstPackages -- /p:"PackagesDrops=[ProjectDir]Packages/AzureTransfer/[Release|Debug]/"```
|
||||
- -BuildTestsAgainstPackages tells the build to use the project.json files you generated in the "Generate Test project.json files" step
|
||||
- /p:"PackagesDrops=[ProjectDir]Packages/AzureTransfer/[Release|Debug]/" tells the build to use the packages from the Azure download (DownloadDirectory).
|
||||
|
||||
### Use a versions file for specifying package versions
|
||||
|
||||
This scenario uses a versions file (https://github.com/dotnet/versions/blob/master/build-info/dotnet/corefx/master/Latest_Packages.txt, for example) to determine what package versions to build tests against.
|
||||
|
||||
1. Generate Test project.json files using a 'versions' file.
|
||||
- ```sync.cmd -t -- /p:"SkipCleanPackages=true" /p:"VersionsFiles=[local version file path]"```
|
||||
- /p:SkipCleanPackages=true is required for release branches where the packages folder is cleaned during every build.
|
||||
2. Build Tests against packages
|
||||
- ```build-tests.cmd -BuildTestsAgainstPackages -- /p:"PackagesDrops=[ProjectDir]bin/packages/[Release|Debug]/"```
|
||||
- -BuildTestsAgainstPackages tells the build to use the project.json files you generated in the "Generate Test project.json files" step
|
||||
- /p:"PackagesDrops=[ProjectDir]bin/packages/[Release|Debug]/" tells the build to use the packages from your local build drop.
|
||||
- If the package versions you are referencing have been published publically, you can omit the "PackagesDrops" property.
|
||||
|
||||
## Common Questions
|
||||
|
||||
- **How do I know it worked?** The best way is to look in the log for the compilation line ("csc.exe") and ensure that its references now point to packages (packages\blah) where previously they pointed to build product binaries (bin\blah).
|
||||
|
||||
- **Why are there build failures?** Not all of our tests build nicely against package references due to differences in the public surface area (compiling against the reference assembly versus an implementation assembly). In cases where we were unable to sync / restore (packages were unavailable or other restore problems), we've opted those projects out of this process by adding "KeepAllProjectReferences" or "KeepProjectReference" (added to a Project Reference's metadata) to the test project.
|
||||
|
||||
- **Where are the generated project.json files?** Generated project.json files get created under "[ProjectDir]bin/obj/generated".
|
||||
@@ -1,9 +1,7 @@
|
||||
Code Coverage
|
||||
=============
|
||||
|
||||
"Code coverage" is a measure that indicates how much of our library code is exercised by our test suites. We measure code coverage using the [OpenCover](https://github.com/opencover/opencover), and a report of our latest code coverage results can be seen by clicking the coverage badge on the [CoreFX home page](https://github.com/dotnet/corefx):
|
||||
|
||||
[](http://dotnet-ci.cloudapp.net/job/dotnet_corefx_coverage_windows/lastBuild/Code_Coverage_Report/)
|
||||
"Code coverage" is a measure that indicates how much of our library code is exercised by our test suites. We measure code coverage using the [OpenCover](https://github.com/opencover/opencover), and a report of our latest code coverage results can be seen by clicking the coverage badge on the [CoreFX home page](https://github.com/dotnet/corefx), linking to the latest [Coverage Report](https://ci.dot.net/job/dotnet_corefx/job/master/job/code_coverage_windows/Code_Coverage_Report/).
|
||||
|
||||
This report shows each library currently being tested with code coverage and provides statistics around the quality of the code coverage for the library. It also provides a line-by-line breakdown of what lines are being covered and what lines are not.
|
||||
|
||||
@@ -30,6 +28,16 @@ An issue need not be addressed in its entirety. We happily accept contributions
|
||||
|
||||
Code coverage runs are performed by Jenkins approximately twice a day. The results of these runs are all available from the site linked to by the code coverage badge on the home page.
|
||||
|
||||
## PR Code Coverage Runs
|
||||
|
||||
Jenkins can create a coverage report using your PR. Ask for it using `@dotnet-bot test code coverage please`.
|
||||
|
||||
After it's done the report can be found in the build log, it looks like eg
|
||||
`https://ci.dot.net/job/dotnet_corefx/job/master/job/code_coverage_windows_prtest/16/artifact/bin/tests/coverage`
|
||||
then add index.htm on the end:
|
||||
`https://ci.dot.net/job/dotnet_corefx/job/master/job/code_coverage_windows_prtest/16/artifact/bin/tests/coverage/index.htm`
|
||||
You can navigate to this from your PR by clicking the "Details" link to the right of the code coverage job listed at the bottom of the PR after having issued the above request to dotnet-bot. In the Jenkins UI for the resulting build, click the "Build Artifacts" link and navigate through the resulting hierarchy to the index.htm file.
|
||||
|
||||
## Local Code Coverage Runs
|
||||
|
||||
You can perform code coverage runs locally on your own machine. Normally to build your entire CoreFX repo, from the root of your repo you'd run:
|
||||
@@ -50,11 +58,11 @@ You can also build and test with code coverage for a particular test project rat
|
||||
|
||||
msbuild /t:BuildAndTest
|
||||
|
||||
To do so with code coverage, as with ```build``` append the ```/p:Coverage=true``` argument:
|
||||
To do so with code coverage, append the ```/p:Coverage=true``` argument:
|
||||
|
||||
msbuild /t:BuildAndTest /p:Coverage=true
|
||||
|
||||
The results for this one library will then also show up in the aforementioned index.htm file. For example, to build, test, and get code coverage results for the System.Diagnostics.Debug library, from the root of my repo I can do:
|
||||
The results for this one library will then show up in the aforementioned index.htm file. For example, to build, test, and get code coverage results for the System.Diagnostics.Debug library, from the root of the repo one can do:
|
||||
|
||||
cd src\System.Diagnostics.Debug\tests\
|
||||
msbuild /t:BuildAndTest /p:Coverage=true
|
||||
@@ -63,22 +71,11 @@ And then once the run completes:
|
||||
|
||||
..\..\..\bin\tests\coverage\index.htm
|
||||
|
||||
## Code coverage with mscorlib code
|
||||
## Code coverage with System.Private.CoreLib code
|
||||
|
||||
Some of the libraries for which contracts and tests live in the corefx repo are actually implemented in the core runtime library in another repo, e.g. the implementation that backs the System.Runtime contract is in System.Private.Corlib.dll in either the coreclr or corert repo. To run coverage reports for these projects, you need to build mscorlib locally from the coreclr repo.
|
||||
Some of the libraries for which contracts and tests live in the corefx repo are actually fully or partially implemented in the core runtime library in another repo, e.g. the implementation that backs the System.Runtime contract is in System.Private.CoreLib.dll in either the coreclr or corert repo. To run coverage reports for these projects, you need to build System.Private.CoreLib locally from the coreclr repo. To get coverage of System.Private.CoreLib while running the tests for a particular library:
|
||||
|
||||
The following steps can be used manually to produce a coverage report, but a customizable batch file can be found [here](facade-code-coverage.bat). Changing the parameters in the first couple of lines lets you run a coverage report easily for any facade project.
|
||||
1. Follow the steps outlined at [Testing with Private CoreClr Bits](https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/developer-guide.md#testing-with-private-coreclr-bits). Make sure to include the optional steps listed as being required for code coverage.
|
||||
2. Add /p:CodeCoverageAssemblies="System.Private.CoreLib" to the previously discussed msbuild command, e.g. msbuild /t:BuildAndTest /p:Coverage=true /p:CodeCoverageAssemblies="System.Private.CoreLib"
|
||||
|
||||
1. Build the local test project (`msbuild /T:Build`)
|
||||
3. Build coreclr locally in Debug or Release (`build.cmd all Debug skiptests`)
|
||||
2. Navigate to the built test directory in the corefx bin (e.g. `bin/tests/AnyOS.AnyCPU.Debug/System.Runtime/netcoreapp1.0` for `System.Runtime`
|
||||
4. Delete `coreclr.dll`, `mscorlib.dll`, `mscorlib.ni.dll`, `System.Private.CoreLib.dll` and `System.Private.CoreLib.ni.dll` from that directory
|
||||
5. Copy all files in the coreclr `bin` directory to the test directory
|
||||
6. Copy all files in the coreclr `bin/PDB` directory to the test directory
|
||||
7. Run an OpenCover command with `xunit.console.netcore.exe`. For example:
|
||||
|
||||
<corefx-root>/packages/OpenCover/<opencover-version>/tools/OpenCover.Console.exe -oldStyle -filter:"+[*]* -[*.Tests]* -[xunit.*]*" -excludebyfile:"*\Common\src\System\SR.*" -nodefaultfilters -excludebyattribute:*.ExcludeFromCodeCoverage* -skipautoprops -hideskipped:All -threshold:1 -returntargetcode -register:user -targetdir:<path-to corefx-bin> -target:CoreRun.exe -output:coverage.xml -targetargs:"xunit.console.netcore.exe System.Runtime.Tests -xml testResults.xml -notrait Benchmark=true -notrait category=OuterLoop -notrait category=failing -notrait category=nonwindowstests"
|
||||
|
||||
8. Run a ReportGenerator command with the generated `coverage.xml` file. For example:
|
||||
|
||||
<corefx-root>/packages/ReportGenerator/<opencover-version>/tools/ReportGenerator.exe -reporttypes:Html;Badges -reports:coverage.xml
|
||||
The resulting code coverage report should now also include details for System.Private.CoreLib.
|
||||
|
||||
@@ -103,3 +103,24 @@ prajwal@ubuntu ~/corefx $ ./scripts/arm32_ci_script.sh \
|
||||
```
|
||||
|
||||
The Linux ARM Emulator is based on the soft floating point and thus the native binaries are generated for the armel architecture. The corefx binaries generated by the above command can be found at `~/corefx/bin/Linux.armel.Release`, `~/corefx/bin/Linux.AnyCPU.Release`, `~/corefx/bin/Unix.AnyCPU.Release`, and `~/corefx/bin/AnyOS.AnyCPU.Release`.
|
||||
|
||||
|
||||
Build corefx for a new architecture
|
||||
===================================
|
||||
|
||||
When building for a new architecture you will need to build the native pieces separate from the managed pieces in order to correctly boot strap the native runtime. Instead of calling build.sh directly you should instead split the calls like such:
|
||||
|
||||
Example building for armel
|
||||
```
|
||||
build-native.sh -buildArch=armel
|
||||
--> Output goes to bin/runtime/netcoreapp-Linux-Debug-armel
|
||||
|
||||
build-managed.sh -buildArch=x64
|
||||
--> Output goes to bin/runtime/netcoreapp-Linux-Debug-x64
|
||||
```
|
||||
|
||||
The reason you need to build the managed portion for x64 is because it depends on runtime packages for the new architecture which don't exist yet so we use another existing architecture such as x64 as a proxy for building the managed binaries.
|
||||
|
||||
Similar if you want to try and run tests you will have to copy the managed assemblies from the proxy directory (i.e. `netcoreapp-Linux-Debug-x64`) to the new architecture directory (i.e `netcoreapp-Linux-Debug-armel`) and run code via another host such as corerun because dotnet is at a higher level and most likely doesn't exist for the new architecture yet.
|
||||
|
||||
Once all the necessary builds are setup and packages are published the spliting of the build and manual creation of the runtime should no longer be necessary.
|
||||
@@ -1,6 +1,6 @@
|
||||
# Running XUnit tests cross platform
|
||||
|
||||
Unlike Windows, where we run tests as part of the build, we have a seperate
|
||||
Unlike Windows, where we run tests as part of the build, we have a separate
|
||||
explicit testing step on Linux and OSX. Over time, this special step will go
|
||||
away in favor of a similar "run tests during the build" model.
|
||||
|
||||
@@ -17,12 +17,12 @@ instructions assume you are building for Linux, but are easily modifiable for OS
|
||||
|
||||
From the root of your CoreCLR enlistment on Linux, run `./build.sh Release` in
|
||||
order to build.
|
||||
2. A corresponding version of mscorlib.dll. Depending on your platform, this may
|
||||
2. A corresponding version of System.Private.Corelib.dll. Depending on your platform, this may
|
||||
be produced when you run `build.sh`. Otherwise, this can be produced by
|
||||
running `build.cmd linuxmscorlib Release` from a CoreCLR enlistment on
|
||||
Windows. Remember that the runtime and mscorlib are tightly coupled with
|
||||
running `build.cmd linuxmscorlib Release` (it's `mscorlib` for historical reasons) from a CoreCLR enlistment on
|
||||
Windows. Remember that the runtime and System.Private.Corelib are tightly coupled with
|
||||
respect to object sizes and layout so you need to ensure you have either a
|
||||
release coreclr and release mscorlib or debug coreclr and debug mscorlib.
|
||||
release coreclr and release System.Private.Corelib or debug coreclr and debug System.Private.Corelib.
|
||||
3. A Linux build of CoreFX. We currently have experimental support for building
|
||||
CoreFX on Linux via `build.sh`.
|
||||
The other option is:
|
||||
@@ -56,17 +56,15 @@ If needed, copy the packages folder:
|
||||
# rsync -v -f ~/mnt/matell3/d/git/corefx/packages ~/git/corefx/packages
|
||||
```
|
||||
|
||||
If needed, copy mscorlib:
|
||||
If needed, copy System.Private.Corelib:
|
||||
```
|
||||
# rsync -v -r ~/mnt/matell3/d/git/coreclr/bin/Product/ ~/git/coreclr/bin/Product/
|
||||
```
|
||||
|
||||
Then, run the tests. We need to pass an explict path to the location of CoreCLR
|
||||
and mscorlib.dll.
|
||||
Then, run the tests. We need to pass an explict path to the location of CoreCLR.
|
||||
|
||||
```
|
||||
# ./run-test.sh --coreclr-bins ~/git/coreclr/bin/Product/Linux.x64.Release \
|
||||
--mscorlib-bins ~/git/coreclr/bin/Product/Linux.x64.Release \
|
||||
# ./run-test.sh --coreclr-bins ~/git/coreclr/bin/Product/Linux.x64.Release
|
||||
```
|
||||
|
||||
run-test.sh should now invoke all the managed tests.
|
||||
|
||||
@@ -1,82 +0,0 @@
|
||||
@echo off
|
||||
:: Example settings for System.Runtime
|
||||
SET project=System.Runtime
|
||||
SET msbuildargs=/T:Build
|
||||
SET testsubdir=AnyOS.AnyCPU.Debug
|
||||
SET filter="+[*]* -[*.Tests]* -[*]System.Collections.* -[*]System.Diagnostics.* -[*]System.Globalization.* -[*]System.IO.* -[*]System.Reflection.* -[*]System.Resources.* -[*]System.Runtime.* -[*]System.Security.* -[*]System.StubHelpers.* -[*]System.Threading.* -[*]Microsoft.* -[*]Windows.* -[*]System.App* -[*]System.Text.Decoder* -[*]System.Text.Encoder* -[*]System.Text.*Encoding -[*]System.Text.Internal* -[xunit.*]*"
|
||||
|
||||
:: Update this when OpenCover or ReportGenerator are updated
|
||||
SET opencoverversion=4.6.519
|
||||
SET reportgeneratorversion=2.4.3
|
||||
|
||||
:: Assumes that the corefx and coreclr repo folders are in the same parent folder
|
||||
SET root=C:\Users\Hugh\Documents\Github
|
||||
|
||||
SET corefx=%root%\corefx
|
||||
SET coreclr=%root%\coreclr
|
||||
|
||||
SET packages=%corefx%\packages
|
||||
SET opencover=%packages%\OpenCover\%opencoverversion%\tools\OpenCover.Console.exe
|
||||
SET reportgenerator=%packages%\ReportGenerator\%reportgeneratorversion%\tools\ReportGenerator.exe
|
||||
|
||||
SET targetdir=%corefx%\bin\tests\%testsubdir%\%project%.Tests\netcoreapp1.0
|
||||
|
||||
SET resultsfile=testresults.xml
|
||||
SET coveragefile=coverage.xml
|
||||
|
||||
SET coveragedir=coverage
|
||||
|
||||
SET originalfolder=%cd%
|
||||
SET sourcefolder=%corefx%\src\%project%\tests
|
||||
|
||||
SET coreclrbuild=%coreclr%\bin\Product\Windows_NT.x64.Debug
|
||||
SET coreclrbuild=%coreclr%\bin\Product\Windows_NT.x64.Release
|
||||
|
||||
:: Build the library
|
||||
cd %sourcefolder%
|
||||
msbuild %msbuildargs%
|
||||
cd %originalfolder%
|
||||
|
||||
:: Delete old files (see #8381 for why)
|
||||
del %targetdir%\mscorlib.dll
|
||||
del %targetdir%\mscorlib.ni.dll
|
||||
del %targetdir%\System.Private.CoreLib.dll
|
||||
del %targetdir%\System.Private.CoreLib.ni.dll
|
||||
del %targetdir%\coreclr.dll
|
||||
del %targetdir%\CoreRun.exe
|
||||
del %targetdir%\CoreConsole.exe
|
||||
del %targetdir%\clretwrc.dll
|
||||
del %targetdir%\clrjit.dll
|
||||
del %targetdir%\dbgshim.dll
|
||||
del %targetdir%\mscordaccore.dll
|
||||
del %targetdir%\mscordbi.dll
|
||||
del %targetdir%\mscorrc.debug.dll
|
||||
del %targetdir%\mscorrc.dll
|
||||
del %targetdir%\sos.dll
|
||||
|
||||
:: Copy over our local build files
|
||||
For %%a in (
|
||||
%coreclrbuild%\mscorlib.dll
|
||||
%coreclrbuild%\PDB\mscorlib.pdb
|
||||
%coreclrbuild%\System.Private.CoreLib.dll
|
||||
%coreclrbuild%\PDB\System.Private.CoreLib.pdb
|
||||
%coreclrbuild%\coreclr.dll
|
||||
%coreclrbuild%\PDB\coreclr.pdb
|
||||
%coreclrbuild%\CoreRun.exe
|
||||
%coreclrbuild%\CoreConsole.exe
|
||||
%coreclrbuild%\clretwrc.dll
|
||||
%coreclrbuild%\clrjit.dll
|
||||
%coreclrbuild%\dbgshim.dll
|
||||
%coreclrbuild%\mscordaccore.dll
|
||||
%coreclrbuild%\mscordbi.dll
|
||||
%coreclrbuild%\mscorrc.debug.dll
|
||||
%coreclrbuild%\mscorrc.dll
|
||||
%coreclrbuild%\sos.dll
|
||||
) do copy /b/v/y "%%~a" "%targetdir%\"
|
||||
|
||||
:: Now, run the actual tests and generate a coverage report
|
||||
SET corerunargs=%targetdir%\xunit.console.netcore.exe %project%.Tests.dll -xml %resultsfile% -notrait category=OuterLoop -notrait category=failing -notrait category=nonwindowstests
|
||||
|
||||
%opencover% -oldStyle -filter:%filter% -excludebyfile:"*\Common\src\System\SR.*" -nodefaultfilters -excludebyattribute:*.ExcludeFromCodeCoverage* -skipautoprops -hideskipped:All -threshold:1 -returntargetcode -register:user -targetdir:%targetdir% -target:CoreRun.exe -output:%coveragefile% -targetargs:"%corerunargs%"
|
||||
|
||||
%reportgenerator% -targetdir:%coveragedir% -reporttypes:Html;Badges -reports:%coveragefile% -verbosity:Error
|
||||
39
external/corefx/Documentation/building/pinvoke-checker.md
vendored
Normal file
39
external/corefx/Documentation/building/pinvoke-checker.md
vendored
Normal file
@@ -0,0 +1,39 @@
|
||||
# PInvoke Analyzer
|
||||
|
||||
During the build of any product library in CoreFX we use a Roslyn code analyzer to look for disallowed native calls (PInvokes). When there is a violation, it will fail the build. To fix the build, either find an alternative to the PInvoke or baseline the failure temporarily. To baseline it, add the function name in the format `module!entrypoint` to a file named PInvokeAnalyzerExceptionList.analyzerdata in the same folder as the project. [Here](https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.Process/src/PInvokeAnalyzerExceptionList.analyzerdata) is an example.
|
||||
|
||||
If you baseline a violation, please open an issue to fix it because the library likely cannot ship in this situation. It is better to not introduce the violation. We want to clean out any baselines. There are situations where a violation may be acceptable. One situation is where we are shipping the native implementation of the API. An example of this situation is `sni.dll` which is used by SqlClient.
|
||||
|
||||
Each project is analyzed against one of two possible lists we maintain.
|
||||
|
||||
## Legal UWP API's
|
||||
|
||||
### Applies to
|
||||
This applies to product libraries that are being built for use in a modern Windows app (aka UWP app, or app running on UAP). When building the `uapaot` or `uap` configurations we will apply this check. If the library does not have a `uap` or `uapaot` configuration explicitly listed in `Configuration.props` in the project folder, when targeting `uap` or `uapaot` we will build the `netstandard` configuration, and apply this check.
|
||||
|
||||
We do not currently apply this check to test binaries. Although when testing UWP libraries the tests must run within a test app, they do not need to pass through the store validation process. It is still possible they may call an API that does not work correctly within an app's security boundary and that call would have to be avoided.
|
||||
|
||||
### Motivation
|
||||
Not all PInvokes are legal within a UWP app. An allow-list is enforced when the Windows store ingests an app, and also in a build step in the Visual Studio build process for apps. If we produce a library for UWP use, any PInvokes it performs must be to API's that are on the allow-list or the app using the library will fail validation.
|
||||
|
||||
### Implementation
|
||||
To enforce this the analyzer consults the list [here](https://github.com/dotnet/buildtools/blob/master/src/Microsoft.DotNet.CodeAnalysis/PackageFiles/PinvokeAnalyzer_Win32UWPApis.txt).
|
||||
|
||||
The analyzer is enabled by default in the configurations below by the setting of the MSBuild property `UWPCompatible`. We aim to make all our `netstandard` compliant libraries work within a UWP app, but in rare cases where a library cannot, the check can be disabled with `<UWPCompatible>false</UWPCompatible>` in the project file.
|
||||
|
||||
There is also a more fine grained property `<EnablePInvokeUWPAnalyzer>false</EnablePInvokeUWPAnalyzer>` for temporary use.
|
||||
|
||||
## Legal OneCore API's
|
||||
|
||||
### Applies to
|
||||
This applies to all other product libraries in all other configurations targeted at Windows.
|
||||
|
||||
We do not currently apply this check to test binaries as they do not need to run on Windows Nano.
|
||||
|
||||
### Motivation
|
||||
.NET Core supports execution on Windows Nano, which has a reduced API surface area known as OneCore. To run on Windows Nano we cannot invoke any platform API that is not available on OneCore.
|
||||
|
||||
### Implementation
|
||||
To enforce this the analyzer consults the list [here](https://github.com/dotnet/buildtools/blob/master/src/Microsoft.DotNet.CodeAnalysis/PackageFiles/PinvokeAnalyzer_Win32Apis.txt).
|
||||
|
||||
The analyzer is enabled by default when building for Windows, not a test, and not building for UWP. We aim to make all such configurations OneCore compilant, but in the rare cases where a library cannot be, the check can be disabled with `<EnablePInvokeAnalyzer>false<EnablePInvokeAnalyzer>` in the project file.
|
||||
@@ -1,6 +1,6 @@
|
||||
Building CoreFX on FreeBSD, Linux and OS X
|
||||
==========================================
|
||||
##Building
|
||||
## Building
|
||||
|
||||
1. Install the prerequisites ([Linux](#user-content-linux), [macOS](#user-content-macos))
|
||||
2. Clone the corefx repo `git clone https://github.com/dotnet/corefx.git`
|
||||
@@ -72,7 +72,7 @@ but the headers are no longer available since that library version is out of sup
|
||||
Some compilers get upset over new headers being in `/usr/local/include` with the old library being present at
|
||||
`/usr/lib/libcrypto.dylib` (the tools have no issue with the versioned files, e.g. `/usr/lib/libcrypto.0.9.8.dylib`),
|
||||
and so Homebrew does not allow the OpenSSL package to be installed into system default paths. A minimal installation
|
||||
is presented here to facilitiate simplifying runtime requirements and compile-time requirements (for build systems using
|
||||
is presented here to facilitate simplifying runtime requirements and compile-time requirements (for build systems using
|
||||
CMake's `find_package`, like ours):
|
||||
```sh
|
||||
# We need to make the runtime libraries discoverable, as well as make
|
||||
|
||||
@@ -34,7 +34,7 @@ In the case of packages, there is one small difference compared to the assembly
|
||||
How does the Official Build workflow works
|
||||
------------------------------------------
|
||||
|
||||
Our Official Builds are a little different than the regular dev flow, and that is because Official Builds need the ability to not only force a specific BuildNumberMinor, but also a BuildNumberMajor. The way they do it, is by passing in the parameter `OfficialBuildId` which specifies the SeedDate that should be used and the revision of the build. For example, the following invocation: `build.cmd -OfficialBuildId=20160523.99` will use May 23 2016 as the SeedDate to generate the version, and it will set '99' as the BuildNumberMinor. With this funcionality, our OfficialBuilds are able to have an orchestrator that triggers different builds and force all of them to have the same version.
|
||||
Our Official Builds are a little different than the regular dev flow, and that is because Official Builds need the ability to not only force a specific BuildNumberMinor, but also a BuildNumberMajor. The way they do it, is by passing in the parameter `OfficialBuildId` which specifies the SeedDate that should be used and the revision of the build. For example, the following invocation: `build.cmd -OfficialBuildId=20160523.99` will use May 23 2016 as the SeedDate to generate the version, and it will set '99' as the BuildNumberMinor. With this functionality, our OfficialBuilds are able to have an orchestrator that triggers different builds and force all of them to have the same version.
|
||||
|
||||
Getting the version of a native binary in non-Windows platforms
|
||||
========================================================
|
||||
|
||||
@@ -5,16 +5,38 @@ You can build .NET Core either via the command line or by using Visual Studio.
|
||||
|
||||
## Required Software
|
||||
|
||||
Visual Studio 2015 is required.
|
||||
Visual Studio must be installed. Supported versions:
|
||||
* [Visual Studio 2015](https://www.visualstudio.com/vs/older-downloads/) (Community, Professional, Enterprise). The community version is completely free.
|
||||
* [Visual Studio 2017](https://www.visualstudio.com/downloads/) (Community, Professional, Enterprise). The community version is completely free.
|
||||
|
||||
The following free downloads are compatible:
|
||||
* [Visual Studio Community 2015](http://www.visualstudio.com/en-us/downloads/visual-studio-2015-downloads-vs)
|
||||
For Visual Studio 2015:
|
||||
* In order to build our C++ projects be sure to select "Programming Languages | Visual C++ | Common Tools for Visual C++ 2015" while installing VS 2015 (or modify your install to include it).
|
||||
* We also require that [Visual Studio 2015 Update 1](https://www.visualstudio.com/en-us/news/vs2015-update1-vs.aspx) be installed.
|
||||
|
||||
Note: In order to build our C++ projects be sure to select "Programming Languages | Visual C++ | Common Tools for Visual C++ 2015" while installing VS 2015 (or modify your install to include it).
|
||||
For Visual Studio 2017:
|
||||
* When doing a 'Workloads' based install, the following are the minimum requirements:
|
||||
* .NET Desktop Development
|
||||
* All Required Components
|
||||
* .NET Framework 4-4.6 Development Tools
|
||||
* Desktop Development with C++
|
||||
* All Required Components
|
||||
* VC++ 2017 v141 Toolset (x86, x64)
|
||||
* Windows 8.1 SDK and UCRT SDK
|
||||
* VC++ 2015.3 v140 Toolset (x86, x64)
|
||||
* When doing an 'Individual Components' based install, the following are the minimum requirements:
|
||||
* C# and Visual Basic Roslyn Compilers
|
||||
* Static Analysis Tools
|
||||
* .NET Portable Library Targeting Pack
|
||||
* Windows 10 SDK or Windows 8.1 SDK
|
||||
* Visual Studio C++ Core Features
|
||||
* VC++ 2017 v141 Toolset (x86, x64)
|
||||
* MSBuild
|
||||
* .NET Framework 4.6 Targeting Pack
|
||||
* Windows Universal CRT SDK
|
||||
* VC++ 2015.3 v140 Toolset (x86, x64)
|
||||
* Ensure you are running from the "Developer Command Prompt for VS2017"; Otherwise, the build will attempt to locate and use the VS2015 toolset.
|
||||
|
||||
We also require that [Visual Studio 2015 Update 1](https://www.visualstudio.com/en-us/news/vs2015-update1-vs.aspx) be installed.
|
||||
|
||||
[CMake](https://cmake.org/) is required to build the native libraries for Windows. To build these libraries cmake must be installed from [the CMake download page](https://cmake.org/download/) and added to your path.
|
||||
[CMake](https://cmake.org/) is required to build the native libraries for Windows. To build these libraries cmake must be installed from [the CMake download page](https://cmake.org/download/#latest) and added to your path.
|
||||
|
||||
## Building From the Command Line
|
||||
|
||||
@@ -35,6 +57,11 @@ Only use it when the parameters that you are passing to the script apply for bot
|
||||
|
||||
For more information about the different options when building, run `build.cmd -?` and look at examples in the [developer-guide](../project-docs/developer-guide.md).
|
||||
|
||||
### Running tests from the command line
|
||||
|
||||
From the root, use `build-tests.cmd`.
|
||||
For more details, or to test an individual project, see the [developer guide topic](https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/developer-guide.md).
|
||||
|
||||
### Running tests from Visual Studio
|
||||
|
||||
1. Open solution of interest
|
||||
|
||||
Reference in New Issue
Block a user