Archive for the ‘Debugging’ Category

String Comparison Fails And String Contains A Dash

January 14, 2011

Our Integration Partner, using a Web Service of ours via their Workflow application, was complaining that our WCF Service was broken in the UAT environment.

The error logs showed this:
2011-01-13 16:23:07,645 [5] ERROR Error in PerformPolicyLookup PolicyNumber: 9999999 Error: Unknown client name “SmithsCrisps – NZ”

But when I accessed the same Web Service through a Visual Studio Project running on my Desktop the Web Service call ran fine.
The URL for that Web Service had changed just a fortnight back so I suggested that maybe they were not accessing the correct Web Service and that they needed to check what URL they were using or maybe regenerate their proxy classes.

Well their Developer got back to me and said that in the Database the dash in “SmithsCrisps – NZ” was stored as an Elongated Dash, properly known as the em Dash, Unicode 2014, whereas the Web Service tested for Client Name based on the en dash, Unicode 2013.

…which doesn’t really add up since the actual Client Name parameter must have been passed as an Elongated Dash (em dash) if it ended up actually matching records on the database, but yet it supposedly also matched against en dash in the parameter validation part of the Web Service call.

So he reckons he updated the Database to use en dashes (the short ones).

…sounds a bit fishy.

But anyway, for our purposes, if you find a String Comparison is failing and the String in question has a Dash in it then be aware that there are several different kinds of dashes.Everthing you ever wanted to know about Dashes is here courtesy of the ubiquitous Wkipedia.

Naturally, dashes can be things that matter most

And one more thing: make sure there are no hyphens in the mix as well or else you may find yourself requiring medical assistance.

CS0246: The type or namespace name ‘BaseUserControl’ could not be found (are you missing a using directive or an assembly reference?)

November 25, 2010

There’s more than one way to get an error message and I found a brilliant way to get this one.

Get this. It can come about when the Start Page of your .NET Project contains a @Register Directive to a UserControl which does not compile.

And now the embarassing part: the confession

So we have this .NET Project which contains Factory Classes which load a different set of UserControls, and Data Access Objects depending on which region is configured in web.config.

But the code written for the Jyvaskyla region (JV) is old and is not intended to be executed so we unload the JV folder from the Project before compilation. But one of the pages Dog.aspx Registers the Jyvaskyla DogBreath control which itself inherits from BaseUserControl. Like so:
%@ Register Src=”~/JV/Controls/DogParts/DogBreath.ascx” TagName=”JVDogBreath” TagPrefix=”uc2″ %

…and in my newbie ignorance to this particular .NET Project I thought that Dog.aspx was the Visual Studio Start Page for the Projec, so that’s what I selected from the Solution Explorer Context Menu.

When I hit F5 to run the Project Dog.aspx was loaded and it went on to register the magnificent JVDogBreath control which it couldn’t because the @Register Directive syntax above forces a dynamic compile of the source code, which as I told you before, does not compile.

And why doesn’t it compile ?

As the error message said, missing namespace for its base class, ‘BaseUserControl’.
The source code for the JVDogBreath starts off like so:

public class JVDogBreath : BaseUserControl
{
…etc
}

That doesn’t compile necause BaseUserControl was not referenced properly. Since it lives in the BaseDogParts namespace it should have been:

public class JVDogBreath : BaseDogParts.BaseUserControl
{
…etc
}

or else in my usings…
using BaseDogParts

Yeah, so I was ambushed by a redundant @Register Directive in combination with me setting the wrong Start Page.

Visual Studio: Cannot Step Into WCF Service Hosted In IIS

October 25, 2010

If you are reading this then you are probably a complete newbie like myself to WCF. Never mind. We can huddle here together for warmth.

So in my case I had a WCF Service running on localhost under IIS and a Client that consumed that Service running under Cassini. There was a Breakpoint in my Client code on the call to my WCF Method and when I hit that breakpoint and hit F11 then the debugger would step into it as obediently as Frankenstein’s Monster on an assassination mission. I was as smug as a 200kg Tabby Cat locked in a Cream factory over the Christmas holidays.

My client app and my WCF app were in different solutions and open in different instances of VS2008.

Then I made my critical mistake – I went to Lunch.

During my absence tiny invisible super-intelligent Manta Rays from the Planet QUARX sabotaged my apps so that I could no longer step into the WCF code from my client. My Team Lead could not figure out why either.

Well about 96 Google Minutes later I found this hyper-simple solution (remember, we’re newbies here) on TroubleShootingWiki.org.

I slavishly did what they suggested which was in the VS2008 instance hosting my WCF Solution, select Debug from the main menu and…

select process aspnet_wp.exe from the list of available processes, and click the Attach button. You will find this process attached to the debugger. Open the HelloWorldService.cs file and set a breakpoint if you haven’t done so already. Now run the HelloWorldClient program…from another Visual Studio instance…and you will see that the breakpoint is now hit.

Good news: The tiny hyper-intelligent Manta Rays are gone and the Tabby Cat is back. Pass me the Triple Fat thanks.

Yet Another Reason Why Breakpoints Will Not Be Hit In Visual Studio: You are running Cassini.

February 24, 2010

I would imagine this is probably the most common reason why breakpoints are not hit: the Web Application is running under Cassini.

Cassini is the built-in Web Server that comes with Visual Studio 2005/2008. It’s a lightweight Web Server provided to spare you the trouble of setting up IIS on your local machine. But being lightweight it can’t do everything and one thing it cannot do is provide debug support. This ASP.NET forum post, ‘Debugging aspx hosted by Cassini’ provides some discussion on the issue.

To debug in Visual Studio when running Cassini you have to manually attach the debugger to the Cassini Process.

To paraphrase Kiliman in his forum post:

In VS.NET, it’s Debug | Processes…

Find WebDev.WebServer.exe in list of running processes and click Attach. Make sure Managed Code or Automatic is selected from the Attach To: DropDownList

If you don’t want to manually attach the debugger every time, then make your site IIS based then go to the Project Properties and change your settings from from internal webserver to IIS.

Here’s an interesting tip from an old Cassini information page for Framework Version 1.1 that allows you to Debug under Cassini without manually attaching that might still work in later Framework versions. I haven’t tried it myself yet. Basically you make Cassini the Start Application for your Debug Build Configuration and define your Web App as a Command Line Parameter.

The reason that Cassini cannot participate in Visual Studio .NET Debugging without the debugger manually attaching to the process is that Visual Studio Debug Builds send a special (non-standard) HTTP Request to the Server using the DEBUG Verb called a Debug HTTP Request. IIS knows how to handle Debug HTTP Requests but Cassini does not.

The DEBUG Verb is used by IIS to verify that the process of the application is running and to automatically select the correct process to attach the Visual Studio debugger to. Its a non-standard HTTP Verb invented by Microsoft for its own purposes, that’s why generic Web Servers like Cassini don’t handle it. See Stack Overflow here.

Breakpoints Not Hit Visual Studio 2005 on Vista

April 29, 2009

This one had me ready to gouge out my eyeballs, perform virtual self-immolation (Google the Dilbert strip if you can), or along with Captain Black of Catch-22, eat my liver.

Recreating Gouge Conditions
I created a toy website in Visual Studio 2005 on Vista, the breakpoints were hit ONCE but never again.

The reason, quite simply, is that on Vista you need to expressly Run Visual Studio as Administrator if you want your breakpoints hit. i.e. go to the Program Launch button in Vista, find Visual Studio 2005 and right-click ‘Run as Administrator’ on the context menu. Infuriatingly simple.

For this I humbly thank Vinblad from this Microsoft Visual Studio Debugger Forum thread who got the info from the blog of the intruigingly named Stephen Quattlebaum.

Stephen explains it:

Visual Studio 2005 starts IE by default when you debug an ASP.net project and (here’s the kicker) stops the debugger automatically when the IE process that it started shuts down.

The issue is that, due to protected mode in Vista, IE likes to restart itself immediately after it is started. As a normal user, you never notice, but it makes debugging IE in Vista hard b/c the process that you started dies right away, and a different, unrelated process starts up. The upshot is that just hitting F5 to start debugging in Visual Studio fails b/c the debugger starts up…and then immediately shuts down, b/c the process it was debugging died right away.

To always allow Visual Studio 2005 to Run As Administrator Browse to your install dir (C:\Program Files\Microsoft Visual Studio 8\Common7\IDE) and open the properties for devenv.exe. Switch to the compatibility tab and select “Run this program as an administrator”. Thanks to Eric Appel’s Digital Life

More
Here’s some more reasons why your breakpoints are not being hit:

1) You have deployment retail=true in machine.config (a Best Practice!)

2) You have selected a Production build as opposed to a Debug build from the ConfigurationManager and hence no debug symbols were generated.

3) You have been mucking around with stuff you don’t understand.

Don’t say you haven’t been warned.

Breakpoints Never Hit But Symbols Appear To Be Loaded

August 11, 2008

I was mucking around practising Javascript on a toy website I had made (using Web Site Project in VS 2005) and started up the VS debugger. To my deep consternation, none of my breakpoints were getting hit even though the breakpoint was set property and there was no warning about ‘symbols not loaded’.

The reason for this turned out to be that I had inadvertently published my WebSite. A published website does not generate pdb symbols on build and hence cannot be debugged.

(NB: I only admit this publicly to save you the same embarrasment – so stop laughing and send money 🙂 )

How Can I Tell If My WebSite is Published ?
It will have a PrecompiledApp.config associated with it. You will also find the Project folder for your site your site find has a sub-folder called PrecompiledWeb which contains an ‘appname’  folder which itself contains PrecompliedApp.config. e.g. Let’s say your Web Project is called “DogFood”. Your precompiled web site will have the following folder structure under ‘Visual Studio 2005’

  • Visual Studio 2005/Projects/DogFood
  • Visual Studio 2005/Projects/DogFood/PrecompiledWeb/DogFood
  •                 PrecompiledApp.config
     

Related Posts
This post, “Why The Debugger Will Not Hit Your Breakpoints” on MSDN Blogs caused the necessary neurons to fire.

Keep Out Of The Reach Of Children
How did the web site accidently get published ? Well…err… it appears that SOME MANIAC COMPLETELY UNBEKNOWNST TO ME right-clicked on the web site project in Solution Explorer and selected ‘Publish Web Site’. Simple, quick and deadly. It should have a skull and crossbones icon on it, or be marked ‘don’t click under any circumstances’ or something…

How To Unpublish Your Web Site
I don’t think you can. But you can apparaently force a published Web Site to build with debug symbols using aspnet_compiler -d from a Visual Studio command prompt. See the post cited above for details.