After developing and packaging a number of DNN 4 modules in VS2005 using the dynamic compilation model, I thought I'd try the pre-compiled model as outlined by Shaun Walker.  Other than the hassle of picking through the precompiled/bin to find all the dlls with the correct hashcode appended names, all seemed to go well with the module installer placing all the pieces in the right folders, running the SQL script, registering the definitions and controls, etc.  However, when I attempted to place an instance of the new module on the test page, I received the following exception errors:

InnerException: D:\Clients\C2032\lakeregiontv.org\public_html\DesktopModules\WESNet\ModuleViewDefinitions.ascx(9): error BC30451: Name 'IsEditable' is not declared.
Message: DotNetNuke.Services.Exceptions.ModuleLoadException: D:\Clients\C2032\lakeregiontv.org\public_html\DesktopModules\WESNet\ModuleViewDefinitions.ascx(9): error BC30451: Name 'IsEditable' is not declared. ---> System.Web.HttpCompileException: D:\Clients\C2032\lakeregiontv.org\public_html\DesktopModules\WESNet\ModuleViewDefinitions.ascx(9): error BC30451: Name 'IsEditable' is not declared. at System.Web.Compilation.BuildManager.PostProcessFoundBuildResult(BuildResult result, Boolean keyFromVPP, VirtualPath virtualPath) at System.Web.Compilation.BuildManager.GetBuildResultFromCacheInternal(String cacheKey, Boolean keyFromVPP, VirtualPath virtualPath, Int64 hashCode) at System.Web.Compilation.BuildManager.GetVPathBuildResultFromCacheInternal(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 ---

InnerException: Object reference not set to an instance of an object.
Message: DotNetNuke.Services.Exceptions.ModuleLoadException: Object reference not set to an instance of an object. ---> System.NullReferenceException: Object reference not set to an instance of an object. at System.Web.UI.UserControl.get_Request() at DotNetNuke.Entities.Modules.PortalModuleBase.get_IsEditable() at DotNetNuke.UI.Containers.Title.CanEditModule() at DotNetNuke.UI.Containers.Title.Page_Load(Object sender, EventArgs e) --- End of inner exception stack trace ---

The problem stems from this common usage in the .ascx of the IsEditable property which the module control inherits from PortalModuleBase:

<ItemTemplate>
        <asp:HyperLink NavigateUrl='<%# EditURL("desktopmoduleid",DataBinder.Eval(Container.DataItem,"DesktopModuleId")) %>' Visible='<%# IsEditable %>' runat="server" ID="Hyperlink1">
               <asp:Image ImageUrl="~/images/edit.gif" AlternateText="Edit" Visible='<%# IsEditable %>' runat="server" ID="Hyperlink1Image" resourcekey="Edit"/>
       </asp:HyperLink>
</ItemTemplate>

Further investigation showed that none of the public properties of PortalModuleBase OR those defined in the code file accompanying the .ascx were visible in the .ascx.  The module works fine in VB2005 development and works fine when packaged and uploaded to the test site along with the code files accompanying each .ascx using the dynamic compilation model.

When I first received these exceptions, I though that it was because I had packaged the .ascx module control files from the DesktopModules/WESNet folder rather than the modified ones that were created in the precompiled/DesktopModules/WESNet folder that were created when I published the website, the difference being that in the @Control directive, the attribute Inherits="WESNet.DNN.Modules.ModuleViewDefinitions" has been replaced with Inherits="WESNet.DNN.Modules.ModuleViewDefinitions, App_Web_moduleviewdefinitions.ascx.585487ff".  The hash code correctly corresponds with that of the pre-compiled codefile which I also verified was correctly getting loaded into the test sites bin folder.

So, once more I settled on using the dynamic compilation model for packaging a DNN 4 module.  Has anyone gotten pre-compilation to work in cases where the .ascx module control references a property or method in the accompanying code file or the code file's base class?

I think that may be the root of the problem.  The controls that were causing the problem are part of a module which provides a base framework/administration for other modules I'm developing for the same site.  When I packaged (using the dynamic compilation model) one of the other modules which called upon this base framework and installed it on the test site, I immediately got dotnetnuke.dll version reference exceptions because the base module was compiled with a later build (on my development box) of dotnetnuke.dll than that on the test site.  Although both the development box and the test site had started with the same build of the DNN 4.00.02 core, I had apparently rebuilt the core library sometime during the development process.  When I restored the core library version to the match that of the test site, re-compiled my base module and re-installed it, all was well.

This brings up the question of how to avoid this in the future when pre-compiling a DNN 4 module.  Presumably, our development machines may often have later builds of the core (accidentally or intentionally) than the test or production sites. I had thought the days of .dll version h*ell were gone - guess not.

Just to bump this thread up and make people notice the problem, especially following the last discussions about Web Application projects.

I got the same error ('IsEditable is not declared') with the following environment:
a) Developing with the DNN 4.0.2 Starterkit (developing the module with WAP and compiling it with DotNetNuke.dll of Starterkit, version 4.0.2.41274)
b) Installing the package to a standard DNN 4.0.2 installation on a web host, DotNetNuke.dll version 4.0.2.31882.

So be aware of this DotNetNuke.dll version issue when developing WAP modules.

Wolfgang