Working on Chapter 11 - the part about implementing a custom profile to allow the user to select themes.

I've stripped everything out of the profile except the themes attribute.

    <profile enabled="true">
      <properties>
         <add name="Theme"/>
      </properties>
    </profile>

I should mention that I'm a newbie and have implemented MS Access providers - based on a lot of stuff I've pulled off MSDN2. - That said, they work - membership, roles, and now profiles.

However, I do have a weird issue - when I put in the section about the HttpModules >

    <httpModules>
      <add name="Page" type="Wrox.Web.GlobalEvents.ThemeModule" />
    </httpModules>

and added the theme.vb module to the App_Code directory, I started getting the following error. . .

Error 4 Type 'ProfileCommon' is not defined. c:\inetpub\wwwroot\Basic_Provider\App_Code\VB\Them eModule.vb 33 26 http://localhost/Basic_Provider/

(BTW, I like the VS2005 copy error codes feature - I would have liked it better if I could have just selected any of the relevant text by clicking and dragging though)

I did lots of research on the web and tried all the fixes I could find - stopping and starting the webserver, killing the aspnet process, making a change to the web.config file, saving, loading a page, changing config back, saving, new method (instead of directcast - CType(ProfileBase.Create("ProfileTestVB", True), ProfileCommon),
essentially everything I could find. Finally, I dumped my config file, started with the Wrox application config file, dumped the parts like the shopping cart, the system.net, etc. that I wasn't using and, the error disappeared. Of course, the app didn't work, so I started adding back all of the stuff that I'd added.

Anyway, it's late, I'm rambling, the part of the config file that caused the error to occur was the compilation section. Based on another Wrox book - Professional ASP.Net2 (pg 79-80) and all the rah-rah about how language independent .NET 2 was, I added the following section to my web.config file:

      <compilation debug="true" explicit="true">
          <codeSubDirectories>
              <add directoryName="VB"/>
              <add directoryName ="CS"/>
          </codeSubDirectories>
      </compilation>

My question is, what gives? I did this because I'm not great in C# and there were some membership pages that were written in C# that I wanted to incorporate in the site. I was going to re-work them because they were ugly, but the basic functionality was there. I thought I’d cut short the development time. They worked fine beside my vb providers until I added your ThemeModule.vb. How come everything broke down?

Thanks for your time,

Joe.

Follow up:

Just to test, I decided to add back the subdirectories and just moved the theme.vb module into the main app_code directory. Re-built and no errors. It made no difference if I moved the rest of the VB providers I'm using either into the "VB" directory or outside of it.

OleDbAccessRoleProvider.vb
OleDbAccessProfileProvider.vb
OleDbAccessMembershipProvider.vb

For instance, the file structure could be:
App_code
  ThemeModule.vb
    CS <dir>
        List of class files
    VB <dir>
        OleDbAccessRoleProvider.vb
        OleDbAccessProfileProvider.vb
        OleDbAccessMembershipProvider.vb

or

App_code
  ThemeModule.vb
  OleDbAccessRoleProvider.vb
  OleDbAccessProfileProvider.vb
  OleDbAccessMembershipProvider.vb
    CS <dir>
        List of class files
    VB <dir>

It's just odd. It's seems as if as long as the compiler doesn't have to deal with mixed source files in App_Code, it's happy - it doesn't care how you manage them, provided you do. The subdirectories aren't sole locations where files of a particular language can appear, just additional locations where they can be stored separate from any other language files. I guess you could use the subdirectories to store class files relating to a particular part of your web application if you had multiple files to store

ProvidersDir <dir>
        OleDbAccessRoleProvider.vb
        OleDbAccessProfileProvider.vb
        OleDbAccessMembershipProvider.vb
BusinessLogic < dir>
Etc.

The part I don’t understand is why the code referencing ProfileCommon code

>> Dim pb As ProfileCommon = DirectCast(HttpContext.Current.Profile, ProfileCommon)

must be at the top level of the App_Code directory for this to work.

Joe.

I couldn't get the themes module to work on anonymous users. I tried adding a default value to the database and to the properties setup in the web.config. I finally got it to work by adding this line of code in the module itself:

                Dim pb As ProfileCommon = DirectCast(HttpContext.Current.Profile, ProfileCommon)
             * If pb.Theme = Nothing Then pb.Theme = "BasicAlpha"
                p.Theme = pb.Theme

BasicAlpha was just what I named the default skin I wanted to use in the site.

Was there another way, some setting that I missed that could have handled this?

Thanks,

Joe.

RIGHT FRUGGING UNBELIEVABLY FRUSTRATING BANG THE FRUGGING DESK DEATH TO MICROSOFT DEVELOPER IDIOTS .. on .. I've been going abso *crazy* trying to get profiles working on various sites we support .. been WEEKS of ripping out hair and cursing the existence of ASP.NET and the moronics who wrote it and continue to blather its saving graces - CRAP. And yes all my code is in neat little sub-folders in App_Code .. WHODA THUNK Microsoft India could be so stupid as to write code that just gracefully ignores - no errors, nothing but dented keyboards and replace lcd monitors.

With all the bugs and limitations in: FormView, GridView, SqlDataSource,ObjectDataSource .. and now another .. App_Code .. I'm really starting to doubt the viability of using ASP.NET for anything other than the most simplistics of situations. .. Would be far better to just go back to hand coding.

bitter n'twisted by ms.
Riix