This project is read-only.

Extensions Manager is empty

Topics: ASP.NET 2.0, Business Logic Layer, Controls
Aug 24, 2008 at 10:25 AM
I upgraded to 1.4.5 the other day and have just realised that my Extension Manager isn't working properly. The page loads, but does not show any extensions in the admin screen, so I can't configure any of my extensions, let alone any of the ones I have added.
On a day-to-day basis this isn't really a problem as changes here are minimal, but nonetheless I would like to get this section working again. Can anyone suggest what might be wrong?
Aug 26, 2008 at 8:50 PM
Anyone got any thoughts about this?

If nothing else any ideas about why nothing is being loaded in the table?
As far as I can tell the database was upgraded successfully and I have copied all the files over from the new version 1.4.5
Aug 26, 2008 at 8:57 PM

Have you tried setting all ExtensionType bit values to "1" in be_datastoresettings?

Aug 26, 2008 at 9:28 PM
Extension Manager is populated by reflecting through each type in each assembly looking for the Extension attribute. It is triggered by the Application_Start event your Global.asax. You might want to double check your Global.asax, make sure that your void Application_Start(sender object, eventargs e) method is there and matches what is in the BE.Net Web App's Global.asax.
Aug 26, 2008 at 10:03 PM
That's a good point, Joe, and thanks for mentioning it.  I remember that when I was having a similar issue with 1.45, but my Global.asax was sitting pretty while my be_datastoresettings.ExtensionType bits at "0" were the culprit.

Aug 27, 2008 at 7:52 AM
Hi Dave and Joe
Thanks for your advice. I have copied Global.asax over again and set all the ExtensionType bits to 1 and that has fixed my problem.
I now have my extensions back.

Thanks again.

Oct 19, 2008 at 5:03 PM
Hmm, I have a blog which runs fine under test (IIS7) with the standard extensions plus a "thumbnailer" one I found on the net.

But if I put that precise same set of extensions on the live version of that site (IIS6), bang, the extensions list becomes empty as above. it's not crashing on load, or at least I see no crash dump and I've checked that debug's switched on. I've not dicked around with the global file.

So I think I need to chase down this ExtensionType thing, for reasons I can't imagine. But I can't find it anywhere... would anyone mind enlightening me: where do I find the bits I need to set to "1". The only good news is that if I remove the extension I just added it all comes back again. But there's nothing wrong with that extension according to my test machine. Both are latest versions of everything, 3.5, all that...
Oct 20, 2008 at 12:53 PM
I simplified my problem down by cloning one of the shipped classes and stripping it down to do nothing:
[Extension("Test", "0.0", "Phil")]
public class TestFred
    static TestFred()
Of course that runs fine on my local IIS7 test machine. On my hosted IIS6 tarket machine it kills the extension manager thing: it seems to stop when it hits the new extension, wherever that is in the list of extension. Precisely where extensions (I have the standard set shipped with BE) stop being listed seems to vary from install to install. The second effect of my little nasty class above is that it appears to stop some or all of the other extensions actually running. On the IIS6 machine only of course.

Both of these are BE 1.4.5 (latest release), 3.5, latest everything. The IIS6 one is hosted, but I set write permissions on App_Data and all that, and it works fine as a blog other than in this respect. Installing "TestFred.cs" bounces the IIS6 machine but not it seems the IIS7 one; I don't see why that would be, or what to deduce from it.

I checked /App_Data/datastore/extensions and nothing's bring written with the name TestFred.xml, which seems odd as the other things are all there. If I manually copy the TestFred.xml file across from my test machine that doesn't fix anythuing.

I think I really need to understand what this stuff is trying to do, in order to deduce what's wrong with my IIS6 system. I downloaded the source but it's kind of not obvious what everything's doing there; is there any separate documentation available to help me with this? How about debugging or these things; at the moment they're quietly croaking in the background somewhere - is there an error log or something so I can see what's failing to do what?

I'm sure there's something wrong, or something I need to tweak, in that IIS6 environment as I have no trouble on IIS7. In both cases BE is similarly installed, in a subdirectory and as an application, a configuration I have running on a number of other sites. There's definitely read/ write access to App_Data as of course I can save xml posts, images, and all that stuff.

Has anyone had this kind of problem and can you help me find a way through it? It's kind of frustrating as I have these nifty extensions on my IIS7 machine, but I can't put them live until I can figure out what's up with this.

Oct 20, 2008 at 4:22 PM
Well there's a strange thing. I thought as above that manually copying the extension.xml data file across from test to live server didn't work, but I tried it again in desperation... bounced the application... and now it works. So there's something stopping the extension infrastructure from creating those xml files in that
~/BlogEngine.NET/App_Data/datastore/extensions folder. Obviously I have all the permissions set to the tree App_Data.

Harumph, well at least it works now. So here's the work-around for anyone suffering from similar problems.... get it to work on a test machine, then copy both the extension CS file and also the corresponding XML file. Then it seems stable, for now at least.
May 19, 2009 at 12:15 AM
Edited May 19, 2009 at 12:16 AM

I did not encounter this problem with 1.4.5, but after upgrading to 1.5 my extensions disappeared.  I tried setting all ExtensionType bit values to "1" in be_datastoresettings, but that did not fix it.

Checked the global.asax, copied over a new one, etc.  Still not luck.  I am about ready to install workpress.