MobilePipes grows up!

The MobilePipes team works hard on our product suite making sure that our customers are buying software that is top notch, bright and shiny, reliable, easy to use, stands the test of time, and, well you get the point!  We could assure all day long that our products meet this criteria but we took the extra steps to prove it. 

MobilePipes was officially certified by Microsoft this month as a certified product.  This means a lot for our marketing and sales material because we get to include the logo all over the place, but more importantly, it assures our customers that they are buying a quality product. 

For those familiar with the process we ensured that our code meets the Microsoft standard for .NET based Web Services, Managed Code, and Windows Server 2008 Hyper-V. 

Anyone that has ever consumed Interop assemblies from managed code has experienced some of the headaches with the old ways of coding Microsoft solutions.  Some of those bigger issues are dealing with DLL hell and having to deploy and rely on those exact assembly versions availability on the target system.  Add into the  equation many different target environments and you have a real mess on your hands.  The CLR team has added lots of great new features into .NET 4.0, one of those features is embedding Interop Types in your .net projects.  And ... it's really easy to do!

First lets paint a bit of a scenario.  You are working with a solution that must work with the Excel Interop classes.  You must first start by adding the assemblies as a reference into your project.  Now you code away and finish your solution.  Once you deploy you realize that two of your systems don't have the assemblies installed at all, a third has different versions of the assemblies, and the final system is happy.  1 out of 4 is pretty bad and I am sure your users will have the same reaction!  You could deploy those Interop assemblies along with your application but that is a bit messy as well given different deployment models and potential DCOM issues.

With Embedded Interop Types you can include your interfaces and functionality required for those Interop assemblies by simply checking off the embed on that assembly reference.  The following screen shot demonstrates.

Now, if you load up that application, and look at the loaded assemblies, you will find that no Interop assemblies are loaded and you are working completely within your managed code.  No need to rely on those target assemblies on the system.  You can read more at: Type Equivalence and Embedded Interop Types

{ Happy Coding }

If you read this blog, one recurring theme is clear for the reader, we love our development tools here at Syndicated Methods!  Javascript has come a long way in recent years, but I would argue that one place it falls short is in the Integrated Development Environment arena.   Yes, I know that Firefox has the Firebug extension, but for me that is more of a debugging environment.  I would much rather that that my IDE incorporates debugging and code quality tools at design time. 

Thanks to Douglas Crockford, we now have a Code Quality tool that targets all that bad Javascript that is out there.  Please read more on his website at www.jslint.com.  But, that only gets us about half way there.  I really want to know when something is wrong while I am writing code.  There is a solution for all of you .net developers.  CodePlex has a project available under the name of JSLint.VS.  Using this Visual Studio add in developers will get code quality feedback on their Javascript at compile time (sorry, no background compiler). 

{ Happy Coding }

** UPDATE [3/6/2009] - Note to self. use a product before you blog about it :).  JSLint itself is a useful tool.  After using it for about a day though I am finding that it is quite brutal on particular syntax.  Specifically around some of the requirements around global variables.  Furthermore, JSlint has major issues with the JQuery framework including the custom code that you write using JQuery.  This makes JSLint a bit of a useless feature for me as most of the Javascript code that I intend to write will be in a framework such as JQuery.  JSLint.vs is also a bit buggy and I started to experience major slow downs with my build.  This will kill my Continuous Integration process, always strive for fast builds, always!  I also didn't like some of the features whrere it adds reminders to fix things into your task list.  I would much rather these be treated as a warning or error much like the legacy compiler in VS.NET.  If anyone has better luck or thinks I am crazy feel free to comment.

After writing my recent post for Consuming Cross Domain Services using jQuery, I started investigating how we could leverage the power of ajax with our flagship product for mobile solutions, MobilePipes.

The service layer for MobilePipes is written in the .NET platform using WCF. Right away I realized that we are missing support for JSON serialization. MobilePipes currently supports SOAP and POX formatting through WCF service configurations. Microsoft did a fantastic job with WCF with separating configuration from implementation so I knew that getting JSON formats in place should be a snap. One of the ways to achieve this is to define a different interface for the different services that we want to expose. SOAP formatting is a the standard Service Contract that by default is configured when you use the tools in Visual Studio.

Other formats get a bit tricky because you need to define certain attributes that instruct WCF how to behave at runtime. For instance, POX services are configured with the following configuration:

That's it! Simple as that.  This configuration tells WCF to return a string from this method in the HTTP GET request. In other words, it skips SOAP formatting and just returns the string ... in the case of POX it's simply XML.  Which gets me back to JSON. In order to get MobilePipes up to speed, we have created a new Service Interface with the JSON format.  All we need to to is add the format that we want returned like so:

Now any clients that choose to use JSON rather than a traditional XML format can just point to the correct Service Endpoint. All of these endpoints are encapsulated in their own assembly and call out into the domain library. All of this allows us to keep our domain library for MobilePipes completely separate while providing SOAP, XML, and JSON return formats.  With the recent serivce endpoint for JSON, any ajax libraries can now seamlessy call MobilePipes services.

Microsoft has made the life of a .net developer trying to stay current extremely arduous!  Don't get me wrong, I am extremely happy that Microsoft has succeeded in expanding and adding great features to the .NET framework.  This is where short and concise literature on the vast subjects of .net become so important.  

I completed the "Essential Windows Presentation Foundation" by Chris Anderson, and I thank Chris for writing a book that fits this profile to a T.  Essential WPF gives you more than a brief overview but not so much content that you are reading a manual.  Chris is one of the Architect's of WPF and demonstrates his knowledge of the technology, and some history of the GUI for that matter, presented in a way that developers soak in.

WPF is groundbreaking and very different.  You win forms folks that have been waiting for the overhaul that ASP.NET gave to ASP will most certainly appreciate some of the changes in WPF.  Check it out, and I definitely recommend Essential WPF.