What is a “Predicate delegate” – bytes

Thinking in terms of Delegates was always a bit of a challenge to me. So when I hit the Predicate parameter when trying to using a List<X>.FindAll(XType y).

The example given in discussion on this article went a long way to clearing this up. If I get more answers like this from Bytes I might start using this as my secondary source of programming answers after StackOverflow.

Customising the debug and run an ASP.NET MVC Application

I tend to use F5 to debug my code, my two teammates have a preference to have the codebase as a virtual directory in IIS and make changes to their code in Visual Studio and then reload the page in a browser to analyse the returned results.

Which is the better technique? Certainly my co-workers had a  point that by running using Cassini instead of IIS I was opening up myself to bugs popping up when the application was deployed to a real IIS box on testing and some IIS-specific behavior arose.

But why must I hassle myself with attaching IIS to the W3wp.exe process every time I want to do a line-by-line debug my code? And I always want to be debugging, especially in this new realm of integrated ASP.Net MVC where debugging a View means you have to worry about if the bug lies in your ASP.Net code, your JQuery code, or the service(s) your .ajax or .getJSON calls are making. I didn’t mind the hassle of having to recompile every time a change needed to be made inside the Controller or Business Logic layers once it meant I could track the state of my application during events as closely as possible.

Turns out we can have it both ways. These recommendation from Stephen Walter, although set on the topic of running an ASP.Net MVC Application specifically, are useful for any developer looking to customise the debug and run process when using Visual Studio 2008. So my coworkers and I will both be happy, because now they’ll be readily able to debug their code in real time (and engaging in a better coding practice at the same time) and I’ll be running my debug sessions on top of IIS to remove any possible hiccups from using Cassini for testing.

The settings are available on the Web tab on the Web Application Project’s properties page (ASP.Net MVC or not)  and to do this I have to make sure it is set to use a local IIS virtual directory (which I’ll make right there if it isn’t set already) and that I enable the check box that allows me to make code changes without the need to stop debugging and recompile.

Getting the address of the hosting server

One of the simple problems I’ve encountered was just getting the name of the server that’s running my ASPX application, whether it be the localhost:xxxx of VS 2008’s Cassini server, localhost, or http://www.myserver.com. The following commend returns that as a string.


The ServerVariables NameValueCollection has a very interesting collection of information that I can see being quite useful to know about in future.

DotNetJunkies has a good tutorial on ServerVariables in ASP.Net.

Note: The command above only returns the address as a string, not the protocol. If you want to use it in an anchor tag (<a href=”someaddress”>somelink</a>) don’t forget to append the protocol (e.g. ‘http://&#8217;) to the string returned from the command or you may experience some strange behaviors.

HOWTO: VS 2008 Fix for ASP.Net MVC and xUnit.net new project errors

This may have been fixed by now with the release of ASP.Net MVC 1.0 RC, but using ASP.Net MVC Beta 1 to create a new project with xUnit.Net tests always generated the error “The name ‘GlobalApplication’ does not exist in the current context” when you first compile, something a bit daunting to any developer now trying to ‘get’ ASP.Net MVC.

This Codeplex discussion has the answer.

Basically rename all instances of GlobalApplication to MvcApplication in the Test project and things should compile and run fine. If you want to know exactly why this works, you can take a read of this cool article on the anatomy of an ASP.Net MVC Application.

HOWTO: Convert BlogEngine.NET from Web Site to Web Application Project

Much thanks to BenAmada for providing on this thread a step-by-step guide for converting the downloadable BlogEngine.Net Web Site Project to a Web Application Project.

This varies a bit from the MSDN Documentation walkthrough on moving an ASP.Net Web Site Project to a Web Application Project as there are some added steps due to several reasons in the architecture of BlogEngine.Net e.g. the way BlogEngine does themes, its widgets framework and controls dependencies. These are not to criticise the design decisions made, it still is a full featured, well built blogging application which I use and customise daily.

Here are the steps repeated, but I encourage anyone benefitting from this to post your thanks to Ben on this thread as well so that he knows.

1. Create a new WAP.  File -> New -> Project -> Visual C# -> ASP.NET Web Application.  Select the location (I created a new folder for this WAP project), and I used ‘BeWap’ for the Name of the project.

2. Close Solution.

3. In Windows Explorer, copy all the BE files into the WAP folder.  You’ll be overwriting a couple of the files that were included in the new WAP project we created (default.aspx and web.config and maybe a couple of others).

4. Rename the App_Code folder to Old_App_Code.

5. Reopen WAP solution in Visual Studio.

6. Right-click on project name (BeWap) in Solution Explorer, and select ‘Add Reference’.  Go to the Browse tab, and browse to the BIN directory in this project, select ‘BlogEngine.Core.dll’.

7. In Solution Explorer, click the ‘Show All Files’ icon.  All the files/folders that we copied into the WAP folder will show up in Solution Explorer, but they are not yet included in the project, so they are white/ghosted out icons.  Select all these ‘excluded’ folders/files in Solution Explorer, right-click and select ‘Include in Project’.

8. Select the top node in Solution Explorer, ‘BeWap’ (right under Solution ‘BeWap’).  Right-click and select ‘Convert to Web Application’.

9. Save all files (Ctrl-Shift-S).

10. In the web.config file, in the <pages> section, there’s this line:

<add namespace=”Controls” tagPrefix=”blog”/>

Change that to:

<add assembly=”BeWap” namespace=”Controls” tagPrefix=”blog”/>

… where “BeWap” is the name of this WAP project.

11. The site.master files for Indigo, Mobile and Standard all have the same class name of ‘site’.  Change the class name in site.master.cs for the Standard theme to site_standard and changed the Inherits attribute in the <%@ Master %> directive in site.master to site_standard (so they match).  Need to do the same thing for the Indigo and Mobile themes … giving them class names of site_indigo and site_mobile.

12. The class name in edit.ascx, edit.ascx.cs and edit.ascx.designer.cs files in the RecentComments widget is widgets_RecentPosts_edit.  Need to change the class name in these 3 files to widgets_RecentComments_edit.

13. The class name in edit.ascx, edit.ascx.cs and edit.ascx.designer.cs files in the TextBox widget is widgets_LinkList_edit.  Need to change the class name in these 3 files to widgets_TextBox_edit.

14. The class name in widget.ascx, widget.ascx.cs and widget.ascx.designer.cs files in the TextBox widget is widgets_LinkList_widget.  Need to change the class name in these 3 files to widgets_TextBox_widget.

15. Save all files (Ctrl-Shift-S).

16. When trying to build the project, I was getting about 47 errors about unrecognized controls.  The problem was the ‘designer.cs’ files didn’t get created for these ASPX pages back in step 8 when I did the ‘Convert to Web Application’ command.  Even if I try repeating that step again, the designer.cs files still do not get created.  Visual Studio is complaining that various BE controls (blog:SearchBox, blog:PageList, etc) are unknown server tags.  If Visual Studio can build the project once, then these BE controls will start to get recognized.  What I did to get this done was temporarily exclude these pages that reference the BE controls.  The pages referencing these controls can be found in Visual Studio’s error list when you try to build the project.  I excluded the entire Widgets folder, the entire themes folder, the post.aspx file, the error404.aspx file, the default.aspx file and the apiTagMiniView.aspx file.

17. Build the solution.  Should get no errors.

18. Add those temporarily excluded items back into the project from two steps ago.

19. Select the top node in Solution Explorer, ‘BeWap’ (right under Solution ‘BeWap’).  Right-click and select ‘Convert to Web Application’.  The pages we re-included back into the project should now all have designer.cs files.

20. Build the solution.  Should get no errors.

21. Run the solution.  Everything should work.

Dashes vs. underscores in website URLs

As one of the design decisions made when the GigJunkie website moved to MVC world, we decided to adopt Wikipedia styled URL naming by substituting spaces with underscores, instead of dashes. Some debate was thus unleashed when one of us discovered Google’s Matt Cutts’ article that showed this may have created an unforseen hindrance for our SEO goals. Another SEO article only added fuel to the fire as we now tried to figure out with our own testing if the discoveries dictated in these articles still held, i.e. that dashes were, by article and the published evidence, more index-friendly than underscores as replacements for spaces between words in URLs. I ended up starting to read the mantra of search engineers, the Stanford-published document that started it all, as well as another article on the PageRank concept in the seemingly hopeless quest to make sense of it all…

Perhaps I’m just too tired from the day, so I’ll put these on hold till tomorrow when I can figure out some sort of metric for weighing the impact (if any) of our design decision.