strange error on dmx module page where i have the main module added.\

i have added other modules since installing this module. 
OPEN DNN SEARCH
DNN ARTICLES 8.0
Advanced Articles 4.2.9 from InvenManager.com

should i just reinstall yours and hope for the best?

Error loading Bring2mind/DMX/ViewCollection.ascx
DotNetNuke.Services.Exceptions.ModuleLoadException: Type 'ComponentArt.Web.UI.CallBack' does not have a public property named 'ClientEvents'. ---> System.Web.HttpParseException: Type 'ComponentArt.Web.UI.CallBack' does not have a public property named 'ClientEvents'. ---> System.Web.HttpParseException: Type 'ComponentArt.Web.UI.CallBack' does not have a public property named 'ClientEvents'. ---> System.Web.HttpException: Type 'ComponentArt.Web.UI.CallBack' does not have a public property named 'ClientEvents'. at System.Web.UI.ControlBuilder.GetChildPropertyBuilder(String tagName, IDictionary attribs, Type& childType, TemplateParser templateParser, Boolean defaultProperty) at System.Web.UI.ControlBuilder.CreateChildBuilder(String filter, String tagName, IDictionary attribs, TemplateParser parser, ControlBuilder parentBuilder, String id, Int32 line, VirtualPath virtualPath, Type& childType, Boolean defaultProperty) at System.Web.UI.TemplateParser.ProcessBeginTag(Match match, String inputText) 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.ParseReader(StreamReader reader, VirtualPath virtualPath) 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.UI.TemplateParser.Parse(ICollection referencedAssemblies, VirtualPath virtualPath) 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.Compilation.BuildManager.GetVPathBuildResult(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 Bring2mind.DNN.Modules.DMX.Dispatch.ᜀ(Object A_0, EventArgs A_1) --- End of inner exception stack trace ---

i have emailed the owner of the other module i installed. the company is InvenManager.
their response was .....

Michael,

The Facility Booking module updates a component called "ComponentArt.Web.UI", so this might have some conflict with the version that used in DMX.

im confused on how you developers expect your modules to work on DNN installations where different companies selling modules update common components. you leave us in the business world just hoping the next module doesnt break our Intranet. i need to use both of your modules and need to know how to get around this problem.

if i reinstall your modules, will i just break the facility management module? i know DNN is shareware but you charge money for your module so that means you be taking precautions to not break the other 1000 modules available for sell for DNN.

how do i fix this problem?
can you send me a file to copy back to the portal to fix your module?
thanks

Hi, Michael. This unfortunately isn't an answer to your question, but wanted to let you know that Peter will be tough to reach until next week.
However, I would say that it's a simple reality in the world of 3rd party modules to make regression testing in a non-production environment a part of your routine. It's always a risk to deploy a new module to a production intranet without testing it out first. This will let you find any conflicts that might pop up without impacting your end users.

i understand the testing before implementing. i always do a site and db backup before adding new modules so i can do a complete restore if the new module corrupts the site. however, if 2 modules say they work with my version of DNN but they were written using 2 different versions of the same DLL component, then its a lie to say the module is compatible. There needs to be a disclaimer clearly marked that this module is poorly written and overlays common DLLs and may corrupt your installation. Cant the DLL just be renamed and used? cant it be put in a unique directory under the BIN folder. There has to be a better way to develop modules than just "I hope it works" method. Apparently 3rd party module developers should stay away from pre packaged DLLs because they will be overlayed.

i dont understand the concept of this "duhhhh, i hope my module dont break your site" programming practice, because i have been developing applications for 30 years.

Another fix to this problem is that you publish an upgrade your PA zip everytime the common component is upgraded. if a newer module overlays your installation files in the BIN folder, i simply go get the upgraded version of your module. this is the downside of taking shortcuts in development.

 Yep, no arguments from me that a developer shouldn't alter a core or shared DLL file without renaming.  I'd bet Peter could give you more insight, but it looks to me that it's the Invenmanager module that might be the offending one in this case.  It almost looks like they've tried to extend it a bit (with the "ClientEvents" property), but didn't bother to rename or separate it.  Now any other module that expects to see the "stock" component (like DMX) are throwing the error.  

I could be way off, but that's the hunch I get.  

Hi guys,

I'm back. The deal is that the problem here is actually two-fold. There is a versioning issue and a licensing issue. The former is solvable, the latter is not. Allow me to explain.

Versioning: ultimately 3rd party component developers are responsible for their code and normally they will make sure there is upward compatibility. The invenmanager module installed an older CA dll which broke DMX. Replacing it with the DMX one should make both modules work (according to standard .net practice and providing CA made sure it really is backward compatible). BUT ...


Licensing: CA requires you recompile their dll with a code in it to make sure you don't hand out a dll anyone can use for their own stuff. Fair enough. But if there are 2 modules using CA then obviously one will shoot into unlicensed mode as the magic key is no longer there. I have spent a fair amount of time on licensing myself and I think this is solvable. Only: we are a small market to companies like CA so they don't really see this as urgent. Until they solve this we're stuck.

So is there no solution? Well, yes there is: buy your own CA. If you have your own CA it will be licensed to work and it will make both modules light up (the licensing check is done inside the CA dll, not inside the DMX code). Until our market matures and is able to exert pressure on companies like CA this is the only way out. In my work in the DNN core team I have brought this forward but again the ball is really in the court of the component vendors.

Peter