ASP.NET runtime error : Ambiguous Match found

Question

Recently, my team converted ASP.NET project from .NET 1.1 to .NET 2.0. Everything is pretty good so far except for one web page.

This is the error message I got when I tried to open this page:

Server Error in '/' Application.

Parser Error Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.

Parser Error Message: Ambiguous match found.

Source Error:

Line 1: <%@ Control Language="c#" AutoEventWireup="false" Codebehind="Template.ascx.cs" Inherits="eReq.Web.WebControls.Template.Template" TargetSchema="http://schemas.microsoft.com/intellisense/ie5" %> Line 2: Line 3: function ExpandCollapse_Template(inBtn, inSection, inSectionID) {

Source File: /WebControls/Template/Template.ascx
Line: 1

-------------------------------------------------------------------------------- Version Information: Microsoft .NET Framework Version:2.0.50727.3053; ASP.NET Version:2.0.50727.3053

I tried renaming class and renaming filename but it didn't work.

Anyone have any idea on this?

Radnorshire

Answer 1

It may appeared because of different names of components? for example Button1 and button1, it compiles as casesensitive, but executed as caseinsensitive.

Bora

The project compiled without any problem. Running this web app froom any other pages are fine except this page. I believe this is a runtime error. In Visual Studio 2008, there is a blue underline under the directive line in the Template.ascx file saying "ASP.NET runtime error : Ambiguous match found." – Radnorshire

I found it at last... Thanks x2. There's a user control that use different cases in ASCX and CS file. I guess this is because .NET 2.0 is more strict with cases... Can anyone confirm this? – Radnorshire

Another note here - .NET doesn't do a good job that I've seen of specifying which controls/variables are having a conflict. On my page I had one variable called 'bannerImage', a String, and another 'BannerImage', a PlaceHolder control and I was lucky to find the two... – Defecate

You can catch this at compile time with an MS build task: onpreinit.com/2009/09/ambiguous-match-found_30.html – Mclaren

for example Button1 and button1, it compiles as casesensitive, but executed as caseinsensitive. what does this means? in runtime they both are same? – Cresol

same name for a control and a variable on server side – Fe

This is my problem as well! Thing is, my page consists heaps of controls, textboxes etc., do you guys know a way to simplify the search? – Tornado

Answer 2

In your ASCX file, go through each and every control and change its id. For example,

<asp:TextBox id="foo" />

change it to

<asp:TextBox id="foo1" >

You've probably got a control with an ID that matches a property in your ascx file, so when the compiler is trying to make instance variables its colliding.

Trochaic

Answer 3

I've the same problem and it solved and the solution is in check your code behind and you will find a couple of Controls with the same name:

protected Button Home;

protected System.Web.UI.HtmlControls.HtmlAnchor home; 

you have to erase one line or comment it.

Mouth

Answer 4

I'd trawl your web.config for 1.1 and 2.0 references to the same DLL. In most cases that I have gotten this it was System.Web.Extensions.

Also check the @registers in Pages if that fails.

Good luck (it is not a fun bug to find!)

Dan

Worldbeater

Answer 5

Same Name Id in aspx file and property inside aspx.cs file

when .aspx page and behind aspx.cs class contains Same property this kind of problem occur. When I am searching the solution for this problem.. not found any useful content. finally I solved the problem by renaming private property name to different inside aspx.cs class attached image as screenshot.

if anyone still facing the problem you may try

Screenshot 1 Screenshot 2

Organicism

Answer 6

This is due to what can only be described as a defect in System.Web.UI.Util.GetNonPrivateFieldType(Type classType, String fieldName) that allows UI (.aspx/.ascx) fields to compile as case-insensitive but attempts to retrieve them as case-sensitive during the intial parse.

A potential remedy for the time being is to catch it at compile-time with an ms-build task.

Mclaren