Installing BlogEngine 1.3 in a /blog subdirectory. How?

Topics: ASP.NET 2.0, Controls
Feb 3, 2008 at 9:31 PM
I installed BlogEngine 1.2 into the www.mywebsite.com/blog directory and it has worked very well.
However, trying to upgrade to 1.3 has not worked. Has anyone been able to get BlogEngine 1.3 to work in an application subdirectory?

What I did:

1. Compiled BlogEngine 1.3
2. Updated config to use SQL & set up the blog settings etc.
3. Installed in / directory on IIS. It works fine. Groovy.
4. Create /blog directory and installed in /blog directory.
5. Set BlogEngie.VirtualPath to "~/blog/"
6. Made sure the /blog is configured as an application in IIS.

First problem:
6. "\blog\User controls\PostList.ascx(5): error CS0103: The name 'Resources' does not exist in the current context"... looks like there are resources unde xxx.com/blog/AppGlobalresources that could not be found. So, I added those resrources to /AppGlobalresources and then:
7. Then an error "Unknown server tag 'blog:PostCalendar'".

Anyway, the short of it is that I don't think BlogEngine 1.3 works in subdirectories. If anyone has been able to get this to work in a real world environment, please could you let us know how you did it. I have seen other comments here but they all seem to be from people who have not actually installed 1.3 in a subdir.

Thanks!!
Coordinator
Feb 3, 2008 at 11:54 PM
BlogEngine.NET 1.3 works fine in a subdirectory. I believe that is how most people use it actually.

I think you're making the process harder than it is meant to be. Check out the screencast on installation I made at:

http://www.nyveldt.com/blog/post/BlogEngineNET-13-Installation-Screencast.aspx
Feb 4, 2008 at 2:27 AM
Thanks, I followed your screencast exactly and it still fails with "Unknown server tag 'blog:PostCalendar'".
Feb 12, 2008 at 10:07 PM
i know this may not be very helpful, but anyhoo: i did like the video and seems to work just great for me.

one thing to notice though: the video does not do the #5 in your list.

hope this helps,

ciao,
Adrian
Feb 12, 2008 at 10:08 PM
Edited Feb 12, 2008 at 10:08 PM
copy
Mar 12, 2008 at 9:14 PM
For running in a sub application, step #5 should not be done. Just leave it as "~/" for a sub application.

For running in a sub directory (without having a separate IIS application), 1.3 does not work without changes to absolute paths. I was able to make the changes and they may be available in central source code soon.

If you would like to help test the changes, please visit http://be1.balcoding.com/ and poke around the default install that is set up there. Let me know if you find any problems with it.
Mar 14, 2008 at 2:37 AM
Hello,

I am getting the same problem that FlyTheBlueSky described as his "first problem". I have direct control over my web server, and I installed following the 1.3 version by following the instructions on the Wiki at http://www.dotnetblogengine.net/wiki/Default.aspx?Page=Installation&AspxAutoDetectCookieSupport=1#D_-_Fresh_installation_. I installed to a subfolder called "BlogEngineDotNet" that is set up as a .Net 2.0 application in IIS on Windows Server 2003.

After installing and navigating to the site, I get an error on Line 120 of TagCloud.cs that reads "CS0103: The name 'Resources' does not exist in the current context",

The code that it refers to is writer.Write("<p>" + Resources.labels.none + "</p>");

My App_GlobalResources folder looks like it has a bunch of resx files in it. How did FlyTheBlueSky correct this first problem?

One thing I should also mention here is that DotNetNuke is installed in my default web site (in which the BlogEngineDotNet application resides).

Thanks,
-racingcow
Mar 14, 2008 at 3:35 AM
Hey racingcow,

I took the files from Blogengine's /AppGlobalResources directory and put them in the server's root /AppGlobalResources directory. Even though I was not able to get BlogEngine 1.3 to work after that, perhaps you could also try it and report back here? I would appreciate that. Good luck.

Cheers.
Mar 15, 2008 at 5:10 PM
Edited Mar 15, 2008 at 8:20 PM
Brian,

I started poking around, trying to see what would be needed to run in in a subdirectory (not a "sub-application" - to be explicit), I wanted to see how much work would be needed (so I wouldn't have to wait for the next release to see your changes). I started looking at digitalID posts back in Nov to get familiar with the issue (http://www.codeplex.com/blogengine/Thread/View.aspx?ThreadId=18391). Getting the basic site online is fairly trivial, but there is work to be done on the themes.

One question I came across. themes/Standard/SidePanel.ascx references the admin menu user control
<%@ Register Src="~/admin/menu.ascx" TagName="menu" TagPrefix="uc1" %>

How do you change it to use Utils.RelativeWebRoot? (so you don't hardcode a path)

Are you changing other themes? Is there a concerted effort to do so?

I went to your test web site (http://be1.balcoding.com/), so far, everything works (can't think of much to test). Have you tried WLW? Make sure the API is working?

These are the steps I've done so far
  1. Clean install as a sub-application (followed the video/FlyTheBlueSky's list above w/o step 5). This was to make sure everything worked as it should.
  2. Configured it to use the SQL provider - I want to use SQL in the end, and digitalID also was using it, so I figured this was a better way to go.
  3. Created an empty web site, copied everything to a subdirectory (/blog)
  4. Moved /blog/Web.config, Web.sitemap, robots.txt, Global.asax, Bin, App_Code, App_Data, App_GlobalResources to the root (on a site with actual content, you'd have to combine these files/directories).
  5. Open Web.Config, set BlogEngine.VirtualPath to "~/blog/". Make sure to include the trailing '/'.
  6. Fixed menu links in themes/Standard/site.master (replaced ~/ with Utils.AbsoluteWebRoot and removed runtat=server)
  7. Fixed themes/Standard/SidePanel.ascx (used hardcoded path for Register mentioned above, also for OPML image - could just make it an img tag instead of asp:image)
  8. Fixed themes/Standard/PostView.ascx (added reference to core, changed RSS feed pic to use Utils.AbsoluteWebRoot )

The first 2 steps were mostly for me, to get familiar with BlogEngine and to see it working before making any changes...

I noticed that App_Data/extensions.xml has changed, even after I had setup the SQL Provider. It might be something that requires other changes (if you want to have all data stored in SQL)...

I look forward to the ASP.Net Themes compatibility changes (http://www.codeplex.com/blogengine/WorkItem/View.aspx?WorkItemId=4569 and http://www.codeplex.com/blogengine/WorkItem/View.aspx?WorkItemId=5657) planned for 1.4, which will probalby make a subdirectory installation more useful when integrating with an exisitng web site.

(edit to add change to BlogEngine.VirtualPath)
Mar 15, 2008 at 10:33 PM
Edited Mar 27, 2008 at 3:44 PM
Subversion repository where I made these updates.

http://svn.balhosting.com:8080/opensource/blogengine/branches/subdirectory

Currently, updating even the latest code to work in a subdirectory is a multi-step process.

These are the fixes needed, based on version 1.3.0.26 (Change Set 10566). These should be able to be applied to the trunk code without any negative effects.

#1: Fix absolute path references so the site can compile in a subdirectory.

These files have absolute references to their code files that need updated to relative references.

/admin/Extension Manager/Settings.ascx
/admin/Extension Manager/Editor.ascx
/admin/Extension Manager/Extensions.ascx

Several of the admin pages do not have relative references to the admin1.master file. These files are in the "admin/Pages" directory and the "admin/Extension Manager" directory. Search and replace of {~/admin/admin1.master} with {../admin1.master} on the entire project to fix these.

In the Themes and in the Widget Administration, there are references to register "~/admin/menu.ascx". Search and replace of {~/admin/menu.ascx} with {../../admin/menu.ascx} to fix these.

In the themes/TheGreenHouse/site.master there is an absolute reference to register {~/themes/thegreenhouse/sidepanels.aspx} that needs updated to be just {sidepanels.aspx}.

In the widgets/Tag cloud/edit.ascx there is an absolute reference to {~/widgets/Tag cloud/widget.ascx} that needs updated to be just {widget.ascx}.

After making these fixes, the site will compile in a subdirectory.

#2: Fix absolute references to ~/pics:

  • Fix references to "~/pics/blogengine.ico"
    • Update admin\admin1.master line 9 to relative link "../pics/blogengine.ico" manually.
    • All other references are in themes\themename\something.as?x, so can be replaced with search and replace of {~/pics/blogengine.ico} with {../../pics/blogengine.ico}.

  • Fix reference to <%=VirtualPathUtility.ToAbsolute("~/pics/")%>. Search and replace {<%=VirtualPathUtility.ToAbsolute("~/pics/")%>} with {<%=BlogEngine.Core.Utils.RelativeWebRoot%>pics/}


  • Fix reference to {src="~/pics/} by replacing {src="~/pics/} with {src="../../pics/}

#3: Fix absolute links to site pages with relative links.

1. In the PostView.aspx files, where VirtualPathUtility.ToAbsolute("~/") is used to create the "author" link, BlogEngine.Core.Utils.RelativeWebRoot can be used to replace it.
Search and replace {<%=VirtualPathUtility.ToAbsolute("~/")} with {<%=BlogEngine.Core.Utils.RelativeWebRoot}

2. Links to ~/archive.aspx are all in themes directories, and all in server side controls, so it can be search and replace {~/archive.aspx} with {../../archive.aspx}.

3. Links to ~/contact.aspx are all in themes directories, and all in server side controls, so it can be search and replace {~/contact.aspx} with {../../contact.aspx}.

4. Links to ~/default.aspx are all in themes directories, and all in server side controls, so it can be search and replace {~/default.aspx} with {../../default.aspx}.

5. Links with {href="~/"} are all in the themes directories, and all in server side controls, so it can be search and replace {href="~/"} with {href="../../default.aspx"}.

6. There were some absolute links in themes/indigo/postview.ascx to files in the themes/indigo/img directory. Update the links to be to {img/*} instead.

#4: Fix reference to themes directory

  • In the User Controls/CommentView.asx.cs file, the themes directory is referenced using "~/themes". It needs to be updated to use Utils.RelativeWebRoot.

#5: Fix absolute paths in BlogEngine.Core

The paths effected the monster showing up, the pic of the flag next to a comment, the link to the comment, and URLRewrite reewriting anything in the whole site instead of just the subdirectory.

The following files need to be updated to use Utils.RelativeWebRoot instead of "~/":
Web/Controls/CommentViewBase.cs
Web/Controls/PageSiteMap.cs
Web/Controls/PostViewBase.cs
Web/HttpHandlers/MonsterHandler.cs
Web/HttpModules/UrlRewrite.cs
Mar 16, 2008 at 1:07 AM
Edited Mar 16, 2008 at 1:17 AM

I didn't mean to make you post a detailed account of your changes. Thank you for your effort, it's educational.

I started doing a global search for "~/, and I could see that it was going to be quite a bit more work than I had hoped. You have taken a comprehensive approach (I was reticent to do global search/replace). Now it's a matter for developers and theme designers to follow your lead.

I didn't think about using relative paths. That happens when you switch languages over and over, you forget the little big things that make a huge difference. This is a fairly mature project, so the directory structure is more or less set: it isn't likely future efforts will need to change the relative paths.

I did some more testing on your test site. Posted using WLW, poked around a bit more. I was thinking to try other themes, and maybe setup a SMTP server, but that might be taking it too far and it might interfere with other testers...

I can follow your instructions, or it might be easier for everybody if you upload your current code/patch somewhere.

Thank you,
Gabriel

An afterthought (to put it somewhere). There probably will have to be some documentation written on how to set it up in a subdirectory (I know, not volunteering yet, maybe when 1.4 comes out). This documentation should mention that Web.Config file might need to be modified beyond the VirtualPath setting (for example, the login.aspx page location for forms authentication, and the users and roles settings – if you want to use BlogEngine’s implementation).
Mar 26, 2008 at 4:04 AM
I have my website set up with discountasp.net. My wife and I are leaving for our honeymoon in a couple months and we wanted to journal our travels through a blog so that everyone back home could keep in touch with us. I have been trying, unsuccessfully to install blogengine.net 1.3 for the past couple days. I followed the screencast and it still doesn't work for me, however I get a different end result than the others. Here is my best attempt to show you the errors.

www.joshphilpott.com - /blogengine.net/

To Parent Directory

Tuesday, March 25, 2008 4:36 PM <dir> BlogEngine.NET 1.3 shows up on the screen. If I click on the directory it shows I get this...

Server Error in '/blogengine.net' Application.
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".

<!-- Web.Config Configuration File -->

<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>


Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's <customErrors> configuration tag to point to a custom error page URL.

<!-- Web.Config Configuration File -->

<configuration>
<system.web>
<customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/>
</system.web>
</configuration>


So I have no idea what I'm doing wrong, I'm certainly not very good at any of this! Just thought I'd post my experience and hope someone could help!
Mar 26, 2008 at 1:44 PM
Hi,

I've been tinkering with installing BlogEngine in a folder beneath an existing DotNetNuke installation and have been studying this message thread, trying things out and failing for a while. The principal issue I've been having is with Resources causing the compilation to fail. Messages like 'The name 'Resources' does not exist in the current context' have been frustrating me!

I've managed to get it to work, but have had to break it again if I want my DNN software to carry on working and so I thought I'd share what I've found out in the hope that it helps someone else and that between us we can find a solution.

I put the BlogEngine code in a folder of its own, then created a virtual directory called blog directly beneath the root of my web site (so it is accessed using www.mywebsite.com/blog) and created the Application in IIS and set it to dotNet 2.0. Then trying to access the url sees Resource compliation issues. Given that I have discovered that if I then rename the web.config file in the ROOT folder, i.e. my DotNetNuke web.config file, then BlogEngine starts to work, or appears to do so - I have pages ready for me to use. Of course, to get DNN working I have to put the root web.config file back in place and this causes BlogEngine to stop working again.

So... I'm assuming that there is someway to modify BlogEngine's web.config file so that it overcomes the affect of my root web.config file but I haven't had much success yet. Can anyone provide any guidance which will help find a resolution?

Thanks :o)

P.S. jphilpott - change your web.config file so that the 'customErrors' setting is 'Off' and try accessing your site again, then you can find out what is going wrong rather than seeing the 'something happened but I'm not telling you what' message
Mar 26, 2008 at 2:42 PM
Elliveny,

Try this code in your root web.config (DotNetNuke)

<location path="." inheritInChildApplications="false">
   <system.web>
   ...
   </system.web>
</location>

-Mike
Apr 2, 2008 at 1:17 PM
I noticed that Brian's changes haven't been put in the latest change set, and I figured I could try and maybe help a little. I went through Brian's changelog and replayed it on top of change set 10566 (should work with newer change sets) and then used WinMerge to compare both versions. The idea was to try and provide confirmation to Brian's documentation, and to try and help anybody who is trying to get this working,

Distilling down Brian's changes:

  1. Fix absolute path references so the site can compile in a subdirectory.
    1. Global Replace CodeFile="~/admin/Extension Manager/ with CodeFile=" (3 occurrences) - Fixes full path references in codefile in Extension Manager controls.
    2. Global replace ~/admin/admin1.master with ../admin1.master (11 occurrences)
    3. Global replace ~/admin/menu.ascx with ../../admin/menu.ascx (11 occurrences)
    4. Global Replace ~/themes/thegreenhouse/SidePanel.ascx with SidePanel.ascx (1 occurrence)
    5. Global Replace ~/widgets/Tag cloud/widget.ascx with widget.ascx (1 occurrence)
  2. Fix absolute references to ~/pics:
    1. In line 9 of admin\admin1.master change "~/pics/blogengine.ico" to "../pics/blogengine.ico"
    2. Global Replace ~/pics/blogengine.ico with ../../pics/blogengine.ico (10 occurrences)
    3. Global Replace <%=VirtualPathUtility.ToAbsolute("~/pics/")%> with <%=BlogEngine.Core.Utils.RelativeWebRoot%>pics/ (2 occurrences)
    4. Global Replace ImageUrl="~/pics with ImageUrl="../../pics (7 occurrences)
    5. Global Replace src="~/pics/ with src="../../pics/ (1 occurrences)
  3. Fix absolute links to site pages with relative links.
    1. Global Replace <%=VirtualPathUtility.ToAbsolute("~/") with <%=BlogEngine.Core.Utils.RelativeWebRoot (10 occurrences)
    2. Global Replace ~/archive.aspx with ../../archive.aspx (9 occurrences)
    3. Global Replace ~/contact.aspx with ../../contact.aspx (8 occurrences)
    4. Global Replace ~/default.aspx with ../../default.aspx (5 occurrences)
    5. Global Replace href="~/" with href="../../default.aspx" (9 occurrences)
    6. Global Replace ~/themes/indigo/img/ with img/ (3 occurrences)
  4. Fix reference to themes directory
    1. Global Replace "~/themes/" with Utils.RelativeWebRoot + "themes/" (1 occurrences)
  5. Fix absolute paths in BlogEngine.Core
    1. Global Replace Server.MapPath("~/pics/ with Server.MapPath(Utils.RelativeWebRoot + "pics/ (1 occurrences)
    2. Global Replace SiteMapNode(this, Guid.Empty.ToString(), "~/", "Home") with SiteMapNode(this, Guid.Empty.ToString(), Utils.RelativeWebRoot, "Home") (1 occurrences)
    3. Global Replace Response.Redirect("~/error404.aspx" with Response.Redirect(Utils.RelativeWebRoot + "error404.aspx" (1 occurrences)
    4. Global Replace VirtualPathUtility.ToAbsolute("~/category/") with VirtualPathUtility.ToAbsolute(Utils.RelativeWebRoot + "category/") (1 occurrences)
    5. Global Replace const string PARTS_PATH = "~/pics with static string PARTS_PATH = Utils.RelativeWebRoot + "pics (1 occurrences)
    6. Global Replace if (url.Contains("/ with if (url.Contains(Utils.RelativeWebRoot.ToUpperInvariant() + " (6 occurrences)
    7. Global Replace Server.MapPath(Utils.RelativeWebRoot + "App_GlobalResources/" with Server.MapPath("~/App_GlobalResources/BlogEngine/" (1 occurrences)
  6. Additional change(s)
    1. Move contents of App_GlobalResources, App_Code & App_Data to a BlogEngine subdirectory under each directory (App_GlobalResources\BlogEngine, App_Code\BlogEngine & App_Data\BlogEngine).
    2. In a subdirectory installation, you put all files in the subdirectory, and move/merge Web.config, Web.sitemap, robots.txt, Global.asax, Bin, App_GlobalResources, App_Code & App_Data to the root of the application and configure your web.config accordingly.

Changes that might need further review
  1. Change settings defaults in XML and SQL script to use ~/App_Data/BlogEngine as the default data location
  2. How to deal with application paths in Web.sitemap? Brian hardcoded his test path, but that wouldn't be acceptable in the final product. What are the implications to recode admin_menu.BindMenu()? Any point in using SecuritySiteMap? Maybe move to a separate XML file under the admin folder -with relative paths- and configure provider accordingly?
  3. Moved InstallUtil.CheckInstallation(); out of the try block in global.asax. Any reason for this, Brian, or just a leftover test?

Web.config considerations
  1. Obviously, you have to set BlogEngine.VirtualPath (and it has to be a subdirectory, not a sub-application)
  2. Change default value for StorageLocation to ~/App_Data/BlogEngine
  3. Change loginUrl (from ~/login.aspx to ~/<your value for BlogEngine.VirtualPath>/login.aspx)
  4. Change error 404 redirect to redirect="~/<your value for BlogEngine.VirtualPath>/error404.aspx"

Thanks,
Gabriel
Apr 24, 2008 at 3:22 AM
Edited Apr 24, 2008 at 3:26 AM
Server Error in '/Blog' Application.
--------------------------------------------------------------------------------

Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".


<!-- Web.Config Configuration File -->

<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>


Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's <customErrors> configuration tag to point to a custom error page URL.


<!-- Web.Config Configuration File -->

<configuration>
<system.web>
<customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/>
</system.web>
</configuration>

Apr 24, 2008 at 3:24 AM
I get the exact error jphilpott is getting trying to install BE 1.3.1.0 in DiscountASP.NET.

I have made sure, I have created a sub folder and marked it as an application using the ocntrol panel and provided write access to "anonymous" user the BE subfolder. Please help
Apr 24, 2008 at 4:10 PM

aksheik wrote:
I get the exact error jphilpott is getting trying to install BE 1.3.1.0 in DiscountASP.NET.

I have made sure, I have created a sub folder and marked it as an application using the ocntrol panel and provided write access to "anonymous" user the BE subfolder. Please help


As far as I know, BE 1.3.1.0 does not work in a virtual directory either.
Apr 25, 2008 at 3:40 PM


FlyTheBlueSky wrote:

aksheik wrote:
I get the exact error jphilpott is getting trying to install BE 1.3.1.0 in DiscountASP.NET.

I have made sure, I have created a sub folder and marked it as an application using the ocntrol panel and provided write access to "anonymous" user the BE subfolder. Please help


As far as I know, BE 1.3.1.0 does not work in a virtual directory either.


BE 1.3 does work in a virtual directory, I've setup for my own blog in a subdirectory with the "Set Application Root" option and it works.
Apr 25, 2008 at 8:16 PM

BE 1.3 does work in a virtual directory, I've setup for my own blog in a subdirectory with the "Set Application Root" option and it works.


Do you have this set up in an actual production environment? It works fine in the development server environment.
I was able to get BE 1.2 to work in a virtual app directory in a shared hosting environment with some minor changes (coincidentally, I also use DiscountASP.net as some of the other posters have mentioned).

But there are definitely problems with BE 1.3 in a virtual app dir, regardless whether it works for you.
Apr 25, 2008 at 9:15 PM
Edited Apr 26, 2008 at 2:43 AM
It's been well established that there are many portions of code in BE 1.3 that don't use the value in BlogEngine.VirtualPath and that need changes (see earlier in the thread). And a virtual folder or subdirectory is not to be confused with a "sub"-application (which I presume is what "Set Application Root" does in miller's hosting environment - is it a Control Panel option in DiscountASP.NET?).

I just uploaded a patch for codeset 10974 (http://www.codeplex.com/blogengine/SourceControl/PatchList.aspx) which includes BrianLakstins's changes and a few more. I created the patch using a couple of sed based scripts, so it is easier to re-apply the sub-directory changes in future codesets. If 1.4 doesn't include the changes, I should be able to generate a patch for it when it's released - or if you are a developer that is going to integrate the changes, contact me and I might be able to help you with these scripts. If there is interest for it (post here), I could also generate a patch for the 1.3.1.0 version released last week (which is a branch less advanced than codeset 10974, which is a bit above 1.3.0.29).

After you apply the patch, you have to perform these changes (repeated from above)
  1. Move contents of App_GlobalResources, App_Code & App_Data to a BlogEngine subdirectory under each directory (App_GlobalResources\BlogEngine, App_Code\BlogEngine & App_Data\BlogEngine).
  2. Move all files into the subdirectory you want to use except Web.config, Web.sitemap, robots.txt, Global.asax, Bin, App_GlobalResources, App_Code & App_Data. If you are going to run under a different application, you'd have to merge the files/folders.
  3. In Web.Config, set BlogEngine.VirtualPath (and it has to be a subdirectory, not a sub-application)
  4. In Web.Config, change loginUrl (from ~/login.aspx to ~/<your value for BlogEngine.VirtualPath>/login.aspx)
  5. In Web.Config, change error 404 redirect to redirect="~/<your value for BlogEngine.VirtualPath>/error404.aspx"
  6. If you're copying an existing settings.xml, change value for StorageLocation to ~/App_Data/BlogEngine/

The patch includes updated versions for 54 files, ~5% of BE total files...

aksheik, you'd have to start by following Elliveny suggestion and turn CustomErrors off, so you get a meaninful error and someone can help you.

As a note for a developer that might want to incorporate the patch in the codebase. I don't really like the change I made to admin_menu.BindMenu(), but it seemed the best way for it to avoid harcoding paths in Web.sitemap. It's only 1 line, so it should be easy to change if you have a better way.
Apr 25, 2008 at 11:00 PM
Zootie, did you check out ModPack's source code?

Most of the changes are related to using the Blog.VirtualPath value
(actually the Utils.RelativeWebRoot method which uses the web.config setting)

Just uploaded the source of ModPack 1.3.0 (Service Release 1)

ModPack's Codeplex project site

Cheers Mike van Zandwijk
ModPack web site
Apr 26, 2008 at 2:12 AM
Indeed, I saw ModPack before and it seems like a good choice for users using a hosting provider like GoDaddy. In my case, also being a bit reticent to stray much from the main tree, my first impression was that it was too specific to GoDaddy and/or hosting in general (which isn't my target right now, maybe later), and being busy with other aspects of the project, I've been on a holding pattern waiting for 1.4 (and/or using the changes in this thread). ModPack is something I'm considering if 1.4 doesn't include this branch and/or my requirements change...

I downloaded the source for ModPack 130sr1 and started playing with it (using the VS built-in web server). It seems I'm missing something since I'm getting broken paths out of the box and also when I try and set the BlogEngine.VirtualPath to anything other than ~/ (or /Web - the default when I added it to a VS solution). I imagine this is something related to the way it deals with GoDaddy's specifics.

Looking in the source, trying to understand how ModPack works, I started counting occurrences of RelativeWebRoot
  • BE 1.3.1 has 80 occurrences in 38 files
  • ModPac 130sr1, 76 in 38 files (less?!)
  • Codeset 10974, 98 in 45 files
  • The patch I uploaded today, 124 in 57 files

Given that ModPack isn't using RelativeWebRoot as much as other branches, how does it work? I remember reading a thread where you advocated adding a PathFilter setting, is that it? And/or it uses an HttpHandler/HttpModule/rewriter?

Well, I'll continue working on the project, and studying the code...

Thanks
Apr 26, 2008 at 7:55 AM
After I set the the <customError> Off, I am getting the following error.

Please help.

Server Error in '/Blog' Application.
--------------------------------------------------------------------------------

Configuration Error
Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.

Parser Error Message: Theme 'Paper' cannot be found in the application or global theme directories.

Source Error:


Line 21:
Line 22: <!-- Use any of the following values for the styleSheetTheme attribute: "Granite", "Sand", "Paper".-->
Line 23: <pages styleSheetTheme="Paper" />
Line 24: </system.web>
Line 25: </configuration>


Source File: E:\web\<myWebDirectory>\htdocs\web.config Line: 23


--------------------------------------------------------------------------------
Version Information: Microsoft .NET Framework Version:2.0.50727.1433; ASP.NET Version:2.0.50727.1433

Thanks
Apr 26, 2008 at 4:43 PM
aksheik,

Obviously, the error indicates that it can't find a theme named "Paper". Since this isn't one of the themes in the default BE install and there isn't an "htdocs" folder, it seems something else is interacting (presumably, DiscountASP own infrastructure). BE 1.3.1.0 won't work in a subdirectory out of the box w/o making some changes, but it should work as a subapplication -which isn't the topic of this thread-, albeit it might need some changes for it to work with DiscountASP.

Since I'm not using DiscountASP, I can't help you much directly. Maybe MikevZ's updated ModPack might be of use (and/or his suggestion to set inheritInChildApplications="false" in the root Web.Config). Or maybe using codeset 10974 with my patch (in which case you have to unmark it as an application and set BlogEngine.VirtualPath in your root Web.Config).
Apr 26, 2008 at 7:40 PM


FlyTheBlueSky wrote:

BE 1.3 does work in a virtual directory, I've setup for my own blog in a subdirectory with the "Set Application Root" option and it works.


Do you have this set up in an actual production environment? It works fine in the development server environment.
I was able to get BE 1.2 to work in a virtual app directory in a shared hosting environment with some minor changes (coincidentally, I also use DiscountASP.net as some of the other posters have mentioned).

But there are definitely problems with BE 1.3 in a virtual app dir, regardless whether it works for you.



Yes I did sucessfully setup BE1.3 in a virtual directory, I'm using Godaddy, just getting the ugly path format that I don't like it, but really works without any error. I'm new to BE, BE1.3 is the first version I have used.
I just setup a sub virtual directory as application root in godaddy's control panel, copied the whole dir into a sub directory as the same name of the sub virtual directory, set write permission for App_Data, after these steps I got it into error but after searching some posts around this forum I modified the web.config to remove the trust level in it (because godaddy does not allow trust levels higher than medium), and the blog works fine.

You can see my blog here: http://miller.rotatingscrew.com , it's in the "miller" sub directory (It was English version but it's Chinese and Japanese version now)
Before setting up this one, I've also tried it in another virtual directory and had another url http://test.rotatingscrew.com pointed to the dir and it also worked fine, but the test had been removed.
Although the origional version worked well but I'm trying ModPack to solve the ugly path problem so it's not the origional version right now.
Apr 26, 2008 at 8:41 PM
Zootie, UtilsWebRoot is a funny thing ... in BE.NET & ModPack.

Why you probably see less UtilsWebRoot references in ModPack is because for some part of the code, I actually had to reverse the UtilsWebRoot to ~ instead of the expected other way around. And that's because the VirtualPath setting in ModPack removed the ~ in Web.config. I documented all the changes (with line numbers/source code file name), so if you want a draft copy - let me know.

For example:

In source: /Core/Web/Controls/BlogBasePage.cs
Line 3885166: replaced Utils.RelativeWebRoot with ~

Guess the only real GoDaddy specific in ModPack is just the SMTP server setting. Then again, you're right that most modifications I made to support shared hosting environments. Simply due to many security violations the official BE.NET code caused on plans like GoDaddy's.

Thanks for looking into the source code though. I'd love to learn more about your project and its goals. Any pointers?

Cheers Mike
May 5, 2008 at 9:53 PM
MikevZ,

Its been a while since you posted a reply and I'm sorry to say that I hadn't looked at this page in a while. The main reason I hadn't looked was because I was expecting an email notification when someone replied to my posting and I hadn't seen any mail about it. So I was quite surprised this weekend when a whole stack of email appeared in my inbox, with a good number about this posting - great! but not so great that it got delayed for so long.... hmmm!

So, MikevZ, this evening has been my first chance to become aware and try out your solution... and I'm pleased to say that it did the job nicely. I now have DNN and BlogEngine working happily side by side :oD Many thanks.

And now that they do work together nicely I'm thinking that my first posting to my BlogEngine site ought to be a discussion of this problem and solution...!

Thanks.


MikevZ wrote:
Elliveny,

Try this code in your root web.config (DotNetNuke)

<location path="." inheritInChildApplications="false">
   <system.web>
   ...
   </system.web>
</location>

-Mike

May 7, 2008 at 5:09 PM
Edited May 7, 2008 at 7:08 PM
I see this thread started a few months ago... any chance for a follow up? What's the latest news on running BE in a sub directory (not as application). My issue is I would like to reuse header and footer from my site which are contained in their own user controls and rely on the "~/" to resolve image/link paths to the root of the site, however with the blog running as a standalone application there are path issues as everything resolves to /blog/ when "~/" is used. I'm currently running v1.3.1.0

Looking at the past thread of messages it looks like there may be a newer version in repository... has these issues been addressed or should I just hack the existing one with above mentioned steps?

Thanks for your clarification,
-Paul
May 7, 2008 at 9:32 PM
Edited May 8, 2008 at 12:44 PM
Yes, there is a patch in the repository for a recent check-in. However, since it is based on code being developed, I can't say if it is a good idea to use it in a production environment (I'm myself undecided). I'll try and post a similar patch for 1.3.1.0 with the subdirectory changes in the next couple days. I already made the changes in my local system, I'm just testing it... Another alternative is to wait for 1.4 (presumably, by the end of May) - it will either support this or I should be able to generate a patch for it shortly after it's released...

Something that I should mention for discussion. There seem to be at least 2 intended usages for a subdirectory installation:
  1. Most posters want to get BE installed on a hosted environment w/o a cryptic subdirectory and/or subdomain - This is usually done more easily with MikevZ's ModPack.
  2. Others (like senixon, BrianLakstins, and myself) want to segregate BE files in order to combine it with other pages in our web site(s) - usually in cases when we have control of the web server. Being able to create custom pages outside of BE's framework while still being able to refer to BE's themes and controls (or to have BE use files outside its own w/o combining them - what senixon is trying to do).

MikevZ,

I imagine that's why RelativeWebRoot is being funny. For usage #1 (hosted), you're actually using RelativeWebRoot to hide the underlying application directory (by setting BlogEngine.VirtualPath to "/" or "/blog/") and you had to roll back and use ~/ in code at times in order to actually find the underlying files. In #2 (in the same app but segregated), the trend is to set BlogEngine.VirtualPath to "~/" or to "~/blog/" and use RelativeWebRoot everywhere and relative paths when needed.

This double usage/meaning might be mutually exclusive (ie, other settings might be needed so both are supported in the same codebase). I suspect that using relative paths might be enough to make a hosted version that uses RelativeWebRoot more consistenlty (so it is compatible in a same app segregated configuration), but I don't have a hosted environment to test, and I have a few things in my to-do before I can try and experiment with this. If I clear some time, I'll try and get a hosted account and see if I can merge both usages (merge ModPack with the dir changes -if you agree, Mike-), and then see if we can get all of the changes rolled into 1.4 or 1.5...

Furthermore, I would like to get some feedback from other users and developers, make sure I'm not going off on a tangent (or to check if this is already being addressed in 1.4)...
May 7, 2008 at 10:38 PM
Edited May 7, 2008 at 10:39 PM
zootie:: thank you for the follow up and summing it all up very nicely, I've only been following the project a couple of days here and have not dove into the source code too deep, but I'm definitely game for helping you test the patch for either 1.3.1/1.4. I'm setting up this site for my company and don't know if they can launch w/o the blog or wait until end or May/June for this fix. So anything I can do to contribute to the cause... just let me know.

BTW: I love the simplicity of the structure and the ease of creating themes via master pages, bravo! XML DB is a plus as well, thanks for all the great work.

-Paul
May 9, 2008 at 7:39 PM
Great write up and suggestions, Zootie!


Most posters want to get BE installed on a hosted environment w/o a cryptic subdirectory and/or subdomain - This is usually done more easily with MikevZ's ModPack.

Shared web hosting is indeed ModPack's main goal. With the latest SR1 release, I've updated 3 built-in themes with <%=Utils.RelativeWebRoot%> to better support subfolder installation as well. Thanks for your endorsement!

I imagine that's why RelativeWebRoot is being funny. For usage #1 (hosted), you're actually using RelativeWebRoot to hide the underlying application directory (by setting BlogEngine.VirtualPath to "/" or "/blog/") and you had to roll back and use ~/ in code at times in order to actually find the underlying files. In #2 (in the same app but segregated), the trend is to set BlogEngine.VirtualPath to "~/" or to "~/blog/" and use RelativeWebRoot everywhere and relative paths when needed.

Spot on, that's exactly why I had to reverse it else many security exceptions occur on hosts like GoDaddy and 1and1 Hosting.

A small change in the URLRewrite source ensures you can put ModPack in your web root with existing site content and still access BE.NET via /blog/. I figured that's more flexible or even SEO friendly than the /blog.aspx option in BE.NET ... just in case the file extension might change (or even disappear like IIS7 can) in the future.

This double usage/meaning might be mutually exclusive (ie, other settings might be needed so both are supported in the same codebase). I suspect that using relative paths might be enough to make a hosted version that uses RelativeWebRoot more consistently (so it is compatible in a same app segregated configuration), but I don't have a hosted environment to test, and I have a few things in my to-do before I can try and experiment with this. If I clear some time, I'll try and get a hosted account and see if I can merge both usages (merge ModPack with the dir changes -if you agree, Mike-), and then see if we can get all of the changes rolled into 1.4 or 1.5...

Of course agreed!

Let's combine and roll up as much as possible to end up with 1 ultimate BE.NET!

What's the plan and schedule? (since I use weekends only for BE/ModPack)

Cheers,
Mike
May 12, 2008 at 4:24 AM
Edited May 13, 2008 at 3:20 AM
zootie

I am attempting to use BE with a Club site (once I get it going there are other sites that will be done also).  I set up the directory and used the patch against the 10974 build, but was a little confused about moving the app_code, etc dirs (#6 on your list).  Are you saying they need to be in the root sites app_code in a BlogEngine subdirectory? if so it seems that there would be namespace and other issues. 

Tom

zootie wrote:
I noticed that Brian's changes haven't been put in the latest change set, and I figured I could try and maybe help a little. I went through Brian's changelog and replayed it on top of change set 10566 (should work with newer change sets) and then used WinMerge to compare both versions. The idea was to try and provide confirmation to Brian's documentation, and to try and help anybody who is trying to get this working,

Distilling down Brian's changes:
  1. Additional change(s)
    1. Move contents of App_GlobalResources, App_Code & App_Data to a BlogEngine subdirectory under each directory (App_GlobalResources\BlogEngine, App_Code\BlogEngine & App_Data\BlogEngine).
    2. In a subdirectory installation, you put all files in the subdirectory, and move/merge Web.config, Web.sitemap, robots.txt, Global.asax, Bin, App_GlobalResources, App_Code & App_Data to the root of the application and configure your web.config accordingly.

Web.config considerations
  1. Obviously, you have to set BlogEngine.VirtualPath (and it has to be a subdirectory, not a sub-application)
  2. Change default value for StorageLocation to ~/App_Data/BlogEngine
  3. Change loginUrl (from ~/login.aspx to ~/<your value for BlogEngine.VirtualPath>/login.aspx)
  4. Change error 404 redirect to redirect="~/<your value for BlogEngine.VirtualPath>/error404.aspx"


May 14, 2008 at 1:37 PM

senixon, I've been busy in another project. I'll try and upload the patch for 1.3.1.0 this week. Albeit, if you're in a hurry, 10974 seems stable enough...

MikevZ, Once I get the patch for 1.3.1.0 uploaded, I'll start comparing ModPack sr1 with it, and distill down the changes that would apply. Then we'll have to see about testing on a couple hosting providers. 

GeoMarketing, Yes, they need to be in the root site's {{App_Code, App_GlobalResources}} directories - mostly to follow the purpose of these directories. There aren't many references in code to these folders, it's just the way they work. {{App_Data}} is kind of the exception, since you can set it to anything you'd want by using StorageLocation in web.config. As to collisions, there isn't a lot of code in {{App_Code/BlogEngine}}, so it isn't likely to cause code namespace collisions. Or if you meant to support multiple blogs in subdirectories, this patch doesn't address this functionality. I guess that the Xml multi-blog provider might work with it, and allow multiple blogs in multiple subdirectories ({{App_Code, App_GlobalResources}} wouldn't collide as long as all the blogs are using the same version, and {{App_Data}} would be specific to each blog).
May 14, 2008 at 3:58 PM

I am not a software developer and I do not know the BE code, so forgive me for asking...

Can someone tell me if BlogEngine.NET will be supported in a virtual app directory and (e.g. /blog), and if so are the upcoming changes expected to fix that? From the last post it seems that BE will work with patch 10974 in a sudirectory off the root application, but the subdirectory is not an application? i.e. it seems that BE must be blended with the root app and can then be located in a subdirectory?

I was hoping that BE could be installed in a standalone app subdirectory.

Thanks.
May 15, 2008 at 11:07 AM


FlyTheBlueSky wrote:

I am not a software developer and I do not know the BE code, so forgive me for asking...

Can someone tell me if BlogEngine.NET will be supported in a virtual app directory and (e.g. /blog), and if so are the upcoming changes expected to fix that? From the last post it seems that BE will work with patch 10974 in a sudirectory off the root application, but the subdirectory is not an application? i.e. it seems that BE must be blended with the root app and can then be located in a subdirectory?

I was hoping that BE could be installed in a standalone app subdirectory.

Thanks.

BE already works fine in a subdirectory configured as an application. You must either override any conflicts or stop inheritance from your parent directory's web.config. No other changes should be necessary.
May 18, 2008 at 8:58 AM
@Zootie: Sounds good to me. If your 1.3.1 patch could integrate ModPack SR1 bits then you've managed to end up with one single BE.NET version/installation. Imho, that's our main goal.

You wrote:

Once I get the patch for 1.3.1.0 uploaded, I'll start comparing ModPack sr1 with it, and distill down the changes that would apply. Then we'll have to see about testing on a couple hosting providers. 

If there's anything you want me to do in this process, please let me know. For example, I wrote up a draft PDF for ModPack SR1 with required source code changes.

Good luck and thanks for your contributions!
-Mike
May 18, 2008 at 10:34 PM


Taylex wrote:

BE already works fine in a subdirectory configured as an application. You must either override any conflicts or stop inheritance from your parent directory's web.config. No other changes should be necessary.

No, it DOES NOT. That's why I started this thread back in February. I doubt that BlogEngine is going to work for me - I'm pretty much dead in the water unless I can run it as a standalone app in the /blog directory at DiscountASP.NET. At the moment I am still on BE 1.2 with some changes that made it work, somehow. 

Can anyone suggest a suitable ASP.NET alternative to BlogEngine.NET?

Thanks.
May 18, 2008 at 11:10 PM


FlyTheBlueSky wrote:


Taylex wrote:

BE already works fine in a subdirectory configured as an application. You must either override any conflicts or stop inheritance from your parent directory's web.config. No other changes should be necessary.

No, it DOES NOT. That's why I started this thread back in February. I doubt that BlogEngine is going to work for me - I'm pretty much dead in the water unless I can run it as a standalone app in the /blog directory at DiscountASP.NET. At the moment I am still on BE 1.2 with some changes that made it work, somehow. 

Can anyone suggest a suitable ASP.NET alternative to BlogEngine.NET?

Thanks.

Sorry you never got it working, I have 23 installs and counting in a subdirectory as application, must be something different at DiscountASP.net. I do also use SubText in the /Blog scenario without issue.


May 29, 2008 at 7:15 PM


Taylex wrote:


Sorry you never got it working, I have 23 installs and counting in a subdirectory as application, must be something different at DiscountASP.net. I do also use SubText in the /Blog scenario without issue.

ISSUE RESOLVED: Taylex, you sounded so sure of yourself that I went back and read your posts, and I decided to try again. Thanks...

This is how I got BE 1.3.1.0 running at discountasp.net, in an application folder /blog.

1. Installed in /blog as per instruction video.
2. Enabled web application for /blog.
3. Changed to SQL provider as per instruction video.
4. The inheritInChildApplications="false" solution was not viable in my environment, so I removed all inherited modules in the /blog application web.config. e.g.

<

 

httpModules>
.....
   <remove name="AnonymousIdentification" />

 

 

   <!--

 

remove unwanted inherited modules -->
   <
remove name="UrlRewriter" />
   <
remove name="WebPageSecurity" />
</
httpModules>

 

2. I had to create stubs for themes that are declared in the root application but were not declared in the /blog application. Basically, I just copied /App_Themes to /blog/App_Themes

And that was basically it. In fact, it was easier than getting BE 1.2 installed.
I am very happy to have BE 1.3 up and running...
 
May 29, 2008 at 8:08 PM
Edited May 29, 2008 at 8:12 PM


FlyTheBlueSky wrote:


ISSUE RESOLVED: Taylex, you sounded so sure of yourself that I went back and read your posts, and I decided to try again. Thanks...

 

2. I had to create stubs for themes that are declared in the root application but were not declared in the /blog application. Basically, I just copied /App_Themes to /blog/App_Themes


I am glad you got it working. It was frustrating knowing that it does work when others can't get it to.
A cleaner option to your #2 is to add a blank theme or styleSheetTheme directive to your pages section of the web config overriding the parent such as:

<pages enableSessionState="false" enableViewStateMac="true" enableEventValidation="true" styleSheetTheme="">

 

 

 

 

 

Nov 17, 2008 at 1:58 PM
Edited Nov 17, 2008 at 2:11 PM
You get the calendar error because this section is probably not in your web.config:

    <pages>
            <controls>
                <add tagPrefix="asp" namespace="System.Web.UI" assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
                <add tagPrefix="asp" namespace="System.Web.UI.WebControls" assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
        <add namespace="Controls" tagPrefix="blog"/>
      </controls>
    </pages>

See the last part where it says: add namespace etc.. tagprefix="blog"  hence it can't find "blog:calendar" since .NET doesn't know the tag prefix exists.


Dec 17, 2008 at 9:18 PM
I've installed BE in multiple /blog subdirectories, no problem. It's wonderful, actually.  I just wish I was knowledgable enough to put google adsense under the navigation bottom right, or anywhere, but that's another issue.

My problem is that I am trying to install BE into a subsubdirectory, something like mainsite.com/user1/blog & I've hit  the limit on my understanding of why it doesn't work when I've done everything the same as in previous installs, the only difference being I'm installing in a subdirectory of a subdirectory of the root directory.  Here's the message I get:

Server Error in '/' Application.

Runtime Error

Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".

<!-- Web.Config Configuration File -->

<configuration>
    <system.web>
        <customErrors mode="Off"/>
    </system.web>
</configuration>

Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's <customErrors> configuration tag to point to a custom error page URL.

<!-- Web.Config Configuration File -->

<configuration>
    <system.web>
        <customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/>
    </system.web>
</configuration>
Can I do a search and replace to the applicable files to correct the file path? If that is it?  If not, and you're kindly disposed to help, can you please put it in lay terms for ASP simpletons like me?

Thanks!

Coordinator
Dec 17, 2008 at 9:42 PM
This error message is just stating that there's more detailed error information you can get if you make the suggested changes to the web.config file where your new blog is.  In your web.config file, you have a <configuration> section.  Within that, there will be a <system.web> section.  Within that, you may or may not have a <customErrors> tag.  If you do, replace it with <customErrors mode="Off"/>  If you don't yet have a <customErrors> tag, then add <customErrors mode="Off"/>  It's case sensitive too.  Once you make that change, you should get a more detailed error msg.
Dec 22, 2008 at 7:28 PM
Thanks, Ben.  I replaced the custom errors tag, and then I got this message:

Unable to load default BlogProvider

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Configuration.Provider.ProviderException: Unable to load default BlogProvider

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[ProviderException: Unable to load default BlogProvider]
   BlogEngine.Core.Providers.BlogService.LoadProviders() +285
   BlogEngine.Core.BlogSettings.Load() +38
   BlogEngine.Core.BlogSettings..ctor() +221
   BlogEngine.Core.Web.HttpModules.CompressionModule.System.Web.IHttpModule.Init(HttpApplication context) +35
   System.Web.HttpApplication.InitModulesCommon() +66
   System.Web.HttpApplication.InitInternal(HttpContext context, HttpApplicationState state, MethodInfo[] handlers) +1006
   System.Web.HttpApplicationFactory.GetNormalApplicationInstance(HttpContext context) +259
   System.Web.HttpApplicationFactory.GetApplicationInstance(HttpContext context) +114
   System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr) +350

Do you see something amiss in the Stack Trace?  Is it because the /blog is in a subdirectory of a subdirectory?

Coordinator
Dec 22, 2008 at 8:44 PM
That's definitely a much more detailed error message.  Not an error I've experienced myself, though :-)

Look in your web.config file to see what your defaultProvider is.  The section will look something like:

<BlogEngine>
    <blogProvider defaultProvider="XmlBlogProvider">
        <providers>
            <add name="XmlBlogProvider" type="BlogEngine.Core.Providers.XmlBlogProvider, BlogEngine.Core"/>
            <add name="DbBlogProvider" type="BlogEngine.Core.Providers.DbBlogProvider, BlogEngine.Core" connectionStringName="BlogEngine"/>
        </providers>
    </blogProvider>
</BlogEngine>

Your default provider will probably be XmlBlogProvider (like shown above) or it may be DbBlogProvider or even something else.  What default provider do you see?  If it's DbBlogProvider, then I'd make sure your DB connection string in the web.config file is correct.  Whatever the default provider is, make sure within the <providers> section that there is a provider with a name matching your defaultProvider.

There shouldn't be a problem with it being installed in a subdirectory of a subdirectory.  Wherever your blog is installed, you'll want to make sure the directory your blog is in is marked as a Web Application within the webserver.  Do you have another BlogEngine installation in one of the parent folders?
Jan 19, 2009 at 2:05 AM
I have installed BlogEngine in a sub application folder 'blog'.  I have another application running in the root folder. I get the following error.

Configuration Error

Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.

Parser Error Message: Could not load type 'VCHsite.vchSiteModule'. (c:\websites\149293nm7\web.config line 43)

Source Error:

Line 41: 
Line 42:     <httpModules>
Line 43:       <add name="vchSiteModule" type="VCHsite.vchSiteModule" />
Line 44:     </httpModules>
Line 45: 

This is from the root web.config file.  If I remove this httpModule Blog engine runs properly, but my root application does not.  I've poked around the discussions and found some ideas to try but nothing has worked.  Can anyone help.
Coordinator
Jan 19, 2009 at 2:39 AM
In your BlogEngine's web.config file, you can remove the vchSiteModule so it is not used in BlogEngine.  It'll still be used in your root application.

<httpModules>
  <remove name="vchSiteModule" />
  ... existing BlogEngine modules ...
</httpModules>
Jan 19, 2009 at 10:56 AM
I sorry I didn't make it clear that 'vchSiteModule' is only in the root web.config file.  Again the site structure is another script in the root and blogengine is set as an app in the 'blog' folder located in the root .  I've included my blogengine web.config file.  Do you see any reason why it is bombing out on my root application web.config file?

<?xml version="1.0"?>
<configuration>
    <configSections>
        <sectionGroup name="BlogEngine">
            <section name="blogProvider" requirePermission="false" type="BlogEngine.Core.Providers.BlogProviderSection, BlogEngine.Core" allowDefinition="MachineToApplication" restartOnExternalChanges="true"/>
        </sectionGroup>
    </configSections>
    <BlogEngine>
        <blogProvider defaultProvider="XmlBlogProvider">
            <providers>
                <add name="XmlBlogProvider" type="BlogEngine.Core.Providers.XmlBlogProvider, BlogEngine.Core"/>
                <add name="DbBlogProvider" type="BlogEngine.Core.Providers.DbBlogProvider, BlogEngine.Core" connectionStringName="BlogEngine" />
            </providers>
        </blogProvider>
    </BlogEngine>
    <!-- configSource is not implemented in Mono.
    <connectionStrings configSource="sql.config" />
  -->
    <connectionStrings>
        <clear/>
        <add name="LocalSqlServer" connectionString="dummy"/>
        <!-- Mono complains if LocalSqlServer isn't specified -->
        <add name="BlogEngine" connectionString="Data Source=MySQLServer;User ID=user;Password=password;persist security info=False;initial catalog=BlogEngine;" providerName="System.Data.SqlClient"/>
    </connectionStrings>
 
    <appSettings>
        <add key="BlogEngine.FileExtension" value=".aspx"/>
        <!-- You can e.g. use "~/blog/" if BlogEngine.NET is not located in the root of the application -->
        <add key="BlogEngine.VirtualPath" value="~/"/>
        <!-- The regex used to identify mobile devices so a different theme can be shown -->
        <add key="BlogEngine.MobileDevices" value="(nokia|sonyericsson|blackberry|samsung|sec\-|windows ce|motorola|mot\-|up.b|midp\-)"/>
        <!-- The name of the role with administrator permissions -->
        <add key="BlogEngine.AdminRole" value="Administrators"/>
        <!--This value is to provide an alterantive location for storing data.-->
        <add key="StorageLocation" value="~/App_Data/"/>
    <!--A comma separated list of script names to hard minify. It's case-sensitive. -->
    <add key="BlogEngine.HardMinify" value="blog.js,widget.js,WebResource.axd"/>
    </appSettings>
    
  <system.web>
        <compilation debug="true">
            <assemblies>
                <add assembly="System.Management, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
                <add assembly="System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
                <add assembly="System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
                <add assembly="System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
                <add assembly="System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
                <add assembly="System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
                <add assembly="System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
            </assemblies>
        </compilation>

    <globalization requestEncoding="utf-8" responseEncoding="utf-8" culture="auto" uiCulture="auto"/>
        <httpRuntime enableVersionHeader="false" useFullyQualifiedRedirectUrl="true" maxRequestLength="16384" executionTimeout="3600" requestLengthDiskThreshold="16384"/>
        <machineKey validationKey="D9F7287EFDE8DF4CAFF79011D5308643D8F62AE10CDF30DAB640B7399BF6C57B0269D60A23FBCCC736FC2487ED695512BA95044DE4C58DC02C2BA0C4A266454C" decryptionKey="BDAAF7E00B69BA47B37EEAC328929A06A6647D4C89FED3A7D5C52B12B23680F4" validation="SHA1" decryption="AES"/>
        
    <authentication mode="Forms">
            <forms timeout="129600" name=".AUXBLOGENGINE" protection="All" slidingExpiration="true" loginUrl="~/login.aspx" cookieless="UseCookies"/>
        </authentication>
        
    <pages enableSessionState="false" enableViewStateMac="true" enableEventValidation="true">
            <controls>
                <add namespace="Controls" tagPrefix="blog"/>
            </controls>
        </pages>
        
    <customErrors mode="Off">
            <error statusCode="404" redirect="~/error404.aspx"/>
        </customErrors>
                
    <membership defaultProvider="XmlMembershipProvider">
            <providers>
                <clear/>
                <add name="XmlMembershipProvider" type="BlogEngine.Core.Providers.XmlMembershipProvider, BlogEngine.Core" description="XML membership provider" passwordFormat="Hashed"/>
                <add name="SqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider" connectionStringName="BlogEngine" applicationName="BlogEngine"/>
                <add name="DbMembershipProvider" type="BlogEngine.Core.Providers.DbMembershipProvider, BlogEngine.Core" passwordFormat="Hashed" connectionStringName="BlogEngine"/>
            </providers>
        </membership>
        
    <roleManager defaultProvider="XmlRoleProvider" enabled="true" cacheRolesInCookie="true" cookieName=".BLOGENGINEROLES">
            <providers>
                <clear/>
                <add name="XmlRoleProvider" type="BlogEngine.Core.Providers.XmlRoleProvider, BlogEngine.Core" description="XML role provider"/>
                <add name="SqlRoleProvider" type="System.Web.Security.SqlRoleProvider" connectionStringName="BlogEngine" applicationName="BlogEngine"/>
                <add name="DbRoleProvider" type="BlogEngine.Core.Providers.DbRoleProvider, BlogEngine.Core" connectionStringName="BlogEngine"/>
            </providers>
        </roleManager>
        
    <siteMap defaultProvider="PageSiteMap" enabled="true">
            <providers>
                <add name="PageSiteMap" description="The site map provider that reads in the .sitemap XML files." type="BlogEngine.Core.Web.Controls.PageSiteMap, BlogEngine.Core"/>
                <add name="SecuritySiteMap" description="Used for authenticated users." type="System.Web.XmlSiteMapProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" securityTrimmingEnabled="true" siteMapFile="Web.sitemap"/>
            </providers>
        </siteMap>
    
        <httpModules>
            <add name="WwwSubDomainModule" type="BlogEngine.Core.Web.HttpModules.WwwSubDomainModule, BlogEngine.Core"/>
            <add name="UrlRewrite" type="BlogEngine.Core.Web.HttpModules.UrlRewrite, BlogEngine.Core"/>
            <add name="CompressionModule" type="BlogEngine.Core.Web.HttpModules.CompressionModule, BlogEngine.Core"/>
            <add name="ReferrerModule" type="BlogEngine.Core.Web.HttpModules.ReferrerModule, BlogEngine.Core"/>
            <!--Remove the default ASP.NET modules we don't need-->
            <remove name="PassportAuthentication"/>
            <remove name="Profile"/>
            <remove name="AnonymousIdentification"/>
        </httpModules>
        
    <httpHandlers>
            <add verb="*" path="file.axd" type="BlogEngine.Core.Web.HttpHandlers.FileHandler, BlogEngine.Core" validate="false"/>
            <add verb="*" path="image.axd" type="BlogEngine.Core.Web.HttpHandlers.ImageHandler, BlogEngine.Core" validate="false"/>
            <add verb="*" path="syndication.axd" type="BlogEngine.Core.Web.HttpHandlers.SyndicationHandler, BlogEngine.Core" validate="false"/>
            <add verb="*" path="sitemap.axd" type="BlogEngine.Core.Web.HttpHandlers.SiteMap, BlogEngine.Core" validate="false"/>
            <add verb="*" path="trackback.axd" type="BlogEngine.Core.Web.HttpHandlers.TrackbackHandler, BlogEngine.Core" validate="false"/>
            <add verb="*" path="pingback.axd" type="BlogEngine.Core.Web.HttpHandlers.PingbackHandler, BlogEngine.Core" validate="false"/>
            <add verb="*" path="opensearch.axd" type="BlogEngine.Core.Web.HttpHandlers.OpenSearchHandler, BlogEngine.Core" validate="false"/>
            <add verb="*" path="metaweblog.axd" type="BlogEngine.Core.API.MetaWeblog.MetaWeblogHandler, BlogEngine.Core" validate="false"/>
            <add verb="*" path="rsd.axd" type="BlogEngine.Core.Web.HttpHandlers.RsdHandler, BlogEngine.Core" validate="false"/>
            <add verb="*" path="css.axd" type="BlogEngine.Core.Web.HttpHandlers.CssHandler, BlogEngine.Core" validate="false"/>
            <add verb="*" path="js.axd" type="BlogEngine.Core.Web.HttpHandlers.JavaScriptHandler, BlogEngine.Core" validate="false"/>
            <add verb="*" path="rating.axd" type="BlogEngine.Core.Web.HttpHandlers.RatingHandler, BlogEngine.Core" validate="false"/>
            <add verb="*" path="opml.axd" type="BlogEngine.Core.Web.HttpHandlers.OpmlHandler, BlogEngine.Core" validate="false"/>
            <add verb="*" path="blogml.axd" type="BlogEngine.Core.Web.HttpHandlers.BlogMLExportHandler, BlogEngine.Core" validate="false"/>
            <add verb="*" path="sioc.axd" type="BlogEngine.Core.Web.HttpHandlers.Sioc, BlogEngine.Core" validate="false"/>
            <add verb="*" path="apml.axd" type="BlogEngine.Core.Web.HttpHandlers.Apml, BlogEngine.Core" validate="false"/>
            <add verb="*" path="foaf*.axd" type="BlogEngine.Core.Web.HttpHandlers.Foaf, BlogEngine.Core" validate="false"/>
        </httpHandlers>
    </system.web>
</configuration>

Jan 19, 2009 at 11:20 AM
What Ben meant was to add <remove name="vchSiteModule" /> to your httpModules section of your web.config in your /blog directory. This should override the inheritance of that module in your parent web.config to your /blog application.
Jan 19, 2009 at 11:30 AM
Worked great.  Thanks,
Jan 27, 2009 at 2:15 PM
Hi, I've read through this discussion and tried many of the suggestions with no luck yet. I have a virtual directory set up for my root application in IIS, then placed the BE 1.4 code into a /blog subdirectory that is three folders deep from the root directory. I get the following error when I try to access the blog URL directly. Oddly enough, I get this same error whether I create a separate IIS virtual directory for the Blog subapplication or not.

Does anyone have any ideas as to what I'm doing wrong (or need to do) that is generating this error?

Configuration Error

Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.

Parser Error Message: It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level.  This error can be caused by a virtual directory not being configured as an application in IIS.

Source Error:

Line 7:  	</configSections>
Line 8:  	<BlogEngine>
Line 9: <blogProvider defaultProvider="XmlBlogProvider">Line 10: 			<providers>
Line 11: 				<add name="XmlBlogProvider" type="BlogEngine.Core.Providers.XmlBlogProvider, BlogEngine.Core"/>
Jan 27, 2009 at 3:42 PM
I think we've had a breakthrough - not sure why I didn't consider it before but I created the virtual directory for the /Blog site nested in the same folder where the actual /Blog (BE 1.4) code resided, and I was finally able to pull up the BE site! No changes to the BE web.config were needed. I'm still doing some testing of the BE subsite but all looks well for now. Thanks!
Apr 1, 2009 at 2:05 PM
Hi I'm new to BE! Found it via a quick search on Google.  I'm currently working on creating a blog for an existing ASP.net site.... whilst creating a virtual directory works it means that you would be unable to pass authenticated session between the site and the blog which is a bit of a pain. To get BE to work as a sub directory without a virtual directory I've had to modify lots of things but I've finally finished so now my version does work as either a stand-alone blog or can be put in a sub directory.  Some of the key things are.... App-Resources and web.config setting as being added to the root web.config or app-resources folder,  name spaces!!!! Aaargh! Why are there no namespaces? Putting this into another site without them causes conflicts if there the same names. I've added name spaces to EVERYTHING! Registering .cs controls in a web project doesn't work the same way as a web application. This causes the whole thing to die as it doesn't understand .cs as a registerable file type.  I've fixed this by changing the register command so it registers the parent namespace.  Templates often contain hardcoded paths!! Changed some of these but not all!.

Is anyone interested in me posting back my version?