Debug.Assert does not launch a popup window on IIS7 while debugging in Visual Studio

If you are trying to debug an IIS 7 hosted web application using Visual Studio and trying to use System.Diagnostics.Debug.Assert()/System.Diagnostics.Trace.Assert() in your code to launch a popup window it will not work. However you can write the output to a log file using the following:

    <assert assertuienabled="true" logfilename="c:\\myFile.log" />

You can also get the output of Debug.Assert (..) in the Output window within Visual Studio. It will also be logged in the System event log. However, this seems to work with the earlier version of IIS, i.e. IIS 6.0 in the console session.

After going through various forums I see that developers do complain about this being a deprecated feature in IIS 7+ versions which hampers debugging.

However In my opinion it should *never* have worked in the first place for any service based application. ASP.Net application runs as a service on the server side and it should never launch an interactive window which might lead to the process getting into a hung state for all the clients. Lot of times developers miss deleting one of these entries from their code before moving it to the production environment and that leads to hang/frozen condition for the application for all the end users. This is not specific to IIS or ASP.Net in my opinion but manifestation of a feature from Vista onwards at the OS level. Session 0 isolation in Vista onwards prevents services from interacting with user sessions in the way it was possible in the previous versions of Windows like Windows Server 2003.

Important  All services run in Terminal Services session 0 from Vista onwards. Therefore, if an interactive service displays a user interface, it is visible only to the user who is connected to session 0. Applications running in other sessions cannot access Session 0 GUIs. Because there is no way to guarantee that the interactive user is connected to session 0, do not configure a service to run as an interactive service under Terminal Services or on a system that supports fast user switching.



Comments (1)
  1. Pavel says:

    What's the problem with assertions in production environment? Why delete Debug.Asserts ?? In Release builds all Debug.Assert calls are removed by compiler, so that's not an issue.

    If a developer deploys a debug assembly… well, it's his own problem. I aggree that it should be difficult to enable these popups, but there should be a way, because Debugger.Break() still works. 😉 But I want my ASSERTS!

Comments are closed.

Skip to main content