-
Notifications
You must be signed in to change notification settings - Fork 25
dev Branch Instructions
This branch is for testing of the latest builds of ASP.NET Core and .NET Core. This is somewhat unstable and may break from time to time. Use one of the other branches for a stable experience.
The instructions here assume that you need to test latest builds and may need to substitute private builds of CoreCLR to do so. Everything here is hardcoded to win7-x64.
Clone the JitBench Repo
git clone <JitBench repo>
cd JitBench
Get the newest dotnet Shared Runtime as 'repo local'
Windows
.\Dotnet-Install.ps1 -SharedRuntime -InstallDir .dotnet -Channel master -Architecture x64`
.\Dotnet-Install.ps1 -InstallDir .dotnet -Channel master -Architecture x64
OSX
./dotnet-install.sh -sharedruntime -runtimeid osx.10.12-x64 -installdir .dotnet -channel master -architecture x64
source ./dotnet-install.sh -installdir .dotnet -channel master -architecture x64
Linux
./dotnet-install.sh -sharedruntime -runtimeid linux-x64 -installdir .dotnet -channel master -architecture x64
source ./dotnet-install.sh -installdir .dotnet -channel master -architecture x64
You need to run both of these commands in this particular order. This will grab the latest shared runtime and SDK and copy them to <JitBench>\.dotnet. Note you need to source the second script so that it can update your $PATH.
You should also have this version of dotnet on your path at this point. dotnet --info will print the version and it should match what you see in the output of the above commands.
Modify the shared framework (if necessary).
If you need to use a private build of the JIT or other CoreCLR components, now is a good time to update the shared framework with your bits. Copy any binaries you need to use into the shared framework in <JitBench>\.dotnet\shared\Microsoft.NETCore.App\<version>. The version should match the version that downloaded in step 1.
Generate Crossgen/R2R binaries locally
Windows
.\AspNet-GenerateStore.ps1 -InstallDir .store -Architecture x64 -Runtime win7-x64
OSX
source ./aspnet-generatestore.sh -i .store --arch x64 -r osx.10.12-x64
This will generate new crossgen/R2R images locally using the same shared framework version
This step will also set some environment variables that affect the behavior of the subsequent commands. You'll see in the console output some of the information about the environment variables that were set.
This step assumes the latest version of ASP.NET and the shared framework. Use the -AspNetVersion and -FrameworkVersion parameters to override these.
Install the ASP.NET binaries
.\AspNet-Install.ps1 -InstallDir .aspnet -Architecture x64
This will retrieve a zip of pre-optimized ASP.NET binaries and extract them for use with the MusicStore application. This may take a few minutes.
This step will also set some environment variables that affect the behavior of the subsequent commands. You'll see in the console output some of the information about the environment variables that were set.
This step assumes the latest version of ASP.NET and the shared framework. Use the -AspNetVersion and -FrameworkVersion parameters to override these.
Restore dependency packages
cd src\MusicStore
dotnet restore
You should see that all of the ASP.NET dependencies that get restored during this stage have the same version number as the output of step 3.
Build/publish MusicStore
Windows
dotnet publish -c Release -f netcoreapp2.0 --manifest $env:JITBENCH_ASPNET_MANIFEST (powershell)
OR
dotnet publish -c Release -f netcoreapp2.0 --manifest %JITBENCH_ASPNET_MANIFEST% (cmd)
OSX
dotnet publish -c Release -f netcoreapp2.0 --manifest $JITBENCH_ASPNET_MANIFEST
This will publish the app to bin\Release\netcoreapp2.0\publish. You should only see the MusicStore.dll and a few other project related assest here if you passed the --manifest argument.
Run the app
cd bin\Release\netcoreapp2.0\publish
dotnet MusicStore.dll
You should see console output like:
Server started in 1723ms
Starting request to http://localhost:5000
Response: OK
Request took 3014ms
Cold start time (server start + first request time): 4737ms
Running 100 requests
Steadystate min response time: 4ms
Steadystate max response time: 15ms
Steadystate average response time: 4ms
For an intro to dotnet CLI I suggest referring to their docs. We'll describe some of the steps here, but you should refer to the CLI docs as the primary source of information about CLI. If you have issues with the CLI please log them here.
This uses dotnet store to generate an optimized package store under .store. If you want to get an updated set of ASP.NET libraries, start at this step.
This command will also output some messages about environment variables that it sets. Here's a quick guide:
Setting JITBENCH_ASPNET_VERSION to 2.0.0-preview1-24493
This means that the latest build of ASP.NET available at this time is 2.0.0-preview1-24493. This environment variable will 'pin' the versions of the ASP.NET dependencies in the .csproj to match exactly the binaries that we just pulled down. There's no magic here, look at the .csproj to see how this works.
Setting JITBENCH_FRAMEWORK_VERSION to 2.0.0-preview2-002062-00
This means that the version of the shared framework that was selected was 2.0.0-preview2-002062-00. This environment variable will 'pin' the versions of the shared framework in the .csproj to match exactly the binaries that we just pulled down. There's no magic here, look at the .csproj to see how this works.
Setting JITBENCH_ASPNET_MANIFEST to D:\k\JitBench\.aspnet\AspNet.win-2.0.0-preview1-24493\x86\netcoreapp2.0\artifact.xml
This file artifact.xml is a listing of all of the packages that are included in the payload. If you look in this directory, you'll find a hierarchy that's very similar to a NuGet package hive. This environment variable will be used later by publishing to filter the set of packages that are copied to the publish output.
Setting DOTNET_SHARED_STORE to D:\k\JitBench\.aspnet\AspNet.win-2.0.0-preview1-24493
This variable is probed by the dotnet host as an additional set of packages that the runtime can use. Note that the binaries here will only be used if they match and if they are not present in 'bin'. That's why the two other environment variables are important! See here for a more thorough description.
This downloads pre-optimized ASP.NET binaries and unzips them under .aspnet. If you want to get an updated set of ASP.NET libraries, start at this step.
This command will also set the same environment variables as step 3a.
This will restore package and runtime dependencies. In general we already have these on the machine, we just need to update the generated files.
This step will use the environment variables JITBENCH_ASPNET_VERSION and JITBENCH_FRAMEWORK_VERSION to pin the version of the ASP.NET libraries and shared framework based on Step 3.
This will build and publish the application in the Release configuration and targeting netcoreapp20 as the target framework. netcoreapp20 is what we refer to as the shared framework.
The --manifest argument specifies a list of binaries that are already present in a 'shared' location. Now this 'shared' location was created by step 2, and the list of files is stored in the JITBENCH_ASPNET_MANIFEST environment variable. Since these binaries weren't copied to the publish output, they will be loaded instead from DOTNET_SHARED_STORE. See here for a more thorough description.
Runs the app. We're using the shared framework so the actual .exe that runs here is dotnet.exe. The app itself is a .dll with a Main(...) method. It's very important that you do this with pwd set to the publish folder. The app will use the pwd to determine where view templates are located.