The first time xpcom loads mailnews.dll and msgcompose.dll we get a dialog that says 'Cant load appcores.dll' I am guessing I am getting this since I dont have your hack of copying the appcores.dll to the bin/ directory from the components directory. We got to fix this for dogfood guys.

*** Bug 3710 has been marked as a duplicate of this bug. ***

So, I get this dialog when I run apprunner without mail/news. So why is this bug assigned to a mail/news person? Perhaps it's something we've done, but I'm not sure it's our problem.

This is happening because your dlls (msgcompose.dll and mailnews.dll) are compiled with appcores.dll which is not in the bin/ directory. I have talked to alecf and danm extensively about this. There are two solutions we could take: 1. Make appcores.dll export another object that can do the initialization and then you dlls can do init using that object instead calling a static function 2. Move appcores.dll from bin/components/ to bin/ and change NS_SetupRegistry() to statically register all the CIDs in appcores.dll This will make it statically linked in and we wont get this message. (2) is BAD but if appcores are going away, I can live with it for a while. This is tip of iceberg. If we dont fix this, there will be two copies of appcores.dll (one linked in and another loaded by xpcom) used by two different modules; I cant even begin to think how many things might go wrong like this...

So it's a problem with appcores? Or our useage of it? I'm not arguing, just trying to understand...I agree this is a serious problem - we have other instances of this problem, if you'll pardon the pun, and it causes awful bugs.

dp, I thought we talked about this on Friday and you were going to talk to the xpfe guys about moving appcores.dll back into bin instead of components? I'm not sure why this bug is assigned to alec? I thought we were doing option #2. In any case, I fail to see how mailnews can solve the bug. XPFE requires us to call NS_InitBaseAppcoreClass if you are a pluggable app core. In order to build you need to link with appcores.dll to pick up this function. Either appcores moves to bin or xpfe comes up with an XPCOM way of getting NS_InitBaseAppCoreClass called that doesn't require the mail app core to have to link with it. Alec I hope you don't mind, but I'm going to temporarily assign this to danm since dp put you on the cc list (sorry dan =))in the hopes that you have an idea on how you'd like to solve this problem. Let me or alecf know if you want more details about the mail news app core.

Sorry, I was out of town and missed this discussion... I concur that #2 is the better near-term solution (for dogfood) and bad long term (of course) Also, I looked into this and it looks like all of the appcores except RDF are being initialized in NS_SetupRegistry_1 anyway.

Dan shall we do the moving of appcores.dll to bin directory. If we do, then let us make sure we bump the registry version number in xpcom/src/nsComponentManager.h so that the registry of users will be cleared out and recreated. I can do that if you want me to.

reassigning to rods as p2 for m3

correcting Product from MailNews to Browser and changing component to XPCom Registry since this bug is not unique to MailNews. Clearing myself as QA Contact.

I see this bug shutting too much. I can fix completely. Let me know if you want me to. (assign it to me).

Please fix this for M3, since the Appcore functionality will soon all become services, the short term solution is probably best.

Fixed.

*** Bug 3768 has been marked as a duplicate of this bug. ***

setting myself as QA contact

I have not had any dialogs displayed using the 3/17 builds, it appears that this problem has been fixed.