Several Issues with RC2.0

Dec 6, 2010 at 5:50 PM

Hello, 

I am currently trying to port a blog from 1.5.1.18 til RC2.0. I have copied the existing blog into a folder on my computer and then unpacked the web release of 2.0 to another. 

I am running on a Windows 7 Ultimate. 

First Issue

Getting the RC to run in basic configuration turned out an error from the IIS. Apparently this section in the web.config is a duplicate: 

 

    <sectionGroup name="system.web.extensions" type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
      <sectionGroup name="scripting" type="System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
	    <section name="scriptResourceHandler" type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication"/>
		<sectionGroup name="webServices" type="System.Web.Configuration.ScriptingWebServicesSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
		  <section name="jsonSerialization" type="System.Web.Configuration.ScriptingJsonSerializationSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="Everywhere"/>
		  <section name="profileService" type="System.Web.Configuration.ScriptingProfileServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication"/>
          <section name="authenticationService" type="System.Web.Configuration.ScriptingAuthenticationServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication"/>
          <section name="roleService" type="System.Web.Configuration.ScriptingRoleServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication"/>
        </sectionGroup>
      </sectionGroup>
    </sectionGroup>

 

Commenting out this section, allowed me to at least run the web application.

Second Issue

Permissions. Right this is on me, once I found the right users this was easy. However, then I got this: 

Unable to generate a temporary class (result=1). error CS2001

This turned out to be a permission issue, and was resolved when the aspnet and iis_iusrs accounts was given permissions to the c:\windows\temp folder, which I strongly dislike. 

Third Issue

The upgrade doc recommends installing to a new directory, however it fails to comment on how to get settings and posts/pages. I finally got posts imported through the click-once, but pages and settings still defy me.  

Coordinator
Dec 6, 2010 at 6:15 PM

Thanks for trying out the 2.0 RC.

First Issue

BE 2.0 is designed for .NET 3.5 (this includes the web.config file).  If you're running in a .NET 4.0 application pool, you'll have this problem.  Fortunately, the solution is easy as you found.

Second Issue

That's interesting.  I don't recall seeing any problems reported here with permissions and the windows temp folder.  Normally BE only needs Write permissions turned on for the App_Data folder.  But I suppose IIS and the website needs to have some basic, minimal permissions on the machine as well.

Third Issue

If you're using the default XML storage, step 6 in the upgrade instructions explains how to copy your existing settings/posts/pages into the App_Data folder.  This is done by copying the entire contents of your existing App_Data folder into the BE 2.0 App_Data folder.  If you're using a DB, when upgrading, you are still using the same DB (with all of your settings, posts, pages, etc).  In this case, you are just running the DB upgrade script to add the new tables/columns to your existing database.

Dec 6, 2010 at 7:07 PM

Update

  1. First Issue: Cool, although I have more than 10 years of software developer experience, I am mostly a novice when it comes to web development. So that explains it. Maybe a note regarding this is the release notes? That is, if it isn't already there. 
  2. Second Issue: Regarding third issue, I just tried that and got a new permission error. On IIS 6 and 7 the asp.net process is apparently running under Network Service system account, and this failed now. So I added this to the security settings, and now that is working. Maybe it solves the issue with the windows temp folder. 
  3. Third Issue: My bad. I didn't read the upgrade instructions properly enough. I did copy the old app_data over, but I didn't empty the folder first... 

New Issue

I currently have 3 pages, one of which is designated as front page. This does not seem to be working. Although the page is marked as front page, I consequently get the default post list as front page. 

I have a custom theme in which I have a page as front page (see above). In my top menu I have a link to news.aspx which SHOULD be a list of blog posts, but this page is apparently no more. If I copy it in from the old files (and the *.cs of course) it works as always. 

Otherwise, it seems like a very nice upgrade, I especially like the dashboard. As I wrote in my first post, I am testing an upgrade from 1.5.1.18. Is there any changes I need to be aware of regarding custom themes? 

 

Coordinator
Dec 7, 2010 at 2:35 AM

Maybe we will include a .NET 4.0 web.config file since more people are starting to use .NET 4.0 more and more.  This would help with the first issue -- although the person still needs to know which which .NET version their application pool is configured for, which not everyone is aware of or thinks of.

For the 2nd issue -- good to know about that.

The issue with the "Front Page" not showing.  I'm almost certain this was fixed just recently after the BE 2.0 RC.  The problem is related to .NET 4.0 (which you're using).  It was reported here, and fixed a couple of days ago.  Glad you posted your finding on this.  The fix will be included in the final 2.0.

Themes should work the same as they did before.  It could depend on the theme, but I've tested a few older themes with BE 2.0, and they are working.

Dec 8, 2010 at 12:17 AM

I do believe that in order to use a .Net 4.0 web.config, you'd have to have BlogEngine compile in .Net 4.0. IIS will throw an error otherwise.

Coordinator
Dec 8, 2010 at 12:48 AM

That's a good thought, however, I just tested it with the BE 2.0 RC ... using a .NET 4.0 web.config file in a .NET 4.0 app pool with the original BlogEngine.Core.dll file that is included with BE 2.0 RC.  It's running .... no errors while clicking around to a few pages (I logged in, created a post).

This informative page does say (excerpt):

Compiled (binary) files that were created using earlier versions of ASP.NET will also run without errors on ASP.NET 4.....

So, it sounds like we will be okay.  Plus, I think people like thomasdue (original poster here) and Jerry Dean, are using the .NET 3.5 BlogEngine.Core.dll file (from the RC download) in their .NET 4.0 application pools.

Dec 8, 2010 at 7:21 PM

Yep. 

 

In other news: The fix for the frontpage ... page, does it require a recompile, or is it in the web part? 

Dec 8, 2010 at 9:05 PM

I thought I'd add to this thread as I also have some issues with RC2.0, mostly around the admin area (but that's as far as I've got so far)

I downloaded the web.zip file (not fussed about source) and extracted it to a folder, then created a new folder in wwwroot and copied the zip contents in there.
I gave everyone full permissions and unset read-only and browsed to the site at http://localhost/BlogEngine.Web/ - next I wanted to check out the admin area, so clicked the login link in the main menu.
The login was successful; the message changed to Welcome admin! Log Off - but there was no easy way to browse to the admin area? So looking at the site structure I guessed I needed to go to
http://localhost/BlogEngine.Web/admin/dashboard.aspx - fine... but all I see on the main menu there is Blogroll and Common Controls? If I want to get to the settings I have to type the url again?

What's been done to the admin area looks really sweet though, I'm hoping to upgrade from 1.6.1 to 2.0 and will be happy to keep on testing the RC

Coordinator
Dec 8, 2010 at 10:33 PM

thomasdue:  The front page fix is in the BE core, so yes a recompile is needed.  If you use the temporary workaround here, this does not require a recompile.

Coordinator
Dec 8, 2010 at 10:39 PM

Simon, thanks for testing out the RC.

The main way to get into the control panel is thru the Administration widget.  This is the widget that has links for Dashboard, Posts, Pages, Comments, Settings, etc.  This widget typically appears in the sidebar, but only when you are logged in.  If the widget isn't there for some reason, while logged in, you should be able to select the "Administration" widget from the widget dropdown list, and add it.

If you're logged in as an admin, you should see all the tabs going across the top:  Dashboard, Posts, Comments, Pages, Tracking, Controls, Extensions, Users and Settings.  These tabs go across the top.  Blogroll and Common Controls are "sub-tabs" on the right side when you are on the main "Controls" page.  I'm guessing you are seeing Blogroll and Common Controls on the right hand side when you are on the "Controls" tab?  We have this video here of BE 2.0.  In the video, you can see the main tabs at the top (Dashboard, Posts, Comments, etc).  Which of these tabs do you see -- only Controls?

Dec 9, 2010 at 7:21 AM

Ha! Workaround works like a charm, thanks :)

Dec 9, 2010 at 7:52 PM

Hi Ben,

The Administration widget only has BlogRoll and Common Controls in it. I tried removing then re-adding it, but it still only showed those 2 elements.

Clicking on them results in an Ooops page can't be found at http://localhost/BlogEngine.Web/Controls.aspx or http://localhost/BlogEngine.Web/Blogroll.aspx.
So it seems that there's an entire layer of the admin section that's not being linked to. Looking at ~/admin/menu.ascx I get the following:

<%@ Control Language="C#" AutoEventWireup="true" CodeFile="Menu.ascx.cs" Inherits="admin.Settings.Menu" %>
<ul>
    <li <%=Current("Blogroll.aspx")%>><a href="Blogroll.aspx">Blogroll</a></li>
    <li <%=Current("Controls.aspx")%>><a href="Controls.aspx">Common controls</a></li>
</ul>
Which matches what I'm seeing, but isn't what I'd expect.

Coordinator
Dec 9, 2010 at 8:52 PM

Simon, I just downloaded web.zip for RC2.0 and this is what admin/menu.ascx looks like:

 

<%@ Control Language="C#" AutoEventWireup="true" CodeFile="menu.ascx.cs" Inherits="Admin.Menu" %>
<ul runat="server" id="ulMenu" class="toprounded"  />

That's it, just 2 lines of code. Could it be that your download got messed up somehow?

 

Dec 9, 2010 at 9:38 PM

Hi Rtur,

I downloaded the zip again and the file was as you said - not sure how but looks like the version I had before was messed up. I've logged into the admin area and it's looking good.

Next I'm going to try to upgrade my exising blog from 1.6.1 to this new version and if I run into any more issues will let you know.

 

Dec 16, 2010 at 8:44 AM

Second Issue

That's interesting.  I don't recall seeing any problems reported here with permissions and the windows temp folder. 
Normally BE only needs Write permissions turned on for the App_Data folder.  But I suppose IIS and the website needs to
have some basic, minimal permissions on the machine as well.

You can change the path of the temp folder needed for xmlserializer

First of all you need to get the physical path to your website, it's easy but requires a few lines of code if you're in a hosted enviroment
You can use either "Request.PhysicalPath" or "Request.PhysicalApplicationPath" as both will give you a fairly good idea

Next add this section to web.config

<system.xml.serialization>
    <xmlSerializer tempFilesLocation="c:\foo"/>
</system.xml.serialization>

Taken from hanselmans blog
http://www.hanselman.com/blog/changingwhere xmlserializeroutputstemporaryassemblies.aspx