.NET Standard 2.0 Automated Error Reporting not woking

mrmiagi0101

Hello,

I'm using the trial verion of SA 7.

I have created a simple WPF exe (and enabled error reporting) which references a .NET Standard 2.0 class library dll. If I also enable now Automated Error reporting in the class library I get an "System.IO.FileNotFoundException: Die Datei oder Assembly "Microsoft.Win32.Registry, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden." exception as soon the assembly is loaded while running the WPF exe.

At:

bei SmartAssembly.Shared.AppPathFinder.ReadInstalledSaPath():
bei SmartAssembly.License.License.():
bei SmartAssembly.License.License.ValidateDLL():

There is no such error if I do not enable error reporting in the dll and only in the exe. But this will disable the additional informations like method params or line numbers from methodes in the dll.

How to fix this problem, because our application relies on many .NET Standard 2.0 assemblies?

Jessica R

Hi @mrmiagi0101,

This should be fixed in today's release 7.0.3.2212. I hope that helps but please let me know if any issues remain!

Jessica R

Hi @mrmiagi0101,

Thanks for your post and sorry to hear you're running into an issue!

It looks like this is an issue with the trial version and I've been able to reproduce it. Thanks for bringing it to our attention!

I'm going to raise this with our developers and will let you know once we have an update.

mrmiagi0101

I decompiled the created .net standard dll modified by SA. The problem is, you are injecting the same code as for .NET framewrok assemblies including checking registry. For this you also add a reference to a "Microsoft.Win32.Registry" dll. But this dll does not exist.

There would be a ugly workaround by adding the "Microsoft.Win32.Registry" nuget to the .net standard dll and use one of its classes. But this would add a windows os dependency to this lib, which is not possible.

Maybe this can help.

Jessica R

Thanks for your help with looking into this, @mrmiagi0101!

I agree that would be an undesirable workaround and I think this is an issue that just needs to be sorted out in our code- I've already let our developers know and we'll hopefully have a fix soon. I'll post any updates here.

mrmiagi0101

Yes, it seems to work now with .Net Standard also. Thank you very much.