dotMemory CLI with .NET Core throws exception

Hello David,

Probably you try to start .NET Core application from .dll, please use dotnet.exe to start your .NET Core application from dotMemory console, for example:

dotMemory.exe start "C:\Program Files\dotnet\dotnet.exe" -- "<PathToApplication>.dll"

Path to dotnet.exe may differ on your machine.

Don't forget to specify any trigger to get a snapshot.

Hi Anna,

Using the fully qualified path to `dotnet.exe` did the trick.

Thanks

You're welcome!

dotMemory UI contains separate ".NET Core Application" configuration which allow to specify .NET Core application path only. dotnet.exe is launched for this configuration by default.

Currently, dotMemory CLI contains only "start" command, which corresponds "Standalone" configuration, and "start-iis" command, which corresponds IIS configuration.

Thanks.

Can I analysis the snapshot file produced within the GUI?
The docs say that the CLI is suitable for CI.

David,

Could you please describe your use case in details? Do you want to analyze memory snapshots data and perform any assertions automatically on CI server?

Currently, dotMemory CLI provides only possibility to start application and get snapshots using stdin messages. We have a feature request in our tracker: https://youtrack.jetbrains.com/issue/DMRY-4677

We suggest you to pay your attention on dotMemory Unit: https://www.jetbrains.com/dotmemory/unit/

It allows you to make memory assertions in unit tests.

It's a small use case for a blog post. I want to prove that an allocation is happening when I use a certain class. Unfortunately, can't export results from the GUI in a format that's consumable by anything to reduce a plain text report.

I think I can solve the problem with the ClrMD, but your tool is nicer.

David,

If you need allocation result in text view, you can try to copy it from dotMemory interface, probably it will be useful for you. For example, copy result from Similar Retention view looks like:
1048 bytes in 1 objects of AppName.Settings.Setting[]

Main Retention Path:
Roots: Static reference
<D> AppName.Settings.App.AppSettings.settings ->
<D> System.Collections.Generic.List<AppName.Settings.Setting>._items ->
    AppName.Settings.Setting[]

Or if you copy it from Creation Stack Trace view for certain object instance:

Setting[128]

Allocation stack trace

System.Collections.Generic.List<T>.set_Capacity(Int32 value)
System.Collections.Generic.List<T>.EnsureCapacity(Int32 min)
System.Collections.Generic.List<T>.Add(T item)
AppName.Settings.SettingsView.AddSettingDuringCtor<TSetting>(TSetting setting)
AppName.Settings.SettingsView.AddSettingsDuringCtor<TSettings>(TSettings settings)
AppName.Settings.SettingsBase.RegisterSectionDuringCtor<TSection>(TSection section)
AppName.Settings.App.AppSettings.ctor(SettingsStorageHandler storageHandler)
AppName.Settings.App.AppSettings.cctor()
[Native code]
AppName.Startup.StartPart2(String mutexName, String[] remainingArgs)
AppName.Startup.Start()
AppName.Startup.Main(String[] args)
[AllThreadsRoot]

Also you can use dotMemory Unit to create a sample with test which checks for this class:

      [TestMethod]
      public void MemoryTest()
      {
        // preconditions
        dotMemory.Check(memory =>
        {
          var objectSet = memory.GetObjects(_ => _.Type.Is(typeof(MyClass)));
          Assert.IsTrue(objectSet.ObjectsCount > 0);
        });
      }

Test run result:

MemoryTest Success

Or test with AssertTraffuc attribute if this object is collected after GC:

      [AssertTraffic(AllocatedObjectsCount = 0,Types = new []{typeof(MyClass)})]
      [TestMethod]
      public void MemoryTest()
      {
        // preconditions
        dotMemory.Check(memory =>
        {
          var objectSet = memory.GetObjects(_ => _.Type.Is(typeof(MyClass)));
          Assert.IsTrue(objectSet.ObjectsCount == 0);
        });
      }

Test run result:

Number of allocated objects of type [MyClass]
Expected: 0
But was: 1