stackify / stackify-api-dotnet Goto Github PK

See pull request #6.

Log4Net 1.2.14 (2.0.4) added LogicalThreadContextStack, see https://issues.apache.org/jira/browse/LOG4NET-455

Knowing there is an issue with Log4Net prior to version 2.0.4 with a feature that is directly supported, and as Async/Await is more commonly used, it would be good to ensure we don't have this bug as well.

Once 2.0.4 is the minimum version required, we can remove the use of a string compare for type check in the Log4Net Appender.

I am testing the direct api with NUnit tests and the test project's app.config contains the three required appSettings keys, but nothing is logged.

I installed the nuget package.

There are a few calls on Logger which should read the api key, but that doesn't happen. The internal HttpClient should even read the api key when it's not given, but doesn't.

The only way I have gotten the direct api to actually log, is to manually set the ApiKey and call Shutdown() at the end. I haven't seen any references to Shutdown() btw,

Here are the things I have tried:

[TestFixture]
public class Log_to_stackify
{
    [Test]
    public void Api_key_is_not_read_from_config()
    {
        Logger.ApiKey.ShouldNotBeNull();
    }

    [Test]
    public void Api_key_should_have_been_read_but_its_not()
    {
        Logger.CanSend();
        Logger.ApiKey.ShouldNotBeNull();
    }

    [Test]
    public void The_default_example_does_not_log_anything()
    {
        Logger.QueueException(new ApplicationException("Sky is falling"));
    }

    [Test]
    public void Must_set_api_key_manually_and_call_shutdown_in_order_to_log()
    {
        Logger.ApiKey = ConfigurationManager.AppSettings["Stackify.ApiKey"];
        Logger.QueueException(new ApplicationException("Sky is falling"));
        Logger.Shutdown();
    }
}

NLog has Event Properties which is used for logging custom values.

LogEventInfo theEvent = new LogEventInfo(LogLevel.Debug, "", "Pass my custom value");
theEvent.Properties.Add("MyValue", "My custom string");
theEvent.Properties.Add("MyDateTimeValue", new DateTime(2015, 08, 30, 11, 26, 50));
logger.Log(theEvent);

Currently the NLog target does not capture these values and it would be very nice if it could.

a naive fix would be adding something like below

if (loggingEvent.Properties.Any())
{
    // capture properties of log event
   loggingEvent
         .Properties
         .ToList()
         .ForEach(prop => diags.Add(prop.Key.ToString(), prop.Value));
 }

after

Updated to 1.20.0 and get null reference error on calling Logger.CanSend()?

Apikey is blank so dev envs don't send to Stackify, framework used for Prefix.

Any guidance?

Dan

The .NET Standard requirement on a project that does not use nor does my hosting environment support. Due to this requirement of your nuget package, I have added a boat load of packages I do not need nor have time to test to ensure it did not inject new errors.

Please break up the NuGet packages. I'm downloading your package and am just going to include the DLL I require.

I'm having some problems building the projects in the solution (from master). Especially the main StackifyLib which seems to have both 4.0, 4.5 and Core configuration in it.

After having removed the missing monitors.cs, project.json, the xproj, added the missing /utils/EtwEventListener.cs, added NET45 conditional AND set the target framework to 4.6 I was able to build it.

I wanted to do the right thing, and create a PR for more information in the WebRequestDetail but this whole ordeal makes me wonder if I'm really supposed to make this work off your current codebase, or if I should just suggest the feature to your support.

Hi, is there any support to add Web Monitors via API? This seems to be only related to Logging/Metrics only.

Thanks

exception.TargetSite does not exist. How do we know the source method of the exception?

Why is StackifyLib unsigned?

I have an Azure function app that's performance-critical. After instrumenting it with NLog and a StackifyTarget with an AsyncWrapper, I was perplexed to be observing the following:

As you can see, a request that I would have expected to execute in 20ms instead took 775ms (39x longer!) due to what looks like blocking code from the StackifyTarget. Thinking perhaps the NLog AsyncWrapper wasn't behaving as it should, I did some debugging and found that the wrapper itself is behaving as expected.

Digging deeper, I found that the AsyncWrapper is pretty useless when used in conjunction with the StackifyTarget, as the StackifyTarget itself queues messages up for "asynchronous" uploading using System.Threading.Timer.

This would be great if the timer function was actually asynchronous. It's not.

My code, which uses async/await code for all I/O operations, is now sharing a threadpool with a synchronous, I/O-bound resource hog.

https://www.nuget.org/packages/StackifyLib/

The nuget package for version StackifyLib 2.0 for .NET Framework 4.5.1 is requiring package Microsoft.Extensions.Configuration. I don't believe this is correct given this package is for .NET Standard not the .NET Framework. Can you please adjust this and re-publish to NuGet so we can pull in this library.

How do we handle Configuration in general with Core? Old AppSettings is gone...

Our Config.cs needs updating. We also have code that looks for Stackify.AppName, etc

Are there any plans to support an ILoggingBuilder extension method along the lines of something like ILoggingBuilder.AddStackifyLib(); so that we can configure logging in our Program class rather than in the IStartup.Configure method?

We are using Log4net (1.2.13) with the Remoting Appender and we are not getting any stack trace in stackify for our errors (it shows an empty array in the UI).

We traced it to this line of your code: https://github.com/stackify/stackify-api-dotnet/blob/master/Src/StackifyLib.log4net/StackifyAppender.cs#L150#

Would it be possible to have fall back logic that extracts the frame from the passed in loggingEvent instead of the current stack (which is not available because the error exists on a different machine & is sent over via remoting).

We have some old services that are using the log4net remoting appender and the error logs are not helpful without the stack trace.

Would like to target NetStandard1.3 but for some reason Environment.MachineName is not available and we need that.

I'm using Serilog with Serilog.Sinks.Stackify to try and log to Prefix from my WCF application. I'm doing this on a Windows 7 machine running .NET 4.6.1 on VS2015.

From what I can find it seems 'GetSystemTimePreciseAsFileTime' is not available on Windows 8 and below.

Is there any possible fix other than moving to a newer version of Windows?

Thanks,
Ritwik

Need to review in ErrorItem GetMethodFullName how we get the full method names that we want for display. The old way with ReflectedType is not available.

Instead of requiring the call StackifyLib.Logger.Shutdown(); can't you use a singleton pattern like so:

ILogger logger = StackifyLib.Logger.Current; // Creates a new logger instance if one is not created.

So...

StackifyLib.Logger.Queue("DEBUG", "My log message");
StackifyLib.Logger.QueueException("Test exception", new ApplicationException("Sky is falling"));

Becomes...

StackifyLib.Logger.Current.Queue("DEBUG", "My log message");
StackifyLib.Logger.Current.QueueException("Test exception", new ApplicationException("Sky is falling"));

And then use the destructor to persist queued logs.

This way you can have multiple loggers and you can remove all the static method calls, making the class unit testable.

The change suggested is backwards compatible too with the existing API.

Is System.Web really required for the Api lib? There are multitudes of ways to make remote calls, interact with IIS, etc. that don't require this dll.

The Stackify.nLog package automatically updates the config to add nlog config node.
But if you already have an nlog.config file, that one just gets ignored.
What happens next is that you run your application and think nlog is broken because all the configuration that you put in nlog.config is ignored. Just wasted half an our trying to figure this out.

I think it would be a better user experience if the NLog configuration was moved to into a seperate Stackify.nLog.Configuration package. You can add a readme to the initial package with information about the configuration.

I'm trying the nlog target in a new application, I've tried the troubleshooting guide with no solution. NLog is working fine, if I put I file logger, but the moment I put the stackify target <target name="stackify" type="StackifyTarget" globalContextKeys="" mappedContextKeys="" callContextKeys="" logMethodNames="true" /> it stops working, even if I don't put it in <rules>.

Also, my Stackify configuration is ok, I've tried to log with the Direct Api and it worked.

Relating to this line we need to turn this off since PII data is being passed to Stackify which is NOT our sub processor

This can also apply to serialising cookies and would be very good to have options to control the level of data being exported from our application.

When a client calls StackifyLib.Logger.Shutdown(), we should log the stack trace.

Logging should be performed by ScheduledLogHandler.Stop()

I'd like to trace azure webjobs without littering my code such that every single WebJob function has a tracer.Exec(() => ...) call. Is there any way to properly use the Stackify ProfileTracer with the WebJobs function filter?

https://github.com/Azure/azure-webjobs-sdk/wiki/Function-Filters

Basically, we need some way to "begin" and "end" a timing session without explicitly wrapping or passing the Action.

What is the preferred library when using Stackify with .NET Core 1 or 2?

Do you better support NLog or log4net?

Are there any issues to be aware of when using one over the other?

It seems that if you add the Stackify Dotnet Core middleware into your application pipeline it will override a server exception and return it as a 200 response code. As you can imagine, this can cause some issues when dealing with an API.

To reproduce this fire up any MVC application and configure it to use StackifyMiddleware. Once you do that in any controller configure the action to throw and exception. From the client, even though the exception is thrown, a 200 is received.

Startup Configure
public void Configure(IApplicationBuilder app, IHostingEnvironment env) { app.UseStackifyMiddleware(); app.UseMvc(); }

Controller Action
public async Task<ActionResult<IEnumerable<string>>> Get() { throw new SystemException(); }

Since it doesnt appear the UseStackifyMiddleware is open source, I figured this to be the next best place to get a comment on this issue with this product. If there is a better way to get support, please let me know.

solution/project targeting .net framework 4.5.2
msbuild .net framework 4.6
stackifylib 2.0.2 from nuget

msbuild is failing to build: error CS0103: The name 'StackifyLib' does not exist in the current context

command line parameters:
SET MSBUILD="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe"
SET MSBUILD_CONFIG=/p:Configuration=Release /p:DeployOnBuild=true /p:PublishProfile=local /t:Rebuild
SET MSBUILD_DOTNET_VERSION=/p:FrameworkPathOverride="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.6"
SET MSBUILD_VS_VERSION=/p:VisualStudioVersion=14.0 /p:GenerateBuildInfoConfigFile=false
%MSBUILD% %PATH_BUILD%<projectname>.csproj %MSBUILD_CONFIG% %MSBUILD_VS_VERSION% %MSBUILD_DOTNET_VERSION%

Ref RFC 7231:

product = token ["/" product-version]
product-version = token

User-Agent: Stackify/2.1.0

Looking at the file: https://github.com/stackify/stackify-api-dotnet/blob/master/Src/StackifyLib.CoreLogger/StackifyLogger.cs I see that BeginScope simply returns null. It would be great if the code added the state as metadata to the logs.

For example, if TState was a dictionary, then the logger should include each name/value pair as metadata. If the state was another object, it could serialize the object as well. I care less about having a true hierarchy of states (though that would be nice) than I do about having the metadata added and available in Stackify logs for searching.

Thanks.

.Net core does not have support for CallContext. So we are unable to use MDLC feature (MappedDiagnosticsLogicalContext) provided by NLog. As most of the core apps use async extensively, can you pls add support for MappedDiagnosticsLogicalContext in StackifyTarget class. This way we can setup transid in mappedContextKeys attribute for stackify target inside nlog config. This will allow to set our cutsom transid value in stackify. The value of transid key = HttpContext.TraceIdentifier.

Also we need the ability to mask sensitive data in certain fields of LogMsg object. The fields that need masking are Msg, data, and Ex.Message. Can you pls mark Translate method in StackifyTarget class as virtual so that we can override in derived class and in our overridden method we will first call base class method and then apply masking in LogMsg object returned by the base method. Then overidden method will return masked LogMsg object.

When using NLog.Target.Stackify then the reported server name is always .. This seems to be caused by the following line:

The documentation of Process.MachineName has the following note: When the associated process is executing on the local machine, this property returns a period (".") for the machine name
This would mean that this line will always return . because the current process will always be running on the local machine.

Right now the core logger just logs basic strings. It would be nice if the template values were also stored as metadata in Stackify for easier searching.

Not sure how to set the proxy on the requests in StackifyHttpClient for .net core

We keep getting crashes when running our new ASP.NET Core app.

Steps to reproduce:

1. Publish website
2. Make a few requests
3. Leave the website with no requests for a minute or so
4. The app crashes

Problem signature:
Problem Event Name: APPCRASH
Application Name: dotnet.exe
Application Version: 2.0.26021.1
Application Timestamp: 5a3b026e
Fault Module Name: StackifyProfiler_x64.dll
Fault Module Version: 4.0.6.9
Fault Module Timestamp: 59f0cdeb
Exception Code: c0000005
Exception Offset: 000000000005f693
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 2057
Additional Information 1: ae86
Additional Information 2: ae860a156c9d9ef453b0254d4be3fd76
Additional Information 3: d4ae
Additional Information 4: d4ae15ddac055b140b0e91f6e26a9d03

Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: dotnet.exe
P2: 2.0.26021.1
P3: 5a3b026e
P4: StackifyProfiler_x64.dll
P5: 4.0.6.9
P6: 59f0cdeb
P7: c0000005
P8: 000000000005f693
P9:
P10:

Attached files:

These files may be available here:
C:\Users\MatthewB\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_dotnet.exe_e291691d7b62f9c3b374c4617a4eebfa6b124ad_1c88e72c

Analysis symbol:
Rechecking for solution: 0
Report Id: effaf68b-195f-11e8-939b-005056c00008
Report Status: 0

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Version=1
EventType=APPCRASH
EventTime=131639496483989411
ReportType=2
Consent=1
ReportIdentifier=effaf68c-195f-11e8-939b-005056c00008
IntegratorReportIdentifier=effaf68b-195f-11e8-939b-005056c00008
Response.type=4
Sig[0].Name=Application Name
Sig[0].Value=dotnet.exe
Sig[1].Name=Application Version
Sig[1].Value=2.0.26021.1
Sig[2].Name=Application Timestamp
Sig[2].Value=5a3b026e
Sig[3].Name=Fault Module Name
Sig[3].Value=StackifyProfiler_x64.dll
Sig[4].Name=Fault Module Version
Sig[4].Value=4.0.6.9
Sig[5].Name=Fault Module Timestamp
Sig[5].Value=59f0cdeb
Sig[6].Name=Exception Code
Sig[6].Value=c0000005
Sig[7].Name=Exception Offset
Sig[7].Value=000000000005f693
DynamicSig[1].Name=OS Version
DynamicSig[1].Value=6.1.7601.2.1.0.256.48
DynamicSig[2].Name=Locale ID
DynamicSig[2].Value=2057
DynamicSig[22].Name=Additional Information 1
DynamicSig[22].Value=ae86
DynamicSig[23].Name=Additional Information 2
DynamicSig[23].Value=ae860a156c9d9ef453b0254d4be3fd76
DynamicSig[24].Name=Additional Information 3
DynamicSig[24].Value=d4ae
DynamicSig[25].Name=Additional Information 4
DynamicSig[25].Value=d4ae15ddac055b140b0e91f6e26a9d03
UI[2]=C:\Program Files\dotnet\dotnet.exe
UI[3]=dotnet has stopped working
UI[4]=Windows can check online for a solution to the problem.
UI[5]=Check online for a solution and close the program
UI[6]=Check online for a solution later and close the program
UI[7]=Close the program
LoadedModule[0]=C:\Program Files\dotnet\dotnet.exe
LoadedModule[1]=C:\Windows\SYSTEM32\ntdll.dll
LoadedModule[2]=C:\Windows\system32\kernel32.dll
LoadedModule[3]=C:\Windows\system32\KERNELBASE.dll
LoadedModule[4]=C:\Windows\System32\SYSFER.DLL
LoadedModule[5]=C:\Windows\system32\api-ms-win-crt-runtime-l1-1-0.dll
LoadedModule[6]=C:\Windows\system32\ucrtbase.DLL
LoadedModule[7]=C:\Windows\system32\api-ms-win-core-timezone-l1-1-0.dll
LoadedModule[8]=C:\Windows\system32\api-ms-win-core-file-l2-1-0.dll
LoadedModule[9]=C:\Windows\system32\api-ms-win-core-localization-l1-2-0.dll
LoadedModule[10]=C:\Windows\system32\api-ms-win-core-synch-l1-2-0.dll
LoadedModule[11]=C:\Windows\system32\api-ms-win-core-processthreads-l1-1-1.dll
LoadedModule[12]=C:\Windows\system32\api-ms-win-core-file-l1-2-0.dll
LoadedModule[13]=C:\Windows\system32\api-ms-win-crt-math-l1-1-0.dll
LoadedModule[14]=C:\Windows\system32\api-ms-win-crt-heap-l1-1-0.dll
LoadedModule[15]=C:\Windows\system32\api-ms-win-crt-convert-l1-1-0.dll
LoadedModule[16]=C:\Windows\system32\api-ms-win-crt-stdio-l1-1-0.dll
LoadedModule[17]=C:\Windows\system32\api-ms-win-crt-string-l1-1-0.dll
LoadedModule[18]=C:\Windows\system32\api-ms-win-crt-locale-l1-1-0.dll
LoadedModule[19]=C:\Windows\system32\api-ms-win-crt-multibyte-l1-1-0.dll
LoadedModule[20]=C:\Program Files\dotnet\host\fxr\2.0.5\hostfxr.dll
LoadedModule[21]=C:\Windows\system32\api-ms-win-crt-filesystem-l1-1-0.dll
LoadedModule[22]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\hostpolicy.dll
LoadedModule[23]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\coreclr.dll
LoadedModule[24]=C:\Windows\system32\ADVAPI32.dll
LoadedModule[25]=C:\Windows\system32\msvcrt.dll
LoadedModule[26]=C:\Windows\SYSTEM32\sechost.dll
LoadedModule[27]=C:\Windows\system32\RPCRT4.dll
LoadedModule[28]=C:\Windows\system32\ole32.dll
LoadedModule[29]=C:\Windows\system32\GDI32.dll
LoadedModule[30]=C:\Windows\system32\USER32.dll
LoadedModule[31]=C:\Windows\system32\LPK.dll
LoadedModule[32]=C:\Windows\system32\USP10.dll
LoadedModule[33]=C:\Windows\system32\OLEAUT32.dll
LoadedModule[34]=C:\Windows\system32\VERSION.dll
LoadedModule[35]=C:\Windows\system32\SHLWAPI.dll
LoadedModule[36]=C:\Windows\system32\bcrypt.dll
LoadedModule[37]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\api-ms-win-crt-utility-l1-1-0.dll
LoadedModule[38]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\api-ms-win-crt-time-l1-1-0.dll
LoadedModule[39]=C:\Windows\system32\IMM32.DLL
LoadedModule[40]=C:\Windows\system32\MSCTF.dll
LoadedModule[41]=C:\Program Files (x86)\Stackify\Profiler\v4.0.6.9\x64\StackifyProfiler_x64.dll
LoadedModule[42]=C:\Program Files (x86)\Stackify\Profiler\v4.0.6.9\x64\cpprest120_2_8.dll
LoadedModule[43]=C:\Windows\system32\WINHTTP.dll
LoadedModule[44]=C:\Windows\system32\webio.dll
LoadedModule[45]=C:\Windows\system32\HTTPAPI.dll
LoadedModule[46]=C:\Windows\system32\CRYPT32.dll
LoadedModule[47]=C:\Windows\system32\MSASN1.dll
LoadedModule[48]=C:\Windows\system32\MSVCP120.dll
LoadedModule[49]=C:\Windows\system32\MSVCR120.dll
LoadedModule[50]=C:\Windows\system32\WS2_32.dll
LoadedModule[51]=C:\Windows\system32\NSI.dll
LoadedModule[52]=C:\Windows\system32\SHELL32.dll
LoadedModule[53]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\System.Private.CoreLib.dll
LoadedModule[54]=C:\Windows\SYSTEM32\MSCOREE.DLL
LoadedModule[55]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\clrjit.dll
LoadedModule[56]=C:\Users\MatthewB\my documents\visual studio 2017\Projects\MVC\Ev.Web.UI.ImageServer.Benchmark\bin\Release\netcoreapp2.0\Ev.Web.UI.ImageServer.Benchmark.dll
LoadedModule[57]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\System.Runtime.dll
LoadedModule[58]=C:\Users\MatthewB.nuget\packages\benchmarkdotnet.core\0.10.12\lib\netcoreapp2.0\BenchmarkDotNet.Core.dll
LoadedModule[59]=C:\Users\MatthewB\my documents\visual studio 2017\Projects\MVC\Ev.Web.UI.ImageServer.Benchmark\bin\Release\netcoreapp2.0\Ev.Generic.Benchmark.dll
LoadedModule[60]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\System.Console.dll
LoadedModule[61]=C:\Users\MatthewB.nuget\packages\benchmarkdotnet\0.10.12\lib\netcoreapp2.0\BenchmarkDotNet.dll
LoadedModule[62]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\System.Linq.dll
LoadedModule[63]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\System.Collections.dll
LoadedModule[64]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\System.Runtime.Extensions.dll
LoadedModule[65]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\System.Linq.Expressions.dll
LoadedModule[66]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\System.Threading.dll
LoadedModule[67]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\System.Collections.Concurrent.dll
LoadedModule[68]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\System.IO.FileSystem.dll
LoadedModule[69]=C:\Windows\system32\CRYPTBASE.dll
LoadedModule[70]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\System.Runtime.InteropServices.dll
LoadedModule[71]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\System.Xml.ReaderWriter.dll
LoadedModule[72]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\System.Private.Xml.dll
LoadedModule[73]=C:\Windows\system32\CRYPTSP.dll
LoadedModule[74]=C:\Windows\system32\rsaenh.dll
LoadedModule[75]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\System.Private.Uri.dll
LoadedModule[76]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\System.Net.Primitives.dll
LoadedModule[77]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\System.Text.Encoding.Extensions.dll
LoadedModule[78]=C:\Users\MatthewB.nuget\packages\microsoft.aspnetcore.testhost\2.0.1\lib\netstandard2.0\Microsoft.AspNetCore.TestHost.dll
LoadedModule[79]=C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.5\netstandard.dll
LoadedModule[80]=C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.hosting.server.abstractions\2.0.1\lib\netstandard2.0\Microsoft.AspNetCore.Hosting.Server.Abstractions.dll
LoadedModule[81]=C:\Program Files\dotnet\store\x64\netcoreapp2.0\microsoft.aspnetcore.http.features\2.0.1\lib\netstandard2.0\Microsoft.AspNetCore.Http.Features.dll
FriendlyEventName=Stopped working
ConsentKey=APPCRASH
AppName=dotnet
AppPath=C:\Program Files\dotnet\dotnet.exe

Need to figure out how to do this via new dependency injection or some other way.

We're using log4net and have ASP.NET MVC 5 on .NET 4.7.1 and aspnet core 2.2.

The aspnet core app doesn't have any json contextObject properties. The .NET 4.7.1 app works just fine. We're using StackifyLib.log4net 2.1.0.

Is there a way to diagnose or a sample app to reference to make sure we're setup correctly?

I saw this pop up in my log searches recently. I can't understand under what conditions a stack trace / exception would cause this to be added. The code above this hash tag insert seems kind of convoluted. What's the user story in order to help me understand what I'm seeing?

I receive this error in the Stackify.Prefix Log:

StackifyLib.Logger.GetCurrentStackTrace

Request Queuing Delay between pipeline steps
Caught System.ArgumentNullException
System.ArgumentNullException: Value cannot be null.
  at System.Diagnostics.StackTrace..ctor
  at StackifyLib.Logger.GetCurrentStackTrace
  at System.Diagnostics.StackTrace..ctor
  at StackifyLib.Logger.GetCurrentStackTrace
  at System.Diagnostics.StackTrace..ctor
  at StackifyLib.Logger.GetCurrentStackTrace
  at System.Diagnostics.StackTrace..ctor
  at StackifyLib.Logger.GetCurrentStackTrace
  at System.Diagnostics.StackTrace..ctor
  at StackifyLib.Logger.GetCurrentStackTrace

Not sure if this works or if we want to keep it since it does a DllImport function

I'm trying to use stackifyLib from behind a proxy. The docs tells me it's easy, and here is what I'm trying:

var stackify = config.GetSection("Stackify");
Config.ApiKey = stackify["ApiKey"];
Config.AppName = stackify["AppName"];
Config.Environment = stackify["Environment"];

var webProxy = new WebProxy(new Uri("http://proxy:8888"))
{
     UseDefaultCredentials = true,
     BypassProxyOnLocal = false
};
StackifyLib.Utils.HttpClient.CustomWebProxy = webProxy;

This doesn't work, and after some troubleshooting, I check out the StackifyLib source were I find that the CustomWebProxy is only ever used in .NETFULL.

Is this intentional? Is there another way I'm supposed to setup proxy when using .netcore2.1?

Any help appreciated!

kind regards,
Kjetil

We use precompiled pages for ASP.NET MVC on our site. Recently I tried to upgrade the StackifyLib nuget project from 2.1.0 to 2.1.3. When I did that I started getting an error during publish:

aspnet_merge(0,0): Error occurred: An error occurred when merging assemblies: Unresolved assembly reference not allowed: System.Net.Http.

This also occurs if I upgrade to StackifyLib 2.1.2.

We are targeting .NET 4.7.2. We have the following installed:
StackifyHttpModule version="1.0.28.0"
StackifyLib" version="2.1.0"
StackifyLib.log4net" version="2.1.0"

How do we collect correlation ids?

No need to perform the reflection-dance for every LogEvent (Introduced with #94):

Should cache the lookup of callContextType.GetProperty("TraceContext") and traceCtxType.GetProperty("RequestId").

var traceContextProp = _callCtxTraceContextPropInfo.GetValue(null);
if (traceContextProp != null)
{
       var reqIdProp = _traceCtxRequestIdPropInfo.GetValue(traceContextProp)?.ToString();
}