I have been trying to create my own Events module from the core Events module 03.02.00. I named this module TME_Events.

I will eventually also create my own tables, stored procedures used by the Events module using the prefix "TME_" but for now I am only trying to focus on the module itself to see if it even compiles.

Here are things that I have done:

1. I copied the Events (source code) folder (from underneath DesktopModules) and pasted it in the same location (under DesktopModules). I renamed this folder: TME_Events.

2. In all the ASCX file, I have changed the Inherits="Dotnetnuke.Modules.Events.xxxx" to Inherits="TME.Modules.TME_Events.xxxx" (where xxxx is the name of the ASCX file without the .ascx extension)

3. In all the VB files, I changed Namespace Dotnetnuke.Modules.Events to Namespace TME.Modules.TME_Events and Dotnetnuke.Events to TME.TME_Events

4. Replaced file paths (such as ???/Events/???) to ???/TME_Events/???) in every file.

5. Renamed the .dnn file to DNN_TME_Events.dnn and replaced any instance of the word Events to TME_Events inside this file

6. Compiled the entire DNN solution!

7. Logged in as the host to my DNN website, went under Module Definition, clicked Add new module definition, selected the DNN_TME_Events.dnn module manifest and clicked the Install button.

8. When I try to add the module to the page by selecting TME_Events from the drop down containing all available modules, I get the following error:

Error: TME_Events is currently unavailable.
DotNetNuke.Services.Exceptions.ModuleLoadException: Could not load type 'TME.Modules.TME_Events.TME_Events'. ---> System.Web.HttpParseException: Could not load type 'TME.Modules.TME_Events.TME_Events'. ---> System.Exception: Could not load type 'TME.Modules.TME_Events.TME_Events'. ---> System.Exception: Could not load type 'TME.Modules.TME_Events.TME_Events'. ---> System.Web.HttpException: Could not load type 'TME.Modules.TME_Events.TME_Events'. at System.Web.UI.TemplateParser.GetType(String typeName, Boolean ignoreCase, Boolean throwOnError) at
System.Web.UI.TemplateParser.ProcessInheritsAttribute(String baseTypeName, String codeFileBaseTypeName, String src, Assembly assembly) at
System.Web.UI.TemplateParser.PostProcessMainDirectiveAttributes(IDictionary parseData) --- End of inner exception stack trace --- at
System.Web.UI.TemplateParser.ProcessException(Exception ex) at System.Web.UI.TemplateParser.PostProcessMainDirectiveAttributes(IDictionary parseData) at
System.Web.UI.TemplateParser.ProcessMainDirective(IDictionary mainDirective) at System.Web.UI.TemplateControlParser.ProcessMainDirective(IDictionary mainDirective) at System.Web.UI.TemplateParser.ProcessDirective(String directiveName, IDictionary directive) at
System.Web.UI.BaseTemplateParser.ProcessDirective(String directiveName, IDictionary directive) at System.Web.UI.TemplateControlParser.ProcessDirective(String directiveName, IDictionary directive) at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding) --- End of inner exception
stack trace --- at System.Web.UI.TemplateParser.ProcessException(Exception ex) at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding) at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding) --- End of inner exception stack trace --- at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding) at System.Web.UI.TemplateParser.ParseFile(String physicalPath, VirtualPath virtualPath) at System.Web.UI.TemplateParser.ParseInternal() at System.Web.UI.TemplateParser.Parse() at System.Web.Compilation.BaseTemplateBuildProvider.get_CodeCompilerType() at
System.Web.Compilation.BuildProvider.GetCompilerTypeFromBuildProvider(BuildProvider buildProvider) at
System.Web.Compilation.BuildProvidersCompiler.ProcessBuildProviders() at System.Web.Compilation.BuildProvidersCompiler.PerformBuild() at
System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath) at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.UI.TemplateControl.LoadControl(VirtualPath virtualPath) at System.Web.UI.TemplateControl.LoadControl(String virtualPath) at DotNetNuke.UI.Skins.Skin.InjectModule(Control objPane, ModuleInfo objModule, PortalSettings PortalSettings) --- End of inner exception stack trace ---


[If you are wondering, in the above error message the last TME_Events in 'TME.Modules.TME_Events.TME_Events' refers to the TME_Events.ascx]

It looks like the error might be caused by the TME_Events module DLLs not being created during compilation. [They cannot be found in the bin folder for the

DNN installation]. Why aren't they being created? Or is there a different reason for obtaining this error?

I know a lot of folks want to create their own version of this (and other modules).  However, many of these modules are very complex (and getting even more so).  The source provided for the modules is intended for use any way you want.  However, we're interested in why you want to create your own?  If you also post the reasons why, others may chime in and want the same features added...and there is a possiblity that you can contribute your code and expertise, instead of a one-off.  I am currently dealing w/aDNN User that has rolled their own now...they wanted to implement a 3rd party control (which we cannot).  Now that they've forked the build, they want to re-integrate into the latest events version...and cannot easily do so.

So....you're major issue is that DNN (and the modules) do not support transactional processing?  If this is the case, most of the web is stateless (transactions are stateful)...I would not think this is a good idea.  Additionally, it's been my experience that stateful, transactional development is often misused...often applications apply transactions when they are not needed and when stateless methods to handle the same issues which incur less of a performance hit and require less processing overhead.  I worked, early in my career, on the Mainframe, including using IDMS, a high performance, transactional database that required a couple of DBAs just to monitor and free locks for failing software...these were very closed systems!!!  Ask yourself:  "If I use Transactions...can I do commits across Database Platforms (SQL Server, Oracle, etc.) and development languages (.NET, Java)?"  The web, by definition, is a very open architecture...and is rapidly migrating toward disconnected Web Services (Service-Oriented Architecture - SOA).  Most of the Objects Classes, Properties, and Methods I know of in DNN are very extendable (and published via open source)...I for one, would hate to see DNN closed by implementing vendor-specific transactions.  But, you are welcome to use the DNN Code and Module Source Code any way you see fit...that's the beauty of Open Source Projects, like DotNetNuke...