Introduction to the ASP.NET Web API

If you are interested in learning about the new HttpServer and HttpClient types – and how the HttpMessageHandler glues it all together please sign up!

Make sure to go to the YouTube HTML5 page to turn on HTML5 video and turn off that horrible Flash

One of the perks of working at Pluralsight is getting to watch all the other great content put together by the other authors

Of course I prefer watching them streamed to my 32 inch LCD from my iPad through my AppleTV

A subscriber on Twitter questioned the title He thought it should have the term “Hybrid” in the title.  After doing some google research – I decided he was correct – it is clear that from a “marketing” point-of-view a native app that uses HTML5 through a native component (UIWebView in the case of iOS, WebView in the case of Android, and the WebBrowser control in the case of Windows Phone 7) are commonly called “Hybrid” apps.  So we changed the title of the course

From a technical point-of-view I find the term to be slightly misleading.  Here is my definition of a “native” mobile application:  A mobile application that can be deployed to the mobile device’s AppStore/Marketplace.

Delineating an app on any other technical basis I think confuses the issue more than clarifies it.

Here is another way I think about it – with Windows 8 moving to Metro apps that can be built in HTML5/JavaScript – are those apps going to be “Hybrid” Metro apps?   I think not.

http://www.pluralsight-training.net/microsoft/Courses/TableOfContents?courseName=native-mobile-apps-with-html5

If you want to try it out you can start a 10-day Free Trial – https://www.pluralsight-training.net/microsoft/Subscribe/Step1?isTrial=True

In this course I cover the three “major” mobile platforms and how to build a native application on each of the platforms while re-using much of your UI and business layers by writing them in HTML5 and JavaScript.

I also cover responsive web design (media queries) and how that applies to mobile HTML5 development.

I also cover cool things like enabling the web inspector in the UIWebView by using the _enableRemoteInspector call.

So please check it out

A number of people (including Shawn Wildermuth) have been writing and speculating about the Build conference. I’m about to pack to drive down to Anaheim and wanted to document in the blogosphere my hopes about what will be announced there.

I actually hope that .NET on the client is dead. Well not dead – but IMO .NET has had a good run and it’s time to let go. When I say .NET on the client I mean WinForms, Silverlight, WPF, all of it.

You might ask why someone who has spent 10+ years working on the platform would say that – and my answer is HTML5.

People often think of me as the BizTalk/WF/WCF guy, or the REST guy. But before I was into either of those things I was actually a pure web developer. HTML, JavaScript, ASP, and then ASP.NET.

In essence I feel like I am going back to my roots these days (come see me talk about HTML5 and mobile app development at VSLive this fall, for example).

That’s why as of today this site is now renamed www.masteringhtml5.com – I’m going back to my roots.

My hope is that Microsoft sticks with its first announcement about Windows 8 and that new “immersive” apps or whatever they are going to be called *have* to be built using HTML5 and JavaScript. Not only do I hope that because I’m happy to be going back to my “roots”, but I think it is the smartest thing to keep the Windows platform relevant.

I’ll have more to come on this topic as the week progresses.

After I updated to the most recent version of the Windows Azure Tools for Visual Studio I started to get this error:

"windows azure web role entry point has stopped working"

If I debugged the project I got

System.ServiceModel.CommunicationObjectFaultedException was unhandled
  Message=The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state.
  Source=mscorlib
  StackTrace:
    Server stack trace:
       at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout)
    Exception rethrown at [0]:
       at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
       at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
       at System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout)
       at System.ServiceModel.ClientBase`1.System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout)
       at Microsoft.WindowsAzure.Hosts.WaIISHost.Program.Main(String[] args)
  InnerException:

Either way I was forced to shutdown Visual Studio and reopen it to get the project to deploy to the local dev fabric again.

Of course I turned off the “Just My Code” debugging setting and set the debugger to break on all exceptions and low and behold I got the real exception:

The problem is that the web.config is marked as read-only because it is checked into source control.

Moral of this story – if you are developing with Windows Azure and using source control – you always have to keep your web.config checked out.  Not sure if a fix is coming from MS – but I thought this might be helpful to someone out there.

If you came to my session on Workflow and SharePoint – here are my

demos (383.72 KB) and slides (1.51 MB)

MEFDemo.zip (78.36 KB)

BTW – the problem I had with the bi-directional Import/Export was that I was calling SatisfyImportsOnce – not ComposeParts.  SIO of course only satisfies the imports on  the object in question – so this makes sense