Adam,
I may have missed something but there is no change in behavior based on the new DLL. Also, it seems to be the same version as the one in the install. Here is the trace information. The test I did was to put the new DLL in the bin directory, kill the IIS process, go to my website, log in, and then click on the file manager button at the top right.
|
An error has occurred. 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 --- |
|
|
|
|
Unhandled error loading module. DotNetNuke.Services.Exceptions.ModuleLoadException: D:\Dev\NMFTA\nmfta.dnn\Admin\Files\FileManager.ascx.vb(709): error BC30560: 'ZipEntry' is ambiguous in the namespace 'ICSharpCode.SharpZipLib.Zip'. ---> System.Web.HttpCompileException: D:\Dev\NMFTA\nmfta.dnn\Admin\Files\FileManager.ascx.vb(709): error BC30560: 'ZipEntry' is ambiguous in the namespace 'ICSharpCode.SharpZipLib.Zip'. 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 --- | |
Cheers,
Scott