Type Reflection and Code Directory

[Andrew Feldman]

Is someone from MS listening? Every thread I've seen on this topic
goes dead. Even the MVP's don't seem to have an answer.

My problem:
I'm working with ASP.NET 2.0 Beta 1. I have all web application
instance-specific code factored into the /code directory of my web
project. I have custom EventArgs/Handler's for my current web app
instance that I would like to create and use dynamically via
reflection, from a web control in the same web project. The statement
Type.GetType("myCustomEventArgsType") returns null. I've seen some
posts online about specifying the assembly qualified name as in
"myCustomEventArgsType,Code", but this appears to be an out of date
piece of advice as the dynamically generated assembly has an
autogenerated name. The funny thing is that intellisense picks up this
type at design time, it is just unavailable, or unreachable, at
runtime.

This "feature" severely limits the dynamic capabilities of web
applications built in Whidbey. As we all know this was all possible in
1.1 as the web project was compiled into a well known DLL. I know big
changes are coming in Beta 2, but I would like to know for sure whether
these changes will alleviate this problem, and if there is any possible
work around in current Beta 1 bits. Thank you.

 

[Scott Allen]

Hello Andrew,

Are you calling GetType from code that is inside that dynamic assembly? With
specifying
an assembly name I believe get type only looks in the current assembly and
mscorlib.

 

[Andrew Feldman]

I assume you mean "WithOUT specifying an assembly name..."

The problem is that in ASP.NET 1.1 the entire web project was compiled
into a single dll with a well known name, and all types in it were
visible to each other. With the /code directory being compiled into
its own dll, with a randomly generated name, how am I supposed to
utilize any of these types at runtime? Sure the /code directory is
neat, and useful at design time, but without the ability to utilize it
at runtime severely reduces its utility. Again I realize that this is
a premature product, and that changes are coming, but certainly I am
not the first one to encounter this problem and so (hopefully) someone
has found a workaround.