[MonoDevelop] asp.net codebehind member generation fails due to tag not registered
Michael Hutchinson
m.j.hutchinson at gmail.com
Sat Jul 26 19:25:30 EDT 2008
On Sat, Jul 26, 2008 at 1:33 PM, Jhon <jhon at anset.org> wrote:
> Hi,
>
> Monodevelop autogenerates asp.net member variables in the codebehind page.
>
> I recently started using the javacontroltoolkit and now this auto
> generation fails with the following error:
>
>
> CodeBehind member generation failed with error The tag type
> 'ajaxToolkit:ValidatorCalloutExtender' has not been registered.. Further
> CodeBehind members for this file will not be added.
>
>
> If I have to put the toolkit variables in myself, no problem, but now
> the generation stops for the rest of the file and that I find is a pity.
>
> What does monodevelop mean with "tag registration"? I've registered the
> tag propperly in the web.config file and I have tried adding the
> Register tag in the page itself and in the MasterPage, but nothing
> seeems to work.
>
> I've done my best googling for any information about how I can register
> this tag wit monodevelop but came up wit nothing usefull.
>
> Not givving the controls an ID would mean monodevelop does not need to
> generate a codebehind variable. However, due to a bug in the toolkit,
> all the controls get the same ID by default and that means the page
> won't compile. So I have to give the controls a unique id.
>
> If anyone here can offer some help or point me in the right direction, I
> would very much appreciate it.
MonoDevelop parses the pages itself and resolves control types in
order to generate the CodeBehind fields, as the standard ASP.NET APIs
don't really expose anything for doing this sort of thing. There are a
few things that /look/ almost appropriate, but in practice don't work
well in an IDE, for example they need to reflect into the referenced
assemblies.
To resolve control types, MD tries to resolve the tag registrations
the same way the ASP.NET would. Unfortunately MD 1.0's handling of
third-party controls is a little flaky, as I had very few examples
with which to test it. MD 2.0 should hopefully be somewhat improved in
this regard.
--
Michael Hutchinson
http://mjhutchinson.com
More information about the Monodevelop-list
mailing list