dstruve,

The reason I asked if you upgraded recently is because we got all sorts of errors like this when we upgraded from 3.0.13 to 4.0.3. It was almost as if entire chunks of the database didn't survive the upgrade. In the end we went back to a full working copy of the old files+db, and then went incrementally to 3.3.3 and then 4.3.3. My theory was that there were so many deep structural changes from pre-3.1.0 that it just couldn't make the jump in one big step.

Good luck.

I have a question related to all of this.  I have been working on the Events module, specifically fixing it so that the event notifications and event enrollments work.  In the process of doing this I decided to take the new App_Code directory out for a spin.  So I converted the Events module to this, and got it working, great.  But in the process of doing this, I had to modify the DNN core (speficially ProcessGroup.vb, and Reflection.vb) to use BuildManager.GetType instead of Type.GetType, because, as far as my understanding goes, when using the app_code directory, you *have* to use buildmanager, or the system won't know how to get the assembly, and since .NET changes this assembly name/location dynamically, you can't know at design time what the name is going to be, like you do when pre-compiling the site. 

My question is this: did I miss something in doing it this way?  If i'm right, and it must be done this way, using buildmanager in order to hook modules in using the app_code as their deployment method, then the DNN 4.3.5 release is *not* compatible with the app_code way of doing things, because its source still uses type.gettype.  Am I right about this or am I missing something about how things work here? 

Someone who knows about this stuff, please post here and shed some light on this?

Thanks!