Mamlin, I took a totally different approach but I have been having success as well.

Using a site created from a DNN Module Template as a guide I have been converting the source code files individually. I wanted to run the original Events module simultaneously with the converted version so I have been changing all the namespaces as I convert.

In my App_Code subfolder I have the following five files: SqlDataProvider.vb, DataProvider.vb, EventInfo.vb, EventController.vb and EventBase.vb.  I just corrected any errors that occurred. Most of my errors were caused by me changing the namespaces.

In my DesktopModules subfolder I have placed the ascx and ascx.vb files. In the top line of the ascx files the parameter "CodeBehind" gets replaced with "CodeFile". In the ascx.vb files you can comment out all the control references that show duplicate reference errors, these references are no longer needed with "CodeFile". I then went through and corrected the other errors. My system is not complaining about HTML tags being in caps but I do get an warning in all the asp controls that "resourcekey" is not a valid attribute. I haven't figured out how to correct that one yet. Any help would be appreciated.

If you want to modify the code in the custom web controls then you will also need to completely delete the assembly name parameter for those controls. More about the web controls later.

Beneath the DesktopModules subfolder in the App_LocalResources folder are the resx files. I haven't changed these at all. But I may need to modify them to remove my resourcekey errors.

Using the custom web control source files: With ASP 2.0 if you place the web control source files in the in the App_Code folder they will be automatically be compiled. That is why you don't need a assembly name when you register them. The problem is that the web controls are written in C# and ASP will lay an egg if you place C# files with the VB files. The workaround is to create a new subfolder under App_Code, let's call it "MyCSCode". Add the C# source to this folder. Now insert the following line(s) to your Web_Config file.

<compilation>
    <codeSubDirectories>
        <add directoryName="MyCSCode" />
    </codeSubDirectories>
</compilation>

MyCSCode will have its own assembly and eliminate the mixed language errors.

I have only done a quick check so far but everything seems to be OK.

My conversion of the Events source was primarily a learning tool for me. I have written some calendar applications in classic ASP and wanted to see if DNN could be used for some future projects. Since I plan on using VS 2005 porting the Events module allowed me to learn how it all works.

So far I like what I see. They handled a few things like recurring events differently then I usually do, but that's OK.

Right now I am trying to decide if I should add features by adding to existing code or by replacing the existing code.

For example most of my clients would need Categories and Locations to be Module specific instead of Portal specific. The easiest way to implement that would be to change the existing code. But now my code has forked from the DNN source. If the DNN Events team adds a cool feature it may be difficult for me to implement it.

The harder way would be to keep the existing source as is and create an add-on module for the new features. Or if everyone likes my features I could change the Events source then submit the code to the DNN Events team and hope it is incorporated.

The whole thing may be academic, any DNN site I create would need the ability to manage almost a hundred roles. That would be cumbersome with vanilla DNN. I am hoping to find a module out there that allows for easier management of many roles.

I would be happy to share my experiences. I have a classic ASP intranet that has been in operation and evolving over the last 7 years. The calendar application sees heavy usage and contains hundreds of thousands of records.

I mentioned recurring events in a previous post so let me start there. Originally I stored recurring events as single record as I believe the DNN Events module does. Even though it may seem counter-intuitive I increased performance by splitting and storing the recurring record as many single events. Here's why.

The event is entered once but viewed hundreds of times. The idea is to optimize the data for viewing at the expense of storing more data (more about data structure later). With a single recurring record you have to cast a wide net to make sure have all the data. To view a date the required statement "SELECT * FROM Events WHERE @EventDate BETWEEN EventDateBegin AND EventDateEnd" will return lots of unnecessary records. In addition the recurring records will need to be evaluated to see if they fall on that date.

If you split recurring events at the time of entry to view a date the statement becomes "SELECT * FROM Events WHERE @EventDate = EventDate". It grabs exactly records needed with no recurring evaluation needed.

I have used two different data structures for storing the split recurring events.
In the first one the Events table remains as is and a second "EventDates" table is added containing:

ModuleID
EventID
EventDate

If a recurring event occurs over ten days then ten entries are made into this table one for each day. Normal non-recurring event dates are also added into this table. All date searches are then done against this table.

My users were not happy with the above method because all recurring events were still tied to a single record. If you change one you change them all.  For example if they had a recurring record that states there will be a meeting the first Tuesday of every month for the next two years. They wanted to change JUST next months event to say "Cancelled".  

I accomplished this by adding a ParentEventID field to my Events table. When editing a recurring event a check box would ask them if they wanted to change just this date. If checked a new (non-recurring) event would be created and the original recurring EventID would be put in the ParentEventID field. Any changes to the original recurring event can now be propagated to the new event via the ParentEventID field.

For example: "DELETE FROM Events WHERE EventID = @EventID OR ParentEventID = @EventID"

Questions and Comments welcome.

Dan