You have reached the blog of Keith Elder. Thank you for visiting! Feel free to click the twitter icon to the right and follow me on twitter.

.Net 4.0 – Start Reading Between the Lines – Learn Silverlight and Entity Framework

Posted by Keith Elder | Posted in .Net, Asp.Net, C#, Internet, Mobile Devices, MVP10, PC Software, Smart Clients, SQL Server | Posted on 30-11-2009


I started writing this as a general recap of PDC for team members but the more I thought about what was announced at PDC, the longer the email got.  Ultimately I decided to put it out so you dear reader could also gain some insight from things announced at PDC. 

For starters listen to the podcast we recorded with Scott Guthrie or “The Gu”, or “His Guness”, or “ScottGu” about Silverlight 4 announcements among other things while at PDC. 

The big stories out of PDC that I think everyone should take note of are Silverlight 4, Entity Framework 4 and Windows Mobile. Wait Windows Mobile 7? Yes.  Wait… I didn’t hear anything about Windows Mobile 7? Well I didn’t either and that is why this post is called “read between the lines”.  Call it speculation or whatever, but I think I can bring you up to speed on what is about to happen (and no I have no official behind the scenes information, I’m just a guy with a brain).  Before we get to Windows Mobile 7, let’s start with Silverlight.


Silverlight 4 had tons of announcements including:

  • Camera and microphone support
  • Trusted out of browser support.  This means one can access COM (for example, an application could access Outlook APIs)
  • Lots of line of business app controls
  • Added support for drag and drop
  • WCF RIA Services (this is basically what I’m calling the new CSLA, if you listen to the podcast you’ll find out that Rocky worked with the team closely on RIA Services)
  • Print natively
  • More…

Tim has a great recap of all the Silverlight announcements here with links to videos:


Now what does this all mean? It means the line is blurring between client and server applications. It also means we are coming back full circle to “Smart Clients” (which were hot in 2005/2006 but were forgotten due to the Web 2.0 hype.  The only difference is this new breed of application (Silver Clients?) can run directly from a web site, or on a client’s machine.  It also means that Silverlight is going to finally fulfill the vision we heard about a long long time ago that was called WPF/e (WPF Everywhere).  A lot of people have forgotten this but we are seeing it take full shape now.  For businesses that are writing applications internally, I think we are going to start seeing a huge shift away from writing Asp.Net/MVC apps and a move towards the rich model with Silverlight.  I mean seriously, why wouldn’t you? If you get cross platform compatibility, rich data binding, write once and work in any browser, why would developers that are trying to build internal business applications continue to kill themselves writing JavaScript, fighting CSS and browser compatibility?  I can’t think of a reason either.  In my opinion this is just a waste of time (and always has been).  There is something extremely powerful putting a variable in memory and having it be there when you need it without having to worry about sessions, state, etc.  Yes we are FINALLY getting back to the client programming model, just coming at it a different way. 

Entity Framework

Let’s talk about Entity Framework 4.0 for a moment.  This is another big piece of news.  It is big because as .Net developers we will finally have one true way to access data that fits the multitude of ways we have to work.  Here’s a recap of announcements (not a complete list, watch the videos from PDC):

  • POCO – supports plain old clr objects
  • EDM designer enhancements
  • Better stored proc support
  • Model first (then gen database model)

Doug Purdy (who we also interviewed for Deep Fried Bytes while at PDC) has a list of the sessions that cover the Entity Framework 4.0.  Just start at the top and work your way down as far as you can.  At least watch the first video as it shows off all the features of EF.


With the number of features that were announced in EF4 I think we are on the verge of seeing the demise of NHibernate usage by developers in the .Net stack.  For those that have used NHibernate in the past, it is worth another look at the Entity Framework to be released in .Net 4.0.  About the only thing EF4 doesn’t do that NHibernate does do is built-in caching (which hey, there’s this caching thing that AppFabric does, hmm, wonder if they’ll use that? Why not! 🙂 ).  But the big thing to note between EF4 and NHibernate is we are starting to see where this whole modeling thing with OSLO is going (edm files are m fles and so on).  And of course there is the bigger picture of reusing this model in report services, BI and other areas (although we haven’t *seen* that really working yet, it is coming though see next sentence).  As EF4 makes it way into other products throughout the Microsoft ecosystem it is going to be extremely hard to avoid the Entity Framework.  Read between the lines, the writing is on the wall, LEARN THE ENTITY FRAMEWORK.

Just a side bar here because I know someone is going to ask me this at a later time.  Will the Entity Framework kill NHibernate? Answer: Nope I’m not saying that. 

Out of band developers that seem to have a knack for yelling the loudest will continue to use NHibernate but a much larger ecosystem will leverage the out of the box Entity Framework in .Net 4.0.  Think back for just a bit.  History is about to repeat itself all over again.  Remember when we got MSTest and or MSBuild?  Same thing is happening again. There is now an out of the box product for standardizing data access.  Are their alternatives? Sure.  Just as MSTest didn’t kill NUnit or MBUnit and MSBUILD didn’t kill NAnt, EF4 will not kill NHibernate.  However, if you look at the number of developers using MSBuild or MSTest it is high. Extremely high.  Why is that? Answer: pain, ease of use, integration, documentation.  MSTest is not the best testing framework out there (this is a proven fact), but it is good enough for 90% plus test cases.  Entity Framework 4.0 is going to put an ORM in the hands of developers.  And you know what, it doesn’t suck either. 

Windows Mobile 7

And now onto Windows Mobile 7. 

Is this WinMo 7 above?  I honestly don’t know, I found these screen shots on http://windowsphonemix.com/ web site.  BTW, notice that URL?  Mix? Yes Mix.  Mix is the first of the three major conferences Microsoft puts on each year.  The very last slide at PDC during the last keynote said, “Come to Mix 2010 for Windows Mobile 7 futures”.  A lot of people missed this because they were tuned out from the SharePoint demos and already packing to leave.  But there it was on the big screens.  Thus we know Mix is when we’ll see Windows Mobile 7.  Again, listen to the podcast to get some other insight. 

Here’s a quote:  “Three screens and the cloud”

We heard this over and over at PDC.  Let’s read between the lines a bit shall we?

I have three screens:  Windows Desktop, Web, Mobile.  Ok, if I want to write an app that will run on all three what do I as a developer have to do today?  Let’s see, well, we could write a ClickOnce deployed Smart Client for the Desktop that uses WPF.  For the web, well, we would have to switch gears completely and rewrite our app in Asp.Net or Asp.Net MVC to get that screen.  For mobile, even tougher, we have to rewrite the app again to get the mobile version.  Let’s think about this differently again.  Think about it, how many technologies would a developer have to know in order to an application for these three different screens;  WPF, JavaScript, HTML, and CSS will be used just to name a few.

Now, let’s switch gears.  What if I used Silverlight 4 to write my app?  Well, it could work in the browser no doubt.  Hmmm, it could also work on the Desktop using the out of browser experience with elevated permissions.  What about mobile? 

“Wait, didn’t you just say Keith that at Mix we’ll get to see Windows Mobile 7?”


“And hasn’t there already been talk of using Silverlight for mobile?”


“Aha! Three screens with Silverlight, I get it!”

That’s right my friendly .Net developers the writing is on the wall. The vision of WPF/e (WPF Everywhere) is about to come true.  We’ve waited for years but it is just around the corner as I predicted would happen years ago.


(ok, so it wasn’t right around the corner but 3+ years later)

Moral of the story?

LEARN SILVERLIGHT so you can make millions of dollars building Mobile applications just like the iPhone devs.  There, I just made you rich by putting this puzzle together for you, please send me 20% of all profits.

You are welcome.

Creating a REST WCF Service From an Existing XSD Schema

Posted by Keith Elder | Posted in .Net, Asp.Net, WCF, Web Services | Posted on 02-11-2008


A reader of this blog sent me an email asking the following question:

“I have an XSD that I am required to use to export my company’s data. How can I use that XSD and return data to them in a web method? I should be able to return a data set with the information formatted the way the XSD defines but I have no idea how to do that. Any ideas would save me a ton of time and grief!”

Turns out this is a really good question, and I think one a lot of developers struggle with primarily because the majority of developers are scared of XSD schemas.  Hopefully I can change that.  An XML Schema is really simple and it is your friend. 

What is an XSD or Xml Schema Definition?

An XML Schema describes the structure of an XML document.

That’s it, see, it isn’t that hard after all!

As a developer think of an XSD the same way you would when creating business rules to validate objects before storing them into a database.  Some items in objects cannot be null, some can.  Some need to have their data formatted (email address for example) and others need to not exceed certain lengths, etc. 

When dealing with an XML document, we need to apply the same type of rules and this is where the XSD comes in.  Once we have an XSD to describe an XML document we can guarantee any XML data we receive conforms to these rules.

Ok, enough intro, let’s get coding.

The Schema

In the case of the reader’s question, an XSD schema already existed.  To save time, I’ve taken then general idea of the schema I was sent and slimmed it down for simplicity sakes.  The schema represents an XML document that will contain job listings. Here is a view of the schema from the schema explorer in Visual Studio as well as the schema itself (again slimmed down).

   1: <xsd:schema
   2:   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   3:   targetNamespace="http://keithelder.net/Jobs"
   4:   xmlns:xs="http://keithelder.net/Jobs">
   6:   <xsd:complexType name="JobListing">
   7:     <xsd:sequence>
   8:       <xsd:element maxOccurs="unbounded" minOccurs="1" name="job" type="xs:Job" />
   9:     </xsd:sequence>
  10:   </xsd:complexType>
  12:   <xsd:complexType name="Job">
  13:     <xsd:sequence>
  14:       <xsd:element maxOccurs="1" minOccurs="1" name="Title"  type="xsd:string"></xsd:element>
  15:       <xsd:element maxOccurs="1" minOccurs="1" name="Description" type="xsd:string"></xsd:element>
  16:       <xsd:element maxOccurs="1" minOccurs="1" name="Location" type="xs:Address"></xsd:element>
  17:       <xsd:element minOccurs="0" maxOccurs="1" name="PostingDate" type="xsd:date"></xsd:element>
  18:       <xsd:element minOccurs="0" maxOccurs="1" name="CloseDate" type="xsd:date"></xsd:element>
  19:       <xsd:element minOccurs="0" maxOccurs="1" name="Benefits" type="xsd:string"></xsd:element>
  20:       <xsd:element maxOccurs="1" minOccurs="1" name="Salary"  type="xsd:string"></xsd:element>
  21:       <xsd:element maxOccurs="1" minOccurs="0" name="JobType" type="xs:JobType"></xsd:element>
  22:       <xsd:element minOccurs="0" maxOccurs="1" name="Function" type="xs:JobFunction"></xsd:element>
  23:       <xsd:element minOccurs="0" maxOccurs="1" name="Category" type="xs:JobCategory"></xsd:element>
  24:     </xsd:sequence>
  25:   </xsd:complexType>
  27:   <xsd:simpleType name="JobType">
  28:     <xsd:restriction base="xsd:string">
  29:       <xsd:enumeration value="full-time"></xsd:enumeration>
  30:       <xsd:enumeration value="part-time"></xsd:enumeration>
  31:       <xsd:enumeration value="contractor"></xsd:enumeration>
  32:     </xsd:restriction>
  33:   </xsd:simpleType>
  35:   <xsd:complexType name="Address">
  36:     <xsd:sequence>
  37:       <xsd:element minOccurs="0" maxOccurs="1" name="Street" type="xsd:string"></xsd:element>
  38:       <xsd:element minOccurs="0" maxOccurs="1" name="City" type="xsd:string">   </xsd:element>
  39:       <xsd:element minOccurs="0" maxOccurs="1" name="Country" type="xsd:string"></xsd:element>
  40:     </xsd:sequence>
  41:   </xsd:complexType>
  43:   <xsd:simpleType name="JobCategory">
  44:     <xsd:restriction base="xsd:string">
  45:       <xsd:enumeration value="Automotive"/>
  46:       <xsd:enumeration value="Banking"/>
  47:       <xsd:enumeration value="Construction"/>
  48:       <xsd:enumeration value="Internet"/>
  49:       <xsd:enumeration value="Retail"/>
  50:       <xsd:enumeration value="Services"/>
  51:     </xsd:restriction>
  52:   </xsd:simpleType>
  54:   <xsd:simpleType name="JobFunction">
  55:     <xsd:restriction base="xsd:string">
  56:       <xsd:enumeration value="Chief Peanut Butter Spreader"/>
  57:       <xsd:enumeration value="I ran the whole ship"/>
  58:       <xsd:enumeration value="Other"/>
  59:     </xsd:restriction>
  60:   </xsd:simpleType>
  61: </xsd:schema>


Once we have a schema defined like this we can generate code to be used for a service.  We have a tool at our disposal that is available within the Visual Studio Command Prompt called XSD.exe.  This executable does a lot of things but one thing it can do is generate code from an XML Schema Definition. 

When generating from the XSD file I was sent there was a problem with it.  Here is the walk through of that story so you can follow along. 


When I first tried this on the reader’s original XSD I got an error:

Warning: cannot generate classes because no top-level elements with complex type were found.

What does this mean?  Well, look at the screen shot of the XML Schema Explorer above.  Do you see the <> green icons?  Well those represent an XML Element.  An element is a fancy name for an XML tag like:  <Cows>Bramar</Cows> 

Let me roll this up and take another screen shot so you can start to see the problem (i have to hit my magic number of 12 screen shots anyway 🙂 ).


See the problem?  There isn’t an element in this schema (no green <> thingy).  What this means is we have a schema which just lists complex types of elements and enumerations.  There isn’t any “xml” in this schema.  The fix is simple though.  Add an element to the schema. 

   1: <xsd:element name="JobListing" type="xs:Job" />

Now we have a green thingy icon which means this XSD contains at least one element.  Basically think of the JobListing element as the root element.


Now that we have an element we can generate a C# class file from this XSD:


The code generated is about 350 lines so I’m not going to include it in the article.  There are some nice things happening for us when the C# classes are generated using xsd.exe. For starters the enumerations in the XSD are turned into C# enumerations.  The classes are marked serializable and they have the appropriate XML attributes on the properties to serialize these objects into XML.  This is a good thing since it means we didn’t have to create it.  Code generation is your friend.  Now that we have C# objects we can serialize these to XML easily. 

The Service

The first thing we need to do is create the WCF service.  For this example I chose to create a WCF Service Application in Visual Studio 2008.  After the project is initialized, the first thing we need to do is define the contract for the service.  In other words, what is coming in and going back out.  Since we have generated our code using the XSD utility we are going to use the XmlSerializer with our service.  The reason is this will make sure our XML formatted the way we intended.  While we are at it, I’ve made the service a RESTful type of service.  Here is the contract.

   1: [ServiceContract]
   2: public interface IJobService
   3: {
   5:     [OperationContract]
   6:     [XmlSerializerFormat]
   7:     [System.ServiceModel.Web.WebGet(UriTemplate="/jobs/{type}", RequestFormat=WebMessageFormat.Xml)]
   8:     List<Job> GetJobListings(string type);
   9: }

The contract above has one method GetJobListings().  This method has two additional attributes.  One, the attribute to mark the method to serialize using the XmlSerializer and two the attribute to turn the method into a RESTful service.  In other words our service can be accessed like this:


Now that the contract is setup, we just need a class to implement this contract on.  Here’s a quick and dirty implementation.

   1: public class Service1 : IJobService
   2: {
   4:     #region IJobService Members
   6:     public List<Job> GetJobListings(string type)
   7:     {
   8:         return GetJobs();
   9:     }
  11:     private static List<Job> GetJobs()
  12:     {
  13:         var jobs = new List<Job>();
  14:         jobs.Add(new Job { JobType= JobType.parttime, Category = JobCategory.Banking, Benefits= "You are on your own.", Description="I did something" });
  15:         jobs.Add(new Job { JobType= JobType.fulltime, Category = JobCategory.Banking, Benefits= "You get something." });
  16:         jobs.Add(new Job { JobType= JobType.contractor, Category = JobCategory.Banking, Benefits= "Times are tuff, deal with it." });
  17:         jobs.Add(new Job { JobType= JobType.fulltime, Category = JobCategory.Banking, Benefits= "How does $700 billion sound?" });
  18:         return jobs;
  19:     }
  20:     #endregion
  21: }

Now all we have left is to get this working is to configure WCF to support our RESTful implementation.  In order to do this we are going to use the webHttpBinding.  Here is the WCF configuration to implement our RESTful service.

   1: <system.serviceModel>
   2:   <bindings>
   3:     <webHttpBinding>
   4:       <binding name="rest" />
   5:     </webHttpBinding>
   6:   </bindings>
   7:   <services>
   8:     <service behaviorConfiguration="WcfService1.Service1Behavior"
   9:      name="WcfService1.Service1">
  10:       <endpoint address="mex" binding="mexHttpBinding" name="wsdl"
  11:        contract="IMetadataExchange" />
  12:       <endpoint address="" behaviorConfiguration="NewBehavior" binding="webHttpBinding"
  13:        bindingConfiguration="" name="web" contract="WcfService1.IJobService" />
  14:     </service>
  15:   </services>
  16:   <behaviors>
  17:     <endpointBehaviors>
  18:       <behavior name="NewBehavior">
  19:         <webHttp />
  20:       </behavior>
  21:     </endpointBehaviors>
  22:     <serviceBehaviors>
  23:       <behavior name="WcfService1.Service1Behavior">
  24:         <serviceMetadata httpGetEnabled="true" />
  25:         <serviceDebug includeExceptionDetailInFaults="false" />
  26:       </behavior>
  27:     </serviceBehaviors>
  28:   </behaviors>
  29: </system.serviceModel>

That’s it, we are all setup.  Now all we have to do is launch the service and browse to the URL we outlined earlier to get our results.


This may seem like a lot of steps but it really isn’t.  I encourage you to take this example and play with it.  You can download the solution below.

Download Solution WcfService.zip

Dear Joe: I’m NORM.Net

Posted by Keith Elder | Posted in Asp.Net | Posted on 29-08-2008


I love a good discussion even if blogs, comments, and track backs are an extremely poor way to have one.  Joe Brinkman, someone I have known face to face for several years, and someone I respect, read my previous article about my call to arms aimed at developers not spending enough time making their sites work across browsers who are using Asp.Net.   He responded with a post referencing the Alt.Net movement.  My article has a lot of truth in it and some good points but at the end of the article I gave a recommendation for developers to consider using Asp.Net MVC.  It is this that seems to have spurred not only Joe on but several other people as well.  So for Joe and several others that responded, seemingly turning the discussion into MVC vs Webforms (which was not the intent), here you go.

I want to start with Joe’s reference which he heavily eluded to the fact that I’m a part of the Alt.Net movement.  First and foremost let’s be clear that I do not lump myself into the Alt.Net movement.  With that said I don’t publicly disassociate myself with Alt.Net either.  I pretty much stand in the middle I think.  Standing in the middle is something I like to call NORM.Net.  I want to start there because the tone of Joe’s post seemed to lump me into the throws of a movement whereby he read my article thinking I was involved with said movement and coming at it from that angle.  This is not the case.  I’m just a normal guy trying to write code and solve problems and peaking around the corner to see if there is something else out there.  I’m not sure what that makes me but when I wake up in the morning I feel like a normal developer with average skills trying to do an outstanding job for my employer with what God gave me to work with.

Joe did make some great points and he was dead on about developers having to care.  This basically sums up the first two things I said which I’ll get to in a second.  It is funny he mentioned the drag and drop scenario because I’ve spent hours arguing that it has a place.  Obviously that stance wasn’t popular with who I was arguing it with but again I’m NORM.Net.  Like Joe I’ve also argued that Webforms and drag and drop can be made to be compliant and yes the onus is on the developer to make it compliant.  Here is the thing though.  If Webforms is the only thing a developer has to work with, he/she certainly has to care more and work harder to make it compliant. 

Secondly let me clear this up.  I gave “recommendations” not “solutions”.  I gave my recommendations based on something someone that cares about standards and cross platform ability can use once they buy into my first two points.  The first two points of my recommendation were simple:

1.  Care more about web standards
2.  Do extensive testing on more than just IE, test across more platforms

If a developer does those two things, and those two things alone I wouldn’t have had three scenarios to point to that forced me to use Internet Explorer.  That’s how the problem is solved folks.  Make no bones about it.

If the developer is doing those two basic things, caring and testing, here is what I think will happen.   I think they will eventually come to the realization that Webforms is much harder to do this with.  It is for this reason I threw out the MVC recommendation.  This is the same conclusion that countless developers that have investigated Asp.Net Webforms that are experts in other technologies have come to the conclusion of as well so this is nothing new.  Ask any ruby dev or php dev or insert dev here what their experience with Webforms was and they’ll say without waiver that it was painful.  I’ve felt that pain before as well and thus if there is something better out there that solves for the problem use it.  See?  It is about using the right tool for the job.

Therefore, instead of using Webforms and working around some of the challenges it brings to the table (which doesn’t mean you can’t, it boils down to ones pain thresh hold) my recommendation is to use MVC for “public facing web sites”.  Meaning if someone asks me what they should use for a public facing web site, from me, they will always get the answer of Asp.Net MVC, at least to start with.    Does that mean MVC is the one single end all be all answer forever?  No.  It is a starting point and as part of the NORM.Net movement I reserve the right to look at their situation and recommend something else if another tool would serve the situation better. 

Now I use the words “public facing web sites” in quotes to highlight the fact that this requirement must be part of the conversation.  If someone asks me about building an internal application for their Intranet, they will get a different answer because for internal applications there is typically a standard set to support one browser and RAD plays a much bigger role.  Again, use the right tool for the right job.

At the end of the day, all I’m saying is for Asp.Net developers to 1) care and 2) test and 3) use the right tool for the right job.  I think that is a pretty level headed approach.  We can argue MVC vs Webforms all day long but honestly I really don’t care.  Seriously, I really don’t care what someone uses as long as I and others are not forced to open another browser to get to a web site.  This is what spurred this whole thing on.  It isn’t about tools and I’m even sorry for throwing the MVC recommendation into my previous post because it has distracted so much from the problem. 

With that said, I will say this.  I don’t care what my neighbor uses to mow his yard.  If he chooses to mow his yard with a push mower and it takes him 4 hours to do so I don’t care.  All I care about is he mows his yard, the end result.  When I first bought the house we live in now I mowed our 1.5 acres with a push mower.  It took 7 hours to get to the end result of a mowed yard.  After mowing the yard twice, I replaced that tool (the push mower) with another one (48inch riding mower) and now the end result takes 1 hour.  Feel free to apply that story to this conversation however you want.  I’ll let you, the reader, decide where it goes.

NORM.Net President and Founder
Keith Elder

PS – for those that don’t know my sense of humor, no I’m not starting another .Net movement

Dear Asp.Net Developers: Stop Making Our Technology Look Bad

Posted by Keith Elder | Posted in Asp.Net | Posted on 28-08-2008


I run Firefox pretty much all the time.  I like the plug ins and other features it has but there are times when I am forced, yes forced to open Internet Explorer.  That pretty much ruins my whole day to have to start another browser to do something.  It isn’t that I despise IE, if the opposite were true and I was running IE and had to open Firefox to do something well that would ruin my day.  Before you IE / MSFT haters jump in let me just say that no matter which operating system I have used over the years I can’t remember a single time that I was able to use one browser 100% of the time without fail.  This problem can be fixed though, and it starts with Asp.Net developers.

Like I said, no matter which operating system I’ve run over the years I have never been able to use one browser 100% of the time.  There was always something that I needed to do that forced me to use another browser, even on a different operating system sometimes.  For example, when I was using my Mac with OSX I liked to run Safari.  I quickly found out though that Safari didn’t work on this site or that site and I was forced to open Firefox (which back then wasn’t as great of a story as it is now). 

What Do All of These Sites Have in Common?

Recently I ran into some issues that drove me to right this article.  There are three scenarios I ran into that I want to discuss.

Scenario One – I need to do what to read HTML?

The other day I was trying to do real work and went to a web site using Firefox.  I wanted to simply read some FAQs (frequently asked questions) on a web site.  For whatever reason, the Asp.Net developer that wrote the site made the site in such a way that it would not work with Firefox.  I kept clicking on a + sign which indicated there were answers and questions below this navigational menu.  Nothing was happening though.  I then reluctantly started Internet Explorer.  I copied the URL I was on and pasted it into IE’s toolbar.  As soon as I hit the site I was prompted to install an ActiveX control.  You read that correctly!  This public facing web site in the year 2008 had me install an ActiveX control just to get some plain HTML text that I needed.  My jaw hit the floor. 

Scenario Two – It’s just JavaScript!

A few days later I was on another site and clicked on some JavaScript clicky thingy within Firefox and nothing happened.  I HAD to get to this information and I finally gave up.  I opened Internet Explorer to get to the information I needed.  That of course meant I had to re-authenticate and go through eight pages of navigation to find what I was looking for in the first place.

Scenario Three – It is suppose to look like what?

A few hours later I was cooking along with Firefox thinking I had squashed the Internet gremlins for the day and that I’d be able to use my beloved Firefox browser without incident.  I started going through my email queue processing items I needed to get done.  One of the items on my list was to register our user group on CodeZone.  CodeZone is a community site that is supposed to help user group leaders with their user groups.  I pulled up the site and saw this:


Yes, it looks horrible but I tried to put up with the crazy un-zen-like-css-badness and navigate my way around.  And then it happened, I couldn’t take it any longer because I couldn’t find anything I was looking for so I opened up Internet Explorer.  When I went to the site I saw this:


Wow.  Just wow.  I’m ok with a few CSS things being out of line on a site, but this is just blatant not giving a crap.  It was at this point that I started writing this article. 

Survey Says…..!

The question I proposed at the start of the above section was what do these web sites have in common.  The answer is they are ALL Asp.Net web sites.  Now I know some of you that are web developers do not hold Internet Explorer in high regards due to the lack of standards it supports.  Believe me, I have felt that pain before as well.  But this is the opposite case whereby Internet Explorer is working and Firefox doesn’t work!  This my friends has to stop. 

This is one of those elephants in the room that gives developers in other communities ammunition against the Asp.Net platform.  The thing is, it isn’t good ammunition, nor factual, but it certainly sends the wrong message about our platform.  If you are an Asp.Net developer developing a public facing web site, look at the message this is sending to those not in the Asp.Net community.  Just think about the damage this is doing for the platform.  For starters, sites like these send the message that Asp.Net web sites ONLY work with Internet Explorer.  In other words those developers think that sites written with Asp.Net require Internet Explorer to function.  Then they think this is a problem with the platform and thus it must be flawed, proprietary and locks someone into the Microsoft platform from all angles.  This couldn’t be further from the truth but that’s what people think, especially those that are on the outside looking in.  When someone is considering Asp.Net these are the instances they remember in the back of their mind.  If a new platform is investigated, Asp.Net is viewed as already being behind. 

Again this isn’t the fault of the platform, it is the fault of the developer(s) and it is these cases that make our platform and choice of technology look extremely bad.  There are tons of web sites out there that are built with Asp.Net that work in any browser.  The only difference between the site that doesn’t and the one that does is the developer didn’t make it a priority or made bad decisions along the way.  There are web sites written in Asp.Net that adhere to standards and work across different operating systems and browsers.  This blog is currently running SubText and it is an example of an actively developed system in Asp.Net that doesn’t have this problem.  Even non open source products like GraffitiCMS which Deep Fried Bytes uses is an interesting case study.  It is interesting because it does URL rewriting thus pages do not end in .aspx and the HTML is 100% standards compliant.  This makes it interesting because I have personally had numerous people ask me what we are running on that site.  Funny enough, most people think we are using PHP.  There is no way for them to know what we are running and I think that strikes at the heart of the problem with the perception of the Asp.Net platform.  People think all pages must end in .aspx and there is no way to build a site with Asp.Net that is standards compliant.  For those of us that know the platform, we know this is just not the case.  Yet, there are endless examples for people to point to that are bad. 

The other message web sites that only work in Internet Explorer send to the community is Asp.Net developers could care less about standards and testability outside of Internet Explorer.  I know for a fact there are a lot of Asp.Net developers that care about standards.  They do a great job making sure their web site is built in that way.  With that said, this reminds me of the saying “It only takes one bad apple to spoil the rest”.  Let me give you a scenario.  Let’s say there is a web site that works for 99 out of 100 people.  The one person it doesn’t work for is running Linux or a Mac.  By the mere fact the site doesn’t look correct on their platform or the fact they are forced to load something like an ActiveX control which there is NO WAY they can load, that one person is going to tell everyone else about their problem.  As a matter of fact that individual tends to be more vocal than the other 99.  It is just a fact of life that we never hear about good things, always the bad (just watch the 5:00 news). 

My Recommendations

I’ve talked a lot about the problem and the impact it can have.  Now I want to talk about some things Asp.Net developers can do to make this better.  For starters Asp.Net developers need to care more about standards and work to test their web sites across all platforms.  Doing those two things will force someone to think twice about how a user running OSX and Safari will use an ActiveX control for example. 

Beyond those two basic requirements there are a few other things I’ll recommend.  Today the ball game has changed in regards to Asp.Net.  This is a good thing.  In particular there are more options that developers can use instead of rolling their own.  There are also other options that don’t rely on ViewState and out of the box controls that provide Asp.Net developers more flexibility.  Here’s my advice for Asp.Net developers, let me just get it out of the way now.

If you are building a public facing web site in Asp.Net you should be using Asp.Net MVC.

This is my default answer for anyone building a public facing web site in Asp.Net.  As a long time PHP developer I know the benefits of using the MVC pattern inside and out.  While it doesn’t work for every single scenario out there (portals for example), it is what I suggest developers start with when building any Asp.Net web site.  The thing is, it isn’t that hard either.  The page life cycle is extremely simplified and there are guidelines as to where you put things (this is a good thing in my opinion).  In Asp.Net MVC the developer puts this here, that there, names it this or that and badda bing, they have a page that allows them to create whatever they want within their template.  As a matter of fact the way Asp.Net MVC works is very similar to the PHP framework I helped build and used years ago.

Once a developer gets going with Asp.Net MVC they’ll start to realize that similar to PHP and other scripting foo languages where HTML and code are mixed they wind up with something Jeff Atwood calls Tag Soup.  To combat tag soup in templates my default answer is bake in a better template engine.  My default answer for this is NVelocity.  I mentioned GraffitiCMS above and this is what Graffiti uses to do templates.  To understand how powerful this is here is a sample.  I invite you to visit our contact us page on our podcast.  Here’s the URL:  http://deepfriedbytes.com/contact/.

What do you think the template for that page looks like?  I can’t begin to express how simple that page template is behind the site.  Here’s the actual HTML template for that page:

   1: <div class="article">
   2:   <h1 class="title">$post.Title</h1>
   3:   <div class="body">
   4:         $post.Body
   5: <h2>Send us a Question</h2>
   6: $macros.ContactForm()
   8:   </div>
   9: </div>

It almost immediately reminds me of PHP templates and I suddenly start to feel warm and fuzzy inside.  NVelocity is a an open source project that was born from YAP (yet another project) called Velocity

Here’s the question though.  Do these recommendations fix the problems of the three sites I mentioned above?  That is debatable even in my own mind.  At the end of the day, I nor anyone else can stop what a developer does in their code.  That is just a fact.  What these recommendations do is give developers using Asp.Net an absolute way to care about what they are sending down the pipe to their client’s browsers.  They are now 100% in control of what gets sent down the pipe to their clients.  It is the ability to control the output that is extremely important, especially when building public facing web sites.

What else can Asp.Net developers do?  For starters they must NEVER assume.  They must NEVER assume their users are just windows users running Internet Explorer.  Even Microsoft properties are guilty of this and yet again I say, this must stop.  Long gone should be the days of basic site features not working on all browsers in all major operating systems.  I know it is easy to say this and hard to do but the web is what it is.  If you’ve chosen to build web sites then you’ll just have to deal with this rusty washer. 

I wrote this article because I really like our platform.  I have lived the open source / iLife (play on words for the years I used a Mac) for many years and I know how these camps think.  I also have had a lot of conversations with developers in these camps.  More times than not I have to do what I call “Myth Busting” because of what they’ve seen on the Internet in regards to public facing web sites using Asp.Net.  I can’t stress this enough.  It is important that each and every site built with our platform is a shining example of developers doing it right.  In other words, before you build that public web site and embed that ActiveX control stop and think.  Do you really want to make the rest of us look bad?  Do you really want to give that one person out of one hundred the ammunition they need to spoil the masses?  Did you do your diligence to test your web site on multiple platforms and multiple browsers in multiple resolutions?  Moving forward I hope you do.

UPDATE: There is a follow up response posted here.  This is why comments are now closed:


Like this article? kick it on DotNetKicks.com

Deep Fried Bytes Episode 10: A Practical Look at Silverlight Part 2

Posted by Keith Elder | Posted in Asp.Net, Podcast | Posted on 18-08-2008


Can you believe we made it to Episode 10!?  It is such a nice round number isn’t it?  If you think about it, technically we only have two more episodes than Michael Phelps has gold medals.  Episode 10 is part two of our Silverlight discussion with Shawn Wildermuth.  Honestly, I think this episode is the best of the two, mainly because we have a “rusty washers” segment in it that really runs Silverlight through its paces. 

In this episode we welcome a new sponsor to the show, DevExpress, the makers of Coderush and Refactor Pro among a ton of other things.  Just a little FYI, they have a grid specifically for Silverlight that comes with the source code.  Check it out.

What interesting facts will you learn in this episode?  Let’s see.  You’ll probably learn that I have a riding lawn mower and have to mow way too much grass.  You’ll also learn that Woody would get the gold medal for the tallest grass in his neighborhood along with some great guidance about how Silverlight should be used.

Listen to the show


Ways To Listen To The Show

There are several ways to listen to Deep Fried Bytes.

1. Directly From The Web Site (or click the link above)

When you visit the site look for this:

Clicking the triangle will launch the Yahoo! media player and automatically start playing the show for you. As long as you leave the browser window open the player will stay open. Clicking off the page WILL stop the player!

2. Subscribe via iTunes and Zune

If you have iTunes or Zune installed on your computer you can subscribe to our show. In iTunes open the Music Store and search for “Deep Fried Bytes”. In the Zune software, go to the MarketPlace select Podcast and search for “Deep Fried Bytes” to subscribe to the show. You can also click either of the two icons below to automatically subscribe to the show if you have iTunes or Zune installed.

Subscribe via iTunes Store Subcribe via Zune Market Place

3. Subscribe to RSS Feed

To stay current and up to date with the show, subscribe to the site’s RSS Feed. If you don’t know about RSS feeds you can read more here: http://en.wikipedia.org/wiki/RSS_(file_format)

If you already have an RSS reader installed and setup, click the feed icon below to grab our news feed.

Subscribe to our podcast!