the project created by visual studio 2017 can not submit exception

[yunzhizhou]

when I create a project by the visual studio 2017, if the project is .net core web (.net core), it can work; but if the project is .net core web(.net framework), it can't submit exception.

1. normal

<PropertyGroup>
    <TargetFramework>netcoreapp1.1</TargetFramework>
  </PropertyGroup>

2. can't work

<PropertyGroup>
    <TargetFramework>net461</TargetFramework>
  </PropertyGroup>

[niemyjski]

Thanks I'll try this out, have you tried enabling troubleshooting/logging as per the wiki article?

[yunzhizhou]

Thanks. yes, I tried it. because my solution is upgraded from 2015 to 2017, in 2015 project, It is ok. so, I create a new project by visual sutdio 2017, finally, I found out when I switch to .net framework core, It can't work.

[niemyjski]

Thanks for the update, I'm traveling back from elasticon and I'll try and take a look at it tomorrow or first thing Monday. You're installing the asp.net core package right?

[yunzhizhou]

the package name is Exceptionless.AspNetCore

<PackageReference Include="Exceptionless.AspNetCore" Version="4.0.1934" />

[niemyjski]

Do you see this issue if you target dotnet 4.52? I upgraded my dotnet framework and I'm not seeing any errors but I'm also not seeing any events. I'll need to dig into this more and get back to you.

[yunzhizhou]

Thanks. yes , my project is based on dotnet 4.52, I once upgrade to 4.6.2, but the same result is not seeing an errors and also not seeing any events submited.

[niemyjski]

I'm currently blocked on this but am working on it. It might take me a day or two to get to the bottom of this, in order to debug this with the new rtm runtime and vs2017 I need to upgrade our project to the new csproject format which I had started over the weekend.

[muhammetsahin]

@niemyjski When do you plan to finish upgrade VS2017 ?

[niemyjski]

I hope to start today, I just need to finish up one or two small issues today on exceptionless server that I've been working on for a few days and move to this, and get this resolved asap.

[jordanwallwork]

I'm having this same issue. I went through the troubleshooting quickly - the IsolatedStorage directory isn't being created, and I tried enabling logging but that doesn't appear to work either. My app is targeting net462

[niemyjski]

Thanks for the heads up, I'm finishing up testing this one bug and will be moving back to this for sure today. I'll keep you updated.

[niemyjski]

I've started working on this uphill battle, I might have some news on this tomorrow.

[niemyjski]

I believe this issue is caused by the following error:

"Inheritance security rules violated by type: 'System.Net.Http.WebRequestHandler'. Derived types must either match the security accessibility of the base type or be less accessible."

which links to this issue https://github.com/dotnet/corefx/issues/11100.

As @MihaMarkic points out the fix is to install System.Net.Http v4.3.1 in your app and that will resolve this issue temporarily. There appears to be the issue running with referencing system.net.http which ships with .net 4.5 and running on asp.net core 👎

[niemyjski]

@himyspace @jordanwallwork Can you please try installing System.Net.Http v4.3.1 (latest) off of nuget and see if this resolves the issue.

[niemyjski]

I guess one of the things we could do would be to put System.Net.Http as a dependency of the asp.net core client.

[niemyjski]

I have committed a fix for this issue but unfortately I can push the nightly builds out after upgrading to csproj format as there are a few blockers with dotnet pack where half the packages aren't getting read mes :\ The fix for this issue is to install

    <PackageReference Include="System.Net.Http" Version="4.3.1" />

Into your app and it will work. You can also grab our nightlies off of my get (but there won't be a readme until it's fixed) https://www.myget.org/gallery/exceptionless (v1497)

[yunzhizhou]

Thanks. yes, It's ok now, when I install System.Net.Http v4.3.1 (latest) off of nuget ,It can submit events.

[niemyjski]

Thanks for the update! I'll have to wait until they fix nuget pack or give me a work around before I can deploy updated packages

[jordanwallwork]

Sorry for the slow response, I can confirm that that fixed the issue for me too. Cheers

[niemyjski]

A new package should be pushed out very very soon.

[EtiennePeeters]

We're having the same issue. Adding System.Net.Http v4.3.1 also fixed this for us. Edit: Just updated Exceptionless.AspNetCore.Signed to v4.0.1951. Thanks!

[niemyjski]

The new package is out, did that solve it for you?

[EtiennePeeters]

Yes, the problem is solved 👍

[dotnetchris]

So this issue seemed to just catch a colleague of mine. It's a VS2015 project using the xproj file type. Using AspNetCore (not 2.0) with Framework 4.6.1.

PM> Install-Package Exceptionless.AspNetCore
Retrieving package 'Exceptionless.AspNetCore 4.0.1951' from 'nuget.org'.
  GET https://www.nuget.org/api/v2/Packages(Id='Exceptionless.AspNetCore',Version='4.0.1951')
  OK https://www.nuget.org/api/v2/Packages(Id='Exceptionless.AspNetCore',Version='4.0.1951') 105ms
  GET https://www.nuget.org/api/v2/package/Exceptionless.AspNetCore/4.0.1951
  OK https://www.nuget.org/api/v2/package/Exceptionless.AspNetCore/4.0.1951 400ms
Installing Exceptionless.AspNetCore 4.0.1951.
Installing NuGet package Exceptionless.AspNetCore.4.0.1951.
Successfully installed 'Exceptionless.AspNetCore 4.0.1951' to Api
Executing nuget actions took 1.04 sec
Time Elapsed: 00:00:01.8472926

It didn't seem to notice anything about needing System.Net.Http": "4.3.2/1.

I had to explicitly install this package.

Honestly for an exception so critical that logging can't occur, it'd be nice if it crashed the entire application. If i didn't dig around to figure out how to enable logging, I wouldn't have been able to point my colleague to this being the problem and how to fix it.

[If you want to say, but we can't crash because this is all background stuff. Probably the most expressive way to crash would be to cause ToExceptionless().Submit(); to write to the queue and then throw whatever error it has. Atleast this would be unhandled and a developer might actually stumble into it. There's pretty much nothing worse possible in software than error handling code silently failing with no visibility and everything appears to be A-OK]

[niemyjski]

That package has a dependency on system.net 4.3.1 (https://www.nuget.org/packages/Exceptionless.AspNetCore/) so it shouldn't be an issue. Was the HttpClient v4.3.1 installed?

When .Submit() is called we enqueue it for background processing which happens every 10 seconds. If we randomly failed 10 seconds later after calling submit, it would be a big What the heck moment. Our goal is to never slow down your application, interrupt work flows, or bring down your application. Making this throw would bring down your app. Perhaps we should consider throwing if we detect the debugger is attached. It would be nicer to detect when there is an issue of some kind, currently we just degrade as we don't want to bring down the app.

[dotnetchris]

@niemyjski no that is not installed and was not installed

When it comes logging/error handling tools they should scorch the earth if they can't write. I can understand why it "feels good" to prevent hurting, but that's literally poison. If my logging/error infrastructure isn't working, I'd only choose no application over an indeterminate application.

Now that assumes it's truly dead as opposed to transient connectivity / semi-disconnected state. You should definitely know what's a temporary communication issue vs what's an unhandled total failure (like what triggers here)

[niemyjski]

Nuget should have forced that assembly to be installed :\ . I think that it's more than feels good there is two use cases going on here, one that this is supplemental logging and the other this is critical app component. Exceptionless is integrated into commercial applications of fortune 500 companies as well as thousands of small companies which includes medical companies as well. It wouldn't be good if for some hiccup in these cases we took down the app and potentially killed someone. Or the app just stopped working and some engineer has to go investigate it and they find out it was us, now they have a bad taste in their mouth forever.. I get that you want it to fail hard and fast, that's a valid point.

@ejsmith thoughts on this?

[dotnetchris]

@niemyjski I get what you're saying but i disagree, and i feel this directly supports my point. If any medical devices were operating on me and their logging infrastructure wasn't working, I absolutely don't want the device used on me. I would really hope it would halt instantly and entirely. Without those logs, if something goes wrong, they likely have no idea aside from perhaps watching videos if there was those to be a different kind of log.

I get at this point you likely won't change the out of box behavior, but i really hope you atleast make it configurable. Although the debug checking for special alerts for developers, that is a great idea.

[niemyjski]

@dotnetchris I talked with the team this morning and early on we made the decision as an error reporting service that we will never blow up your app and we stand by that. We'd rather have customers reach out to us (even if its after 5 minutes of trying) and do a 1-1 remote session to take a look into what's going on rather than to blow it up. We don't want it blowing up and taking down your app in local or production for simple things like submission (Maybe our api is down, error with the local http client etc..). There are things we can do server side to see if submission has occurred, maybe we need to inspect and ensure that the rate of events has changed and send an alert..

If there are specific use cases or areas that you think we should blow up or improve logging we'd like to hear about it for consideration.

[dotnetchris]

@niemyjski can you atleast make it attempt to write windows event log error messages if it fails?

[niemyjski]

What errors do you think should be written there? Just submission related? It seems like it would be a very rare case that the http client would be messed up. We already have a diagnostic logging to disk and it's easy to enable this. This is an area for consideration but it would be tied to only the full framework. Even then what is the perf hit to write an event log?

[dotnetchris]

@niemyjski the worst thing possible is a logger silently failing, you can certainly throttle writing the windows event. logs honestly even a single message per hour would be enough that a person could atleast trace that something is blocking exceptionless for working.

The big problem with the internal logging behavior of exceptionless is that it would require an application reset which means you would lose all information that was pending. That's why i brought up that the error logs should likely be written to transient storage that is always available such that if a person enables logging to trace issues that you can merge recent failures into the fresh app start.

[niemyjski]

@dotnetchris the chance of the logger failing is very small, and it would for a very large percentage of the time be on application startup and we could and want to do anomaly detection and let you know we are not getting events or seeing less from a specific machine / stack. I get that it really sucks off the bat but the chances of it stopping during application run, well I've never seen that happen in 10 years of logging :).

We do have offline storage via file storage but it's slower if you are doing large amounts of logging (serialization and deserialization calls + io). I'll see what we can do to write to the event logs. Would you want this to just a be a troubleshooting logger? like .UseFileLogger()?

[dotnetchris]

At this point I'm starting to get upset. I am a customer or potential customer depending how you views accounts.

Our initial experience was we installed your product, expected it to work, it did not work. We received no information on why it didn't work. I had to debug your product to figure out why it didn't work.

How many customers do you think you've lost because they didn't bother to investigate your product and just assumed "installed, nope doesn't work" and moved on?

You have anywhere between 15 to 25 major competitors in your market. Your out of box experience totally failed us. There is one and one single reason we didn't abandon your product and immediately move on to another service, a colleague of mine knows some of your guys and said you all are good people. If it wasn't for that super small world personal connection, you would have never even heard from me, and we would not be using exceptionless at all. We'd probably be using BugSnag.

[niemyjski]

@dotnetchris I'm really sorry we let you down. Is this working now that you installed that package? My understanding is you ran into an issue (which completely sucks and shouldn't happen), debugged it (wasn't very intuitive as we could do more to link to troubleshooting guide or link to support via the readme as well as configuration page). Found this issue and installed that package and you are up and working (my understanding), please correct me if any of this is wrong. Is this all correct?

As far as debugging and troubleshooting we can always get better and would love continued feedback. Upon my very first initial thoughts outside of writing to a file via our .UseFileLogger(), the event logs might not of helped as they only work on windows and may not even work on .net core (https://stackoverflow.com/questions/39131217/write-to-eventlog-in-net-core) depending on your runtime. So this would have to been a separate nuget package and not in box, but something we should look into and would gladly accept a pr for if someone wants to research into it.

From my experiences the only reason this package wouldn't be installed is if it the ignore min dependencies selected in the nuget package manager dialog or there is a nuget issues when installing our package (which we should do more to figure out which was the cause, if you create a new app and install our package does it install this dep? It does on my machines and the client machines I've been on), but this is a hard dependency because of this issue on core that is out side of our control.

We love what we do and treat everyone how we want to be treated. We will help anyone who contacts us and do our utmost to ensure it's working so they don't have too (but were always here and happy to help). We provide a service to make peoples lives easier not harder.

If you are still having issues, please reach out to us via in app message, the email on my GitHub profile or our slack channel and we can schedule a one on one remote session to take a closer look.