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
// 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.
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.
UPDATE 2016-11-11: This issue seems to be fixed (checked on .NET 4.6.1586.0), and a valid version of GAC is used, depending on the framework version the application is using. I will keep the post for reference.
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=22.214.171.124, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "126.96.36.199" than the version "188.8.131.52" 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.
This post will be short and is inspired by Robert’s comment under my previous post (Thanks for it!). Robert pointed (and I completely agree) that it might be useful to have application assemblies versions listed in the log output.
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.
ASP.NET Health Monitoring is one of the framework gems that is often forgotten by ASP.NET developers or web server administrators. It provides great monitoring features, often allowing you to rapidly diagnose failing applications or systems. Have you ever wondered why ASP.NET errors appear in the system event log? It’s thanks to the ASP.NET Health Monitoring and its configuration in the master web.config file (the one stored in the framework installation directory):
<add name="All Errors Default" eventName="All Errors" provider="EventLogProvider"
profile="Default" minInstances="1" maxLimit="Infinite" minInterval="00:01:00"
<add name="Failure Audits Default" eventName="Failure Audits"
provider="EventLogProvider" profile="Default" minInstances="1"
maxLimit="Infinite" minInterval="00:01:00" custom="" />
Let’s analyze quickly the above snippet. A
rule defines which ASP.NET health events will be logged (
eventname) by the chosen
provider and at what frequency. The ASP.NET health events hierarchy can be found here. The event name used in the
rule definition is the name of the mapping that is defined earlier in the web.config file. An example event mapping looks as follows:
In this post I’m going to show you how to diagnose SQL exceptions using memory dumps. Imagine you have a web application deployed on a production server. Your application is using Elmah configured to log all exceptions to a dedicated table. One day you receive information that users are unable to make orders and in the Elmah log there are lots of
SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and 12/31/9999 11:59:59 PM.
at System.Data.SqlClient.TdsParser.TdsExecuteRPC(_SqlRPC rpcArray, Int32 timeout, Boolean inSchema, SqlNotificationRequest notificationRequest, TdsParserStateObject stateObj, Boolean isCommandProc, Boolean sync, TaskCompletionSource`1 completion, Int32 startRpc, Int32 startParam)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task&amp; task, Boolean asyncWrite)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task&amp; task, Boolean asyncWrite)
No more information available. If you are using NHibernate you may turn on SQL logging but, if you have thousands of users, this will have a negative impact on the application responsiveness. Another idea might be to use ADO.NET ETW logs – even though this way we will minimize the performance drop, it’s still not a perfect solution. ETW logs weigh hundreds of MB and contain a tremendous amount of information, which you need to filter and analyze. I plan to write about this type of logging in the future. For now, let’s take a third approach: create a production memory dump when the application breaks and analyze it locally in the debugger.