Total Frustration: Ambiguous Match Exception with WebForms
A colleague has called me over to see why a page was failing with Ambiguous Match Exception yellow screen of death. There was a simple change made to the page, that broke it, I tried the usual trouble shooting methods* (restarting VS & ISS, cursing, etc) but that failed to fix it. I moved to code to my machine and verified that it was completely reproducible across machines. Then we started to pick apart the changes, literally line by line.
The problem turned out to be this line:
IList<string> products = new List<string>();
Only then we remembered that the page also had a text box called "Products", which apparently caused the WebForms Parser to choke and die. Really nice way to make sure that we would both lose over an hour of work, trying to find the root cause of an opaque problem.
* Take it for what it worth, but I am sad that I know that in many cases, those methods actually work...
Comments
so Resharper didn't help in that case?
Ahh the joy, we now use variables that refelct the control type as well as the content to stop this kind of issue - e.g. ProductsTextBox.
For me it helps to use prefixes. Txt, lbl, ddl, dg, dl etc. Mostly to group control for entillsense. Means that you collect the data from form, just start to type "txt"... and you see which text inputs need your care.
Not really, it was an error that occured only on runtime, no issue when compiling.
I had read about this issue a while back and suffix all controls with a '1' like the designer creates to avoid this stuff and so I can reflect on view interfaces with a simple naming convention.
Didn't it help to diff against the latest working revision. That's what I do even before I restart VS ;-)
It's an error with the asp.net compiler. While C# is case sensitive, this compiler seems to not be.
You will also get those errors if you try to compile the virtual directory using the aspnet_compiler.exe command line tool.
The error happens when it's compiling the ASPX file and the CS file into a single unit.
****@robert : I used to prefix the controls with the ControlType like you suggest, but then its a mess when you change they type of control you're using. For instance, going from a Literal to a Label, or DropDownList to RadioButton, etc...
I've moved to a convention of prefixing the control names with ux, for User eXperience. This approach still results in nice groupings in IntelliSense while making the controls a bit more generic from the naming perspective.
@Markus,
It did, that is when we started to do a line by line change. I didn't even consider that line, forgot that I even had such a control