Footer I searched for a long time for a simple CSS solution to the eternal "sticky footer" problem, where the footer goes down to the end of the page. Up to now I have resorted to JavaScript to achieve this, which is not really the most elegant solution. It should be simple, right?

The other day, I stumbled upon what looked like a basic HTML/CSS solution. I wanted CSS that would push the footer to the bottom of the page, irrespective of content height, in an ASP.NET Master Page setup. Thanks to Ryan Fait for this.

It was straightforward enough to get it working for IE7. Firefox 3.0 didn't play nice at first until I moved the wrapper and footer divs out to the master page. Feel free to download the sample below and try it out for yourself - VS 2008 solution. Ignore the red wigglies in the master page. It has been tested in IE7, Firefox 3.0 and Chrome 0.2.149.29.

CSS_Sticky_Footer.zip (19.91 kb)

kick it on DotNetKicks.com  PHP, ASP, .NET, JSP Resources, Reviews

Tags: ,

ASP.NET | CSS



BlogEngine 1.4.5 and IIS7

by agrace 6. September 2008 15:57

Blog Up to now I have been using the old 1.2 version of BlogEngine and would pop in the 1.3 dll manually after deploying to fix a known security hole. I finally decided to upgrade to the latest 1.4.5 version last night. I use the SQL Server provider and usually download the source code version to my machine.

When using VS 2005 and IIS5 locally, it was easy to configure the BlogEngine.Web folder as the virtual directory. My physical path would be /CodersBarn/BlogEngine.Web and I would just point my browser to localhost. Since upgrading to VS 2008 and IIS7, this is a whole new ball game. When using the new IIS7, you will typically end up with the following under your wwwroot folder:

localhost/app1
localhost/app2
localhost/app3, etc.

You will notice that there is an extra node in the path in IIS7. The good news is that we don't have to continually go into IIS and change localhost when switching between projects. The bad news is that this causes problems with apps migrated up from the older IIS. Or am I missing something fundamental here?...

When migrating your ASP.NET 2.0 applications to IIS7, as when one moves up to VS 2008, you may also experience many of your links breaking. This is a separate issue relating to ASP.NET rebasing. If you have a link like this:

<img src="/images/mypic.jpg" alt="My Pic" />

Try changing it to:

<img src="~/images/mypic.jpg" alt="My Pic" runat="server" />

 

The ASP.NET runtime will now correctly resolve it, thanks to the addition of the runat="server". I had a blog posting on this very subject half-prepared and I plan to come back to this subject soon. In the meantime, you can find some information on K.Scott Allen's blog posting under "URL Rebasing in Master Pages"; scroll down the page to find it.

Back to BlogEngine. I have installed the full source code in my wwwroot folder many times in the past without any real hitches. This way, I can go in, tweak some code and re-deploy fairly quickly. I usually follow Al Nyveldt's BlogEngine screencasts and adjust the steps for my particular circumstances. In Al's "Installing BlogEngine.NET 1.4" screencast, he downloads the "Web" (executable) version. Normally, I follow along except that I would download the "Source" version. To make a long story short I had problems configuring the localhost in IIS7 and started getting the "It is an error to use a section registered as allowDefinition='MachineOnly' beyond machine.config" error (typical of virtual directory not correctly created). I also experienced the breaking image links described above although this was probably a side effect. FYI, Al's screencasts are the only real source of guidance out there for working with BlogEngine that I have been able to find. The problem here was with the user!

IIS7 Settings

 

FYI: BlogEngine source download is a solution with a core Web Application project and a Web Site project consisting of the main deployable part. I hate Web Site projects; they should be stamped out!!

In the end, I decided to follow Al's steps to the letter. I reckoned I could always download the source version to another folder later, make any code tweaks needed, and pop the updated core dll into the working bin folder. Even if you already have an older version of the blog engine with your own branding, your initial goal will still be to get the out-of-the-box site working with the standard theme. You can copy in your own theme folder later, after you have everything else working. The trick here is to take it slowly. Once the site is running and you have the new user account set up, you can look to updating the SQL functionality. This will involve running a db script which you can find in the setup folder of the download and running it in SQL Server Management Studio. Then all you have to do is update your Web.Config file and this is outlined in this screencast.

Add User

 

I then started to get the following error message:

Parser Error Message: Could not load the assembly 'App_Web_045byxd7'.

So, I relaxed the permissions on the project folder in @"\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files" folder enough to let me delete the temp files. This still didn't fix it. Then I realized that it was picking this up from the original master page in my themes folder which I had copied in:

<%@ master language="C#" autoeventwireup="true" inherits="site, App_Web_045byxd7"%>

 

So, I changed this and saved it back as follows:

<%@ Master Language="C#" AutoEventWireup="true" CodeFile="site.master.cs" Inherits="site" %>

 

Somehow this was lost in the copy and paste process. This finally compiled on the fly and worked locally. I still had to update some of the controls in my side navigation bar. For some reason, I can never get the newer TagCloud control to render correctly with my theme so I just grab a copy of the older one. The newer one lists all the tags on separate lines and it takes up a huge amount of space plus the weighting doesn't work. I see that the disclaimer still insists on rendering every word in caps. The blog roll links are still set to open in the same window and we still can't edit them in admin. Also, the archive page is a total mess when used with my style sheet so I have a pared down version to hand. FYI: my style sheet started out as the Dirtylicious theme; I simply re-worked it to get the look and feel I wanted.

Powered By Logo

 

There definitely needs to be a single document explaining and justifying the architecture step-by-step. Why would you choose to go with a Web Site template for instance? Call me opinionated but you'd have to be pretty retarded to go for that particular option. I know, my bad ;-)

I've said it before: BlogEngine is a great piece of work: but, it's been over-engineered. Both users and developers have to jump through quite a few hoops to get it to work. The bells and whistles should be optional plug-and-play components. Perhaps the distribution model needs to be changed to something that would allow both developers and general users to download different configurations depending on their needs?

Captain's Log: One day later and both the host and myself are pulling out what's left of our hair. I have the blog working correctly on my local but failing every time I tried to deploy it, both normally and with FTP, via VS 2008. In the end, the only way I could deploy it was via FTP using a seperate FTP tool. The saga continues and I am seriously thinking of looking at a more basic and robust blog engine that I can work with. At this time of writing, the blog is really unstable and the referrer's page is crashing with an unhandled exception message: System.IndexOutOfRangeException: Cannot find table 0.

I'd really like to get the full source version working in my wwwroot folder and correctly configured in IIS7. Has anyone out there managed to do this with 1.4.5?

In the meantime, the issue has been reported so if someone has a solution/explanation, I will post it here :-)

kick it on DotNetKicks.com

Tags:

ASP.NET | Blog | IIS



Google Chrome - First Impressions

by agrace 3. September 2008 20:54

Everybody and their Grand-Aunt are currently blogging about the new Google Chrome Browser so I'm joining the gang. First off, it's a beta so I'm not going to knock it for some of the various rendering problems I encountered; I used it on some exisiting sites I have developed with cross-browser consistency for IE7 and Firefox 3.0 (don't get me started on 3.0.1). For example, I'm experiencing what seems to be an unusual interpretation of the box model, problems with a Javascripted footer floating up a little from the end of a page, typical Googlesque background coloring of form fields, and textboxes having a color border placed around them when active, etc.

My Silverlight Won't Work :-(

One question begs to be asked: why would anyone base their new browser on the rendering engine of a browser (Safari) used by about 3% of users (mainly designers), at best? I discovered this nugget when attempting to find out why sites working in IE7 and Firefox 3.0 were not rendering properly in Chrome. It's not like there was a gun to Google's head to get this completed, so why not base it on a popular rendering engine?

Check out the comic book introduction to the new browser. This is a really slick architecture, the way browsers should be built. Plus it's open source... hopefuly we won't have to fix the bugs ourselves :-O Seriously, if Google can iron out the rendering inconsistencies and make it as consistent as Firefox 2.0, they are on to a winner here. Why nobody thought of updating the existing single-process architectures before now is beyond me.

Note to Microsoft: when can we expect Silverlight and Photosynth support for Chrome? Just asking :-|

kick it on DotNetKicks.com