locked
debugging class errors in ashx files vs2012 RRS feed

  • Question

  • User-1242214802 posted

    Hi All:

    Please forgive me as I've come to rely on VS handling all my classing and namespacing, without ever really understanding the relationship between classes and namespaces. Embarassed

    I have a VS2012 web project which I'm allowing to automatically control the namespacing and classing...in other words, I'm not manually adding namespace directives in my class files.

    I ran into the problem of inadvertently naming a class with the same name as the "Root namespace" of the project, which VS allows me to do, but then throws a compilation error when you run the project.

    After much googling, I stumbled across the suggestion to change the root namespace name in the project properties "application" settings, and VS does a nice job of renaming any automatically prepended class names in the aspx files (VS correctly updates the "inherits" classname when you change it in the application settings).

    The only problem I ran into is in my generic webhandler ashx files. It seems only in those files, the class name is not updated:

    <%@ WebHandler Language="VB" CodeBehind="myfeed.ashx.vb" Class="oldClassName.myfeed" %>

    I stumbled upon that after rebuilding and publishing my project. This class-mismatch doesn't show up when I "build", "rebuild" or "clean" the project, and it doesn't show up when I run code-analysis on the project.

    I'm just wondering why the generic handler is not getting updated, when all the other files in the project are, and if there's any way to catch this class-mismatch when debugging in VS2012?

    Saturday, April 5, 2014 9:57 AM

All replies

  • User-760709272 posted

    Can you just update that file manually?  Not everything is "strongly typed", and files like the one you've mentioned are just text files to VS, it has no way of intelligently analysing it.  It is only when you view the page, or access the handler, and it is interpreted that .net realises you're accessing types that don't exist.  This is one of the issues you have when renaming things, the auto-generated mark-up files often have to be done by hand.

    Saturday, April 5, 2014 12:08 PM
  • User-1242214802 posted

    Can you just update that file manually?  Not everything is "strongly typed", and files like the one you've mentioned are just text files to VS, it has no way of intelligently analysing it.  It is only when you view the page, or access the handler, and it is interpreted that .net realises you're accessing types that don't exist.  This is one of the issues you have when renaming things, the auto-generated mark-up files often have to be done by hand.

    Thanks...I did end up editing all the files by hand, and it fixed the problem. I didn't realize VS treated ashx files differently than aspx...it wasn't a big problem to update, I was just suprised when building the website that VS didn't notice that error, when it seems to pick up those errors when compiling aspx pages.

    Monday, April 7, 2014 3:00 PM
  • User465171450 posted

    This is more of a runtime error that will crop up.

    One way to catch this is to use the Publish Web features. The Settings section of a Publish Web Profile has an option to Precompile during publishing. I've been able to use this to find errors such as inheritance mismatches in .aspx file between the main .aspx file and the codebehind file. The publish will fail and point out the offending file.

    Monday, April 7, 2014 10:13 PM
  • User-1242214802 posted

    This is more of a runtime error that will crop up.

    One way to catch this is to use the Publish Web features. The Settings section of a Publish Web Profile has an option to Precompile during publishing. I've been able to use this to find errors such as inheritance mismatches in .aspx file between the main .aspx file and the codebehind file. The publish will fail and point out the offending file.

    Hi Mark: Thanks for that suggestion. I was not precompiling before publication. I tried pre-compiling and interestingly, it found a couple of other errors that were not impacting the website, but it did not pick up when I deliberately "broke" the classing in the ashx file (my original problem). However, after pre-compiling and uploading, the handler still ran without an error. When I looked at the source file on my project, the error was still there, and it was wrong on the destination server as well...I guess pre-compiling "ignores" the class declaration in the ashx file and uses the compiled assembly?

    In any event, I will continue to pre-compile, even though it allows me to be sloppier with my classing! Wink

    Tuesday, April 8, 2014 7:50 AM