- .NET 8 app
- dotnet buildpack
- CF SSH access
We need to the dotnet CLI installed on the target application instance. To get dotnet installed and not
have the buildpack remove it during staging we need to use a Framework Dependent Deployment.
If you're running dotnet publish
on an ARM processor you need to specify the runtime as linux-x64
otherwise you will get an
error trying to start the app.
dotnet publish -r linux-x64 -c Debug
Update your application manifest path attribute to the publish directory. Your app manifest should look something like this:
---
applications:
- name: cf-dotnet-webapp
buildpacks:
- dotnet_core_buildpack
memory: 1G
stack: cflinuxfs4
path: bin/Debug/net8.0/linux-x64/publish
Now cf push
the app as normal.
Now that we have the application pushed and running we can now cf ssh
into the running app instance. From here
we need to setup a couple of things first.
Add dotnet
to the PATH env var.
export DOTNET_ROOT=/home/vcap/deps/0/dotnet-sdk
export PATH="$PATH:$DOTNET_ROOT"
Set a TMPDIR to the same directory as the running web app as the tooling requires this to be set:
export TMPDIR=/home/vcap/tmp
Install one or more performance tools. Some of the tools available:
dotnet-counters
to view Performance Counters.dotnet-dump
to capture and analyze Windows and Linux dumps.dotnet-trace
to capture runtime events, GC collections and sample CPU stacks.dotnet-gcdump
to collect GC dumps.
Install the dotnet-counters tool since this a good first place to start an investigation:
dotnet tool install dotnet-counters --global
export PATH="$PATH:/home/vcap/.dotnet/tools"
With the tooling installed we can now execute it. Each of the tools will need the PID of your .NET web app, so in our example app named cf-dotnet-webapp we use pidof to find the process id.
dotnet-counters monitor --process-id $(pidof cf-dotnet-webapp)