We use NLog or Serilog to do logging. We're busy porting a system from ASP.NET to ASP.NET Core, which has logging built in.
Ideally, we'd like to drop NLog, as there doesn't appear to be a need for it anymore.
However, is the built in logging equivalent to NLog? Is it missing any major features? Is there any point in continuing using NLog (or something similar e.g. Serilog)?
The ASP.NET logging is a common (logging) interface and log implementation.
You could use the common interface and 3rd party library (e.g NLog) together as the infrastructure is prepared for that.
If you take NLog over the built-in logging implementation you win:
changing configuration on-the-fly (while running application without restart)
more targets (e.g. database, file). There is no file target in the built-in: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/logging. The mail target in NLog isn't in .NET Standard yet, but it's planned. The mail target is there for .NET Standard 2 and for .NET Standard 1 there is NLog.MailKit
more options in targets (e.g. file archiving)
writing extra context info, like ${processid}
as we invest a lot of in performance optimization, I would expect performance.
async logging - which isn't in ASP.NET logging as far as I know.
advanced features like buffering, fallbacks & limiting your logs, filter conditions with context info, writing concurrent to one file etc.
NLog is easier to extend (not only targets but also layout renderers, layouts etc.)
possibility for structural logging (Serilog, NLog 4.5)
But as always, if you don't need these features then maybe less (libraries) is more.
I wouldn't say that ASP.NET Core's logging API makes NLog and other providers obsolete. What ASP.NET Core provides is a nice abstraction so logging frameworks can be switched without changing code that depends on logging.
Nlog still provides useful configuration features that are not implemented in ASP.NET Core logging API.
Related
I'm looking into using ASP.Net Core MVC for some of my new projects. I work on a team of developers for a very large organization, and we each individually write a lot of small web apps. Due to the size of our organization, we have a lot of rules that we have to follow, and sometimes those rules change, completely out of our control. So this is what we have used in the past projects, all running on IIS:
ASP Classic - Each IIS root folder has a shared folder, containing a lot of commonly used .asp files. These files are mostly the same on each server, but can point to different databases for dev/test/prod environments. These library files are used for common things like authentication, authorization, encryption, sending emails, etc... Each application would be in a sibling folder to the shared folder, and include files like "..\shared\library.asp"
ASP.Net / MVC - The closest thing we could find was the GAC. Everybody says not to use the GAC, but for our purposes it does exactly what we need. We built a DLL library, and store it in the GAC of each web server. We then put local configuration (dev/test/prod environment specific stuff) information on the global web.config of each IIS server. Application specific information would be stored in that application's local web.config file.
The beauty of these two systems, is sometimes things change, and we can simply go update the global libraries, and every application that depends on them will adapt to the new code without needing a recompile. We have many applications, running on many web servers. This may not be ideal, but for our needs it works perfectly, considering the rules can change at a moment's notice, and recompiling every application would be a huge ordeal. We just have to be sure not to ever introduce breaking changes into our libraries, which is simple enough. We have zero problems with how it works.
Now, on to ASP.Net Core. Is there an elegant way to do this? It seems like Core doesn't support the GAC, nor does it support web.config. Everything wants to use appsettings.json. Is there a way to create an appsettings.json at the root level of IIS, and have it set global variables like environment="dev", authdatabase="devsql" etc? And can we store a .Net Core/Standard DLL in a shared folder, and have every app load it with a path like "..\shared\library.dll"? The closest thing I could find to do this with .Net framework was the GAC, but I'm not really finding any answers for this with Core. I appreciate any help, thanks!
sometimes things change, and we can simply go update the global libraries, and every application that depends on them will adapt to the new code without needing a recompile
Note that this is exactly one of the reasons why GAC deployment is usually avoided. If you update a dependency, and that happens to contain a breaking change (in any possibly case), then applications will start to break randomly without you having control over that.
Usually, if you update a dependency, you should have to retest every application that depends on that before you deploy the updated application. That is why dependency updates (e.g. via NuGet) are deliberate choices you need to make.
.NET Core avoids this in general by never sharing assemblies between applications and by allowing different versions side-by-side. That way, you can update applications one by one without affecting others.
This is actually a primary reason why .NET Core was made in the first place: The .NET Framework is shipped with Windows, and is a global thing. All applications will always use the same framework version. So whenever Microsoft ships an update to the .NET Framework, they have to be incredibly careful not to break applications. And that is incredibly difficult because countless applications depend on all kinds of things in the framework. Even fixing a possibly obvious bug can break stuff.
With .NET Core and side-by-side dependencies, this is no longer a problem because updates will not automatically break applications that still depend on older versions. It is a developer’s explicit choice to update an application, shipping newer dependencies.
So you should actually embrace this and start to develop your applications independently. If you have common dependencies, consider creating (private) NuGet packages for those, so that applications can depend on them and so that you have a good way to update them properly.
I can't seem to find a good way to create separate Service Layer and Repository Layer assemblies while using ASP.NET Core applications. I am trying to do it with EntityFrameworkCore and Azure Storage. I have found a few workarounds where they use .Net Core apps as assemblies but it cause all kinds of other issues for me as well.
Any help would be greatly appreciated.
Setting up a multi layer Application.
A few things to keep in mind:
The power lays in abstraction, being able to easily replace layers.
A layer/Project has dependencies which can not have circular dependencies!
say your main project has Db models and controllers, and DataAccessLayer has the services. then the DataAccessLayer needs the models from the main project and the Controller needs the services from the DataAccessLayer and thus creating a circular dependency.
Project structure
A simple abstract setup can be:
DbModels project (containing only plain simple objects equal to database tables)
IDataAccess project contain all the interfaces of the DataAcess services. (needs dependency on DbModels)
DataAccessLayer project, implementation of IDataAccess. dependencies: IDataAccess & DbModels
Toplayer project: contains the webApi/controllers. Dependencies: IDataAccess,DbModels and an implementation of IDataAccess, in this case DataAccessLayer.
The DataAccessLayer will ofcourse need EntityFramework as a reference. Also the DatabaseContext should be in this project (and the database migrations).
Also make sure to use the DI/IOC container to register and resolve the services.
This will be your setup for a repository project.
what other problems you run into?
why a repository pattern:
Credits to microsoft
As you can see in this image. A repository pattern is made to being able to easily switch Database.
If you are never going to switch database or use unit tests on dataAccess layer, it't basically not worth it to implement a repository pattern. (too much work, vs the benefit)
I'm not sure what issue you're encountering, but here is a good multi-project starter solution for ASP.NET Core web applications, broken up into projects by responsibility:
Core (domain model, abstractions, services)
Infrastructure (implementation-specific classes)
UI (asp.net core mvc web project)
https://github.com/ardalis/cleanarchitecture
Does that help?
We have a couple of relatively large Web Forms web application projects, but we are limited on using the .net 4.0 because some of our clients are still using Windows Server 2003, and the .net4.5 is not compatible with that OS.
Would it be somehow possible to make the model binding framework created on the .net4.5 work with the .net4.0 WebForms? Maybe something along the lines of extension methods on .net2.0 (although that is obviously almost 100% compile time stuff) or LinqBridge.
If that was possible to some extent, I think I would take the time to do it. Maybe if the code can be extracted from the original sources (I'm downloading them right now to see how it works) and be plugged like an extension or inheritance of sorts in our current page life cycle.
Does that mechanism have some external dependency that would make this prohibitive?
The WebForms-based feature required changes which are only available in 4.5.
That said, if you require model binding in some form, you could always try using the ASP.NET MVC or WebAPI frameworks for the particular part of your site in which you require model binding, leaving the rest as WebForms. They both currently only require .NET 4.0. And you get the benefit that both of those are supported products.
I need to know which permissions are requested by an assembly. With permission I mean for example the WebPermission
Background: I have a service which executes plugins in a sandbox. These plugins are restricted with code-access security. For example: they aren't allowed to access the file system or the registry. Networking is restricted to only http, ...
I would like to analyze these plugins in our build-process to ensure that only classes are used, which are covered by the granted permissions.
In .NET 2.0 through 3.5, the permcalc tool would have allowed you to extract a "best guess" minimum permission set for an assembly. However, the tool has not been updated for .NET 4.0 where, for example, the new transparency approach would have a considerable impact on the analysis results.
AFAIK, there is no permcalc substitute (Microsoft or third-party, commercial or free) available for .NET 4.0. In the absence of such a tool, your best bet for verifying the plug-ins would probably be an appropriate set of integration tests run under the runtime permission set.
Greetings, we have a project with loads of beans, JSP and etc. There is a desperate need for performing automated tests in our environment (we use Maven). Now, we can easily write tests for database project layer, for various security utilities we implemented. But the JSP pages remain untested.
I searched for utilities for server-side testing and Cactus seems the best option. However, according to their changelist, their last release is 1.8 and it was released more than two years ago!
So the question is - what happened to Cactus, is it still developing or what? And what are the recent alternates for Jakarta Cactus (if any exists)?
I've used a combination of Spring, JUnit and HttpClient with some success in recent projects.
Apache HttpClient provides a powerful and flexible API for constructing and sending http requests into your application. It cannot replicate a web browser, say by running client side scripts, however if there is sufficient content within the resulting http responses (headers, URI, body), then you can use this information to traverse pages within the application and validate the behavior. You can post forms, follow re-directs, process cookies and supply the inputs into your application.
JUnit (junit.org) drives the tests, invoking a series of pages with HttpClient and can be deployed alongside the application, run standalone with ant/maven, or run separately inside your IDE.
Spring (springsource.org) is, of course, optional as you may not be using it for your project. I've found it useful to stub/mock out parts of the application, such that I can isolate specific areas, such as front-end controllers, through to the business logic, by substituting the DAOs to return specific data values. It provides an excellent Test Context Framework and specialized TestRunners that hook in well to testing frameworks like JUnit (or TestNG if you prefer).
Cactus served as a good server-side testing framework in the ejb2 ages and but it's not supported anymore.
You can use combination of both Mock testing (fine-grained) and In-Container testing (coarse-grained) strategy to test your application completely.
Mock Testing Frameworks : Mockito, Jmockit, EasyMock etc..
Integration Testing Frameworks (Java EE) : Arquillian, Embeddable API, etc..
I prefer Mockito and Arquillian for server-side testing.
How about Arquillian? I haven't used it and it doesn't even have a stable version yet, but at least it's in active development.
You might want to try selenium. That with jBehave is a good combination I'm finding. And the more support for both those projects, the more they will not go defunct (like cactus).