Jason Weber
Jason Weber

Reputation: 5741

Debugging in Microsoft Visual Web Developer 2010 Express

Learning MS Visual Web Developer and ASP.NET 4.0. Rather than using the debugging option in MS Visual Web Developer, I seem to prefer to view the page source and hover over the areas that are underlined in the green squiggly style. When I hover over them, it tells me what's wrong, and then I just figure it out what to do from there.

For one particular instance, I had:

<td background="images/separater.png" width="5">

After hovering over it, I replaced it with this:

<td style="background-image: url(images/separater.png)" width="5">

After making the switch, the green squiggly line disappeared, so I assume that, in effect, I debugged that particular snippet. I believe I just made it compatible with the ASP.NET 4.0 Framework.

The only green squiggly lines I leave alone are the ones from social plugins like Facebook plugins. Anyway, my question is: Is what I'm doing (a) correct, (b) important, and (c) just as good as using the debugging option in MS Visual Web Developer?

Upvotes: 2

Views: 1341

Answers (2)

JustBeingHelpful
JustBeingHelpful

Reputation: 18980

I really prefer the "Attach to Process" option in Visual Studio 2010, but if you are using Visual Web Developer (on a server for example for debugging) to debug a web site or web application that has already been deployed, I like this method over using the ASP.NET development server (which is launched by hitting play). Every exception thrown in your application, except from asmx web services are caught in this method if they are not explicitly handled. Just make sure to create an "exceptions" folder in your web root folder. It takes a lot longer for the debugger to launch your application after hitting the play button in Visual Web Developer 2010, so that's why I prefer setting up the site within IIS, and then send your stack trace to a file since that's what you care about anyway. If you need more details about variables from an exception, catch the exception where it occurs, and throw a new exception with that variable value in it. When searching for the latest exception call stack, just open that folder and do a sort on the files.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.SessionState;

namespace WebApplication1
{
    public class Global : System.Web.HttpApplication
    {

        protected void Application_Start(object sender, EventArgs e)
        {

        }

        protected void Session_Start(object sender, EventArgs e)
        {

        }

        protected void Application_BeginRequest(object sender, EventArgs e)
        {

        }

        protected void Application_AuthenticateRequest(object sender, EventArgs e)
        {

        }

        protected void Application_Error(object sender, EventArgs e)
        {
            Exception ex = Server.GetLastError();
            try
            {                
                WebApplication1.Global.WriteDataToFile(null, ex.StackTrace);
            }
            catch
            {
                throw ex;
            }
        }

        public static void WriteDataToFile(string filePath, string contentToWrite)
        {
            if (filePath == null)
            {
                filePath = string.Format(@"C:\web_root\exceptions\debug.{0:yyyy-MM-dd_hh.mm.ss.tt}.txt", DateTime.Now);
            }

            System.IO.StreamWriter sw = new System.IO.StreamWriter(filePath);
            sw.WriteLine(contentToWrite);
            sw.Close();
        }

        protected void Session_End(object sender, EventArgs e)
        {

        }

        protected void Application_End(object sender, EventArgs e)
        {

        }
    }
}

Upvotes: 1

Michiel van Oosterhout
Michiel van Oosterhout

Reputation: 23084

Most ASP.NET developers would not consider this debugging, since you were not using the Debug command F5 to debug server-side code (usually C# or VB.NET code). See Walkthrough: Debugging Web Pages in Visual Web Developer for more details on that process.

What you refer to as green squiggly lines are actually warnings about your HTML. In this case the background attribute for tables is not a part of the official HTML specification and this is what Visual Web Developer Express was warning you about. Consequently, you did not make your code compatible with the ASP.NET 4.0 Framework, but you did make your markup HTML-compliant.

If your code is not compatible with ASP.NET 4.0 you will usually the the yellow screen of death, at which point you may need to debug to find the cause of the error or exception

Example yellow screen of death

To answer your question(s): what you were doing is (a) correct, is (b) important for browser-compatibility, is not (c) related to the debugging capability in Visual Web Developer Express.

Upvotes: 1

Related Questions