Why can't i put two controls in the same directory*?

  • Thread starter Thread starter K Viltersten
  • Start date Start date
According to the link below, it's not allowed to
place two user controls in the same directory if
one of the controls will contain the other.

http://msdn.microsoft.com/en- us/library/system.web.configuration.tagpre
fixinfo.aspx

While i see it is true, i can't find much info
explaining WHY it is so. My guesses are:
- performance issues
Unlikely

- bad design
Click to expand...

Possibly, but only by proxy
- some secret reason
- miscellaneous stuff
Click to expand...

(see below for above 2)

I have not experimented with it to confirm what I believe, but I think
it has more to do with prefixing the tag. When you include a control in
a control, the contained controlled is given a prefix of say "uc1".

If you put the containing control on the ASPX page, it should recieve
"uc2" so as not to confuse the JIT compiler.

If I am correct, putting both in the same directory can end up with the
IDE assigning the containing control "uc1" and the contained control
will also have "uc1", confusing the JIT compiler on the site and
breaking the page.

Just a thought.

If I am correct, why has this not been solved? Most likely because there
are bigger fish to fry.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************
 
Hello
http://msdn.microsoft.com/en-us/library/system.web.configuration.tagprefixinfo.aspx
Click to expand...


Do you mean ?

"When a source is specified, the user control itself must not be in the same
directory as the page. If it is, you get a run-time error when you attempt
to load the page."

To me it doesn't look they are talking about nested user controls. They are
talking about a user control and its page container (and only when the
Source attribute is used). So it seems much more specific than what you
said...

You could try and see what is the runtime error you get. It could give a
clue about what is the reason behind this (could be perhaps a compilation
issue, depending on the model the whole code in a directory is compiled but
here it could perhaps cause an issue regarding the compilation order i.e.
the control needs to be compiled before the page).
 
Do you mean ?
"When a source is specified, the user control
itself must not be in the same directory as
the page. If it is, you get a run-time error
when you attempt to load the page."

To me it doesn't look they are talking about
nested user controls. They are talking about
a user control and its page container (and
only when the Source attribute is used). So
it seems much more specific than what you
said...

You could try and see what is the runtime error
you get. It could give a clue about what is the
reason behind this (could be perhaps a compilation
issue, depending on the model the whole code in a
directory is compiled but here it could perhaps
cause an issue regarding the compilation order i.e.
the control needs to be compiled before the page).
Click to expand...

Hmmm... I'm rather convienced that i was specific
enough. If you place a user control in an other
user control, you'll get an exception during run-time
given that the source for both is in the same
directory.

It can be resolved by re-registering the inner
control but i was wondering WHY it was that way.
 
While i see it is true, i can't find much info
Possibly, but only by proxy


(see below for above 2)

...I think it has more to do with prefixing the
tag. When you include a control in a control,
the contained controlled is given a prefix of
say "uc1". If you put the containing control on
the ASPX page, it should recieve "uc2" so as
not to confuse the JIT compiler.

If I am correct, putting both in the same
directory can end up with the IDE assigning the
containing control "uc1" and the contained
control will also have "uc1", confusing the JIT
compiler on the site and breaking the page.
Click to expand...

My collegaue provided me with the work-around,
re-registering the control directly in the
affected document. It works but is ugly. I guess,
by using different tagPrefix's, we can avoid the
problem you've discussed.
If I am correct, why has this not been solved?
Most likely because there are bigger fish to fry.
Click to expand...

I'm leaning towards the same explaination. Thanks.
 
And the error is ?

IMO it could be that depending on the compilation model the source code
contains in the whole directory is compiled in multiple assemblies (for
example we could have an assembly per page/control AFAIK). It could perhaps
cause a problem when a page or a control references another control as the
later should be then compiled before...

If the source points to another directory then the compiler knows that what
is in this other directory should be compiled first (and if it points to the
same directory then you are caugth in a circle)...
 
And the error is?

Something about the control being declared
in web.config and living in the same area
or directory as the containing control.
IMO it could be that depending on the
compilation model the source code
contains in the whole directory is
compiled in multiple assemblies (for
example we could have an assembly per
page/control AFAIK). It could perhaps
cause a problem when a page or a control
references another control as the later
should be then compiled before...
Click to expand...

Don't know. It sounds a bit vague and
speculative to me. However, i don't have
any great suggestions myself.
 
Back
Top