Console dotTrace Session Startup Fails with "NetStandard" Error


I am trying to use the console dotTrace tool to attach to and profile a running instance of W3WP.exe (IIS) on a Windows Server Core host.

When I execute the command line 'dottrace' I receive the error message below:

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'netstandard, Version=, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
   at JetBrains.dotTrace.ConsoleProfiler.ProfilerProgram.Main(String[] args)

What is the correction for this error message?  This is directly after having unarchived the dottrace from its archive file.

Thanks for any pointers.



Hello again,

While installing the RemoteAgent as a workaround, I noticed the RemoteAgent included a copy of NetStandard.dll.  Copying this into the console dotTrace folder allowed the console dotTrace to profile sucessfully.

Hope this helps someone.



This message occurs if required .NET Framework version isn't installed on machine. Copying .dll manually isn't good way to fix it. Please install .NET Framework 4.7.2 or higher. 

Full list of system requirements is located here:



Can you please specify which version of .NET Framework is required for dotTrace Command Line Tools 2022.1.2?

I have a client single(?) PC which runs .NET Framework applications just fine, without a problems, but profiling via dotTraceCmd fails being unable to start and find netstandard. It's the first occurrence of that problem.

Have you experienced the problem on your side?

Any suggestions? May it be related to some PC restrictions (limited disc access, not administrator account etc?)?

Copying netstandard.dll also solves the problem, but I suspect there should be some other issue that is causing the problem.

Thank you.



Starting with the 2021.2 releases of our .NET productivity tools, including dotTrace and dotMemory profilers, our tools require .NET Framework 4.7.2 or newer installed on your machine.

We haven't encountered the same problem in our environment. If copying netstandard.dll helps in your case, the problem most likely relates to a missing .NET Framework version.


Please sign in to leave a comment.