Is it possible to use built-in logging to file in dnx?
I tried to use System.Diagnostics.TextWriterTraceListener but is not available in .Net Core. Any suggestions?
By itself, ASP.NET Core’s logging system does not come with a file-based logging provider.
It would be pretty simple to roll your own though; just look at the Debug logger as an example to see what you need to do.
Of course, you could also use another logging framework that already supports this. For example NLog – a .NET Core compatible version is in alpha. Another example would be Serilog which also has .NET Core versions in beta (versions 2.x)
If you run your app through IIS, you can also use IIS’ file logging to redirect the stdout logging into files. This can be configured in the web.config.
Related
I am trying to update a library of shared code from .NET Framework to .NET Standard. The library has important dependencies on System.Web.Hosting.HostingEnvironment.IsHosted and HostingEnvironment.ApplicationID.
The library is precompiled into an assembly, and assembly is referenced across many projects:
.NET Framework console apps
.NET Framework Windows Forms apps
.NET Framework Windows services
Standalone ASP.NET website (bespoke code for a client, often as a web service)
Extension to ASP.NET site written by third-party. (Create new ascx controls with compiled code-behind added to \bin\ folder)
(Precompile is so that updated versions of the assembly can be dropped in place on solutions that already reference it.)
The library provides mostly code accelerators -- standardized database access, logging, license checking, type conversions, etc. The logging features are not only used by the calling project, but are also called by other parts of the library. For example, license checking relies on database access, and database errors are written to the log.
The logging area is a sticking point, especially in the context of bullet 5. The parent application may be served up from multiple IIS websites in multiple app pools. Or multiple IIS sites using the same app pool. Or from different subfolders on the same site, but in different app pools. When the library detects it is being run from inside IIS, logs are written to different files based on appId and application pool name. (E.G. MyCompany.2.PublicSitePool.log inside IIS, or just MyCompany.log when not in IIS)
On .NET Framework, I use System.Web.Hosting.HostingEnvironment.IsHosted to detect when I'm running in IIS, obtain the appId using HostingEnvironment.ApplicationID, and the app pool name comes from System.Environment.UserName.
I am trying to retarget the project for .NET Standard, so the library can be used equally well with .NET Core projects. System.Web.Hosting is not available on .NET Core. I'm looking for a solution that can either:
Give me consistent results on both .NET Framework and .NET Core
or
Explicitly detect whether running in .NET Framework or .NET Core, and then use appropriate techniques for the platform
I already have the "am I in IIS" check running as a singleton in the class constructor. Reflection does not thrill me but is a reasonable option if needed.
I have already reviewed these questions (and a few others). Some useful ideas, but no single solution. Reading settings from *.config is not an option. Asking the calling application to specify "hosted" or "not hosted" is the least attractive option that I know will work, because it will break all existing solutions that use this code.
HostingEnvironment does not contain a definition for IsHosted
How determine if an application is a web application in .NET Core?
How to tell if code is running on web server without using System.Web?
How to get HttpContext.Current in ASP.NET Core? [duplicate]
I looked at the Common.Logging Nuget Package and the latest version supports .NET Core 1. I am currently using .NET Core 3. Hence I am looking for recommendations, whether it is still a good idea to use Common.Logging NuGet package, or is there any other alternate I should explore.
I am writing a NuGet package and one of the requirement is that it can take any logging object, mostly Log4Net or NLog object and log everything according to their configurations, which would be passed in from the parent project.
My suggestion here is that you don't re-invent the wheel and use the Microsoft.Extensions.Logging libraries that Microsoft is bringing to manage the logging providers from a single point.
You have already some third-party connectors for NLog and Log4Net that simplifies the way to log in multiple providers, just registering each at startup level.
I think it's pretty safe. The https://www.nuget.org/packages/Common.Logging.Core/3.4.1 is for .net standard 1.0 and it seems there was no need to update.
In addition, based in this request https://github.com/net-commons/common-logging/issues/148 the project is still active with plans to support in the future.
From this question Are there any alternatives to Common.Logging?, it seems that there are no other valid alternatives but use it, or go for a custom facade implementation.
A Microsoft Azure blog post from 2013 details how to use the application settings and connection strings in Azure app services. However, one part is not quite clear to me:
For ASP.NET web applications, there is some extra runtime magic that is available as well when using the .NET 4.5 framework (note: this magic is not available if you choose .NET 3.5 since it relies on functionality that only exists in .NET 4.5).
The author describes how you can use the System.Configuration.ConfigurationManager class to access the application settings and connection strings configured in the Azure portal.
How does this "extra runtime magic" work? Does the .NET Framework include Azure-specific code, or does Azure inject something, similar to how diagnostics will add a trace listener?
How does this "extra runtime magic" work? Does the .NET Framework include Azure-specific code, or does Azure inject something, similar to how diagnostics will add a trace listener?
As your article refered to,
If the website’s web.config file references the same connection string in the configuration section, then Windows Azure Web Sites will automatically update the connection string at runtime using the value shown in the portal.
Yes, Azure inject something.It is a feature of Azure App Service. For .NET apps, the application settings on portal are injected into your .NET configuration AppSettings/Connection strings at runtime, overriding existing settings.
Hope it can help you. For more details, you could refer to this article.
I'm prototyping a .net core 2 web application. I've been asked to use Log4Net for handling our logging, but I want to put it in a .net framework 4.6.1 wrapper project as to allow for changing out the internal logging systems without having to update all of the method calls throughout the site.
Everything that I've found so far is for doing one or the other. Wrapping the log4net in 4.6.1 or doing a direct reference to the .net core.
So far, my 2 main exceptions are "FileNotFoundException" for when I use it as a direct reference, or when I do the PackageReference in the Framework proejct files I get a "Logging is not compatible with netcoreapp2.0. Logging is framework 4.6.1.
First, I would recommend making your wrapper using .NET standard 1.3 as this is the currently .NET core version supported by log4net, plus, this would allow you to reference this wrapper in .NET core and .NET framework 4.6 and up.
Second, see: https://stackify.com/making-log4net-net-core-work/ for some more info on getting log4net working with .NET core.
i have issues with logging to pappertailapp from asp.net core(1.0.1)
i have downloaded and used this NLog solution
by tutorial all works perfectly it saving logs to local folder and i can see logs.
but by tutorial of pappertrailapp - NLog
i change my nlog.config target paths with this line:
<target name="syslog" type="Syslog"
syslogserver="logs.papertrailapp.com" port="myport" facility="Local7"/>
syslogserver and port take from my pappertrailapp account.
and there is no logs from my local machine and staging server (all the ips(my local and server) are configured in pappertrailapp and all MVC .NET 4 are works but not new ASP.NET Core apps.)
thanks!
As far as I can tell, NLog.Targets.Syslog is not yet compatible with Core projects. You can try taking a look at the config instructions on the NLog github specifically for Core projects, but I don't see any options as of yet that will support Papertrail.
It does seem like log4net is ready to support Core + Papertrail, if switching logging libraries is a reasonable option for you.