If broken it is, fix it you should

Using the powers of the debugger to solve the problems of the world - and a bag of chips    by Tess Ferrandez, ASP.NET Escalation Engineer (Microsoft)

April, 2006

  • If broken it is, fix it you should

    ASP.NET 2.0 Crash case study: Unhandled exceptions

    For a long time all my case studies have been on 1.1. it’s time to venture out in 2.0 land and look at what may seem like a 2.0 specific issue. I say “may seem” because this case study will only directly crash if you are using 2.0, but as you’ll learn later the problem existed in 1.1 and 1.0, it was just way harder to track down. Problem description: Once in a while ASP.NET crashes and we see events in the system event log like this one Event Type: Warning Event Source: W3SVC...
  • If broken it is, fix it you should

    ASP.NET Memory: If your application is in production… then why is debug=true

    Statement “Ensure that the debug="false" on the <compilation> element in the web.config file of each and every ASP.NET application on the server. The default during development is "true" and it is a common mistake to allow this development time setting to find its way onto production servers during deployment. You don't need it set to true in production and it often leads to memory overhead and inefficiencies.” What problems does leaving debug=true cause? There are three main...
  • If broken it is, fix it you should

    ASP.NET: Strong named assemblies should not be stored in the bin directory

    Statement “In ASP.NET 1.1, do not deploy strong named assemblies to the BIN directory (i.e. if they are strong named make sure you DO put them in the GAC).” What problems do storing strong named assemblies in the bin directories cause? In ASP.NET 1.1, strong named assemblies are loaded as “domain neutral”. As you probably already know every asp.net application lives in its own application domain (a unit of isolation inside an application), and assemblies used by this application...
  • If broken it is, fix it you should

    ASP.NET Memory: You use the same dll in multiple applications, is it really necessary to load it multiple times?

    Statement “Wherever possible strong name and install to the global assembly cache (GAC) any assemblies that are used by more than one ASP.NET application. This will reduce memory consumption.” What problems do storing common assemblies in the bin directories cause? Let’s say you host an e-commerce site and you have group of dlls for common tasks such as verifying user information, perhaps some special grid control, shopping cart, some business rules dlls etc. and you have ten different...
  • If broken it is, fix it you should

    ASP.NET: Check your Web Site today for these common assembly related memory and perf issues

    Recently my colleague Doug wrote a nice post on Nine tips for a healthy "in production" ASP.NET application . I have been planning to post about some of these for a while, so I decided to steal some of his points and expand a bit on them, and also show you how you can identify them in a memory dump. As most of you know I like to go into great detail about things J so to make it a bit more manageable I have divided my posts up into 3 different parts (one per statement that Doug makes in...
Page 1 of 1 (5 items)