S
Svetoslav Vasilev
Hi, I am probably not the first, neither the last one to come along a problem
in ASP.NET 2.0 applications resulting in an 'Ambiguous match found' error
during parsing of pages/user controls.
To me however the problem worked somehow weired since it appeared after
converting one ASP.NET 1.0 project to ASP.NET 2.0. You might exclamate that
it explains everything and shouldn't read this comment further, but let me
make this a bit more intriguating - the conversion was done with the Web
project support extension for VS 2005. This means that there is no need to
stick to the new web site model in ASP.NET 2.0 - it is a 1 to 1 match with
what it used to be in VS 2003, eg. no partial classes, no ASP.NET folders, no
crap.
So, lets cut to the chase. The web app i have is constituted mainly of user
controls that are loaded dynamically in another user control, that on its own
is loaded in a page. It is a proven architecture that's been running for the
past 2 years. However, the new ASP.NET 2.0 runtime proved it wrong. The
bottomline is simple - there is a user control A that dynamically loads
another user control B. The user control A contains a member variable of type
control C, named c. The user control B has an instance of the control C,
which is defined as a custom tag in the .ascx file. The ID of the element, as
well as the name of the member variable of type control C, defined in control
B, is c as well.
So when control A loads control B, the exception AmbiguousMatchException is
thrown. Astonishing, since in ASP.NET 1.0 it works just fine!
I had to use the WinDbg in order to track where it actually happened since
I've got way to little info from the exception itself. It appeared that the
problem lies in the fact that the member variables of type control C in both
parent controls A and B are named equally. The exception is thrown inside the
Syste.RuntimeType.GetField() method when trying to create instance of control
C in control B.
To me it appears that the ASP.NET 2.0 runtime does not take into
consideration the access modifier of the member variable at all(they are
protected). Logically there should be nothing in common between those 2
variables dispite the same name, and this is the case in ASP.NET 1.0. They
are basically located in separate instances of different user controls, which
means totally isolated from each other. The only relation of those controls
is that one contains the other through aggregation. It is as if the ASP.NET
2.0 runtime makes this relation appear as inheritance during instantiation.
The workaround that first comes into mind of course is to rename the member
variable of type C in control B, which is exactly what i did. But this is a
quick fix. I cannot imagine how many developers have to suffer and do the
same thing, just because the ASP.NET runtime suddenly started behaving
differntly.
If this issue is acknoledged as a bug, I hope that the ASP.NET team will
look seriously in it so that it can be soon solved, and web developers can
continue to focus on more important business logic matters, rahter than
renaming variables in order to make their apps run again in the new
environment.
If not, let me know where I make mistake.
Best regards.
in ASP.NET 2.0 applications resulting in an 'Ambiguous match found' error
during parsing of pages/user controls.
To me however the problem worked somehow weired since it appeared after
converting one ASP.NET 1.0 project to ASP.NET 2.0. You might exclamate that
it explains everything and shouldn't read this comment further, but let me
make this a bit more intriguating - the conversion was done with the Web
project support extension for VS 2005. This means that there is no need to
stick to the new web site model in ASP.NET 2.0 - it is a 1 to 1 match with
what it used to be in VS 2003, eg. no partial classes, no ASP.NET folders, no
crap.
So, lets cut to the chase. The web app i have is constituted mainly of user
controls that are loaded dynamically in another user control, that on its own
is loaded in a page. It is a proven architecture that's been running for the
past 2 years. However, the new ASP.NET 2.0 runtime proved it wrong. The
bottomline is simple - there is a user control A that dynamically loads
another user control B. The user control A contains a member variable of type
control C, named c. The user control B has an instance of the control C,
which is defined as a custom tag in the .ascx file. The ID of the element, as
well as the name of the member variable of type control C, defined in control
B, is c as well.
So when control A loads control B, the exception AmbiguousMatchException is
thrown. Astonishing, since in ASP.NET 1.0 it works just fine!
I had to use the WinDbg in order to track where it actually happened since
I've got way to little info from the exception itself. It appeared that the
problem lies in the fact that the member variables of type control C in both
parent controls A and B are named equally. The exception is thrown inside the
Syste.RuntimeType.GetField() method when trying to create instance of control
C in control B.
To me it appears that the ASP.NET 2.0 runtime does not take into
consideration the access modifier of the member variable at all(they are
protected). Logically there should be nothing in common between those 2
variables dispite the same name, and this is the case in ASP.NET 1.0. They
are basically located in separate instances of different user controls, which
means totally isolated from each other. The only relation of those controls
is that one contains the other through aggregation. It is as if the ASP.NET
2.0 runtime makes this relation appear as inheritance during instantiation.
The workaround that first comes into mind of course is to rename the member
variable of type C in control B, which is exactly what i did. But this is a
quick fix. I cannot imagine how many developers have to suffer and do the
same thing, just because the ASP.NET runtime suddenly started behaving
differntly.
If this issue is acknoledged as a bug, I hope that the ASP.NET team will
look seriously in it so that it can be soon solved, and web developers can
continue to focus on more important business logic matters, rahter than
renaming variables in order to make their apps run again in the new
environment.
If not, let me know where I make mistake.
Best regards.