In this post I will show you an interesting problem that we experienced when querying a SQL Server database with Dapper. I will use a simplified data model and a sample application so you could reproduce the issue on your own. Our sample table will look as follows:
create table Stats ( StatsDay datetime not null, EventName varchar(100) not null, Item varchar(100) not null, Value int null, constraint PK_Stats primary key(Item,EventName,StatsDay) )
Elmah is a great exception logger for web applications. Next to the exception data (stacktrace, exception message etc.) it collects detailed request and runtime information. If I also mention that it’s easy to install and highly configurable it comes with no surprise that it became an industrial logging standard for .NET web applications. Elmah gives you a great choice of places where you can send your logs, though a database is the one I consider most useful. What I also value in Elmah is its log viewer (elmah.axd) – it has a nice exception list and a great exception details screen – I wish the ASP.NET Yellow Screen of Death had that look . The only thing I don’t really like in this viewer is a fact that by default it is bound to the application that has Elmah installed and is accessible only under
http://<app-url>/elmah.axd. If you do not secure access to this handler everyone can see detailed information on your code and environment – just have a look how many developers forget about it. In this post I will show you how to remove the elmah.axd handler from your application and how to create a separate ASP.NET application that would be a central Elmah log viewer for your applications.
In today’s post I will show you how we fought a pesky compilation problem with Razor views in our ASP.NET MVC application. One of the parts of our application is an email-sending engine which uses Razor templates to create message bodies. After deploying this app on IIS we started receiving the following errors (unimportant parts are stripped):
... Line: 0\\t Col: 0\\t Error: Metadata file \u0027ev-server/dev2/appname/bin/EmailSystem.Client.DLL\u0027 could not be found //------------------------------------------------------------------------------ // \u003cauto-generated\u003e // This code was generated by a tool. // Runtime Version:4.0.30319.235 // // Changes to this file may cause incorrect behavior and will be lost if // the code is regenerated. // \u003c/auto-generated\u003e //------------------------------------------------------------------------------ ...
The first line suggests that it’s a compilation problem, but we didn’t really know exactly which part of the application was throwing it. I thought having a full compiler command line might help us. Unfortunately gathering it from ASP.NET application is not so easy.
In this post I will describe for you an interesting problem that my colleague ran into at work. His original VS solution consisted of two projects targeting .NET 3.5 – let’s name them Alpha and Beta. Alpha had a direct reference to Beta and thus depended on it. Beta was using NHibernate, Castle.Core and some other libraries. During compilation Alpha he received:
c:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9): warning MSB3258: The primary reference "PathToBeta.dll" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=18.104.22.168, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "22.214.171.124" than the version "126.96.36.199" in the current target framework.
and the whole build failed with:
Error 3 The name 'Beta' does not exist in the current context
I recently needed to diagnose an interesting problem with one of our Topshelf Windows Services. The service ended in a StopPending state and we needed to kill it in order to make it work again. But before killing the service we collected a process dump for further analysis. In this post I will show you what I read from this dump and how this information might help you better understand your own Topshelf applications.
Today’s post is dedicated to NLog – one of the logging libraries available for .NET developers. NLog has a lot of features and options but also might seem complicated on first sight. Checking the examples should usually allay your fears but it will still take you some time to get along with NLog’s syntax and configuration. I will try to make the learning curve less steep by providing you with configuration options that are currently working in my projects. If you are new to NLog I recommend you to have a look at its tutorial before reading on.
In this post I will show you how to create a very simple Windows Service (I will call it Musketeer) that will collect information about other processes running on a server. Such a tool might be helpful if you host Windows services on some remote server and you want to store information about their performance in a database for further analysis. This tool might also be a cure if your admins didn’t give you enough privileges to connect the Performance Monitor to the remote server:)
The majority of modern applications use ORMs as a way to connect to a database. Those libraries simplify the usage of the underlying ADO.NET API in a way that we might even forget that under the hood we are dealing with a relational model. This object-oriented wonderland usually lasts till the moment when the first SQL exceptions crop up. If we configured our ORM correctly we should be able to diagnose database problems with just logs that it provides. But what if we didn’t or if the problem lies deep in the ADO.NET layer? We might then try to use a debugger or a SQL Server Profiler. Both those tools, although great, are usually too heavy (or too invasive) for a production environment. Fortunately there is still one option left – ADO.NET ETW tracing. In today’s post I will show you how to turn on this type of tracing and how to use it to quickly diagnose some database problems.
In today’s post I will describe different security settings of the application pool and the IIS6 directory. It’s not always easy to guess which permissions must be set on system folders and files in order to make the application run correctly. I will also show you how to diagnose those pesky security problems using available tracing options.