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.

I was recently listening to a TWIT podcast that was discussing changes in technology over the past 10 years or so.  One area of innovation struck especially close to home for me ... Virtualization.  Virtualized environments have completely changed how I think about hosting development environments. Virtualization allows you to host multiple different environments on the same physical machines.  Depending on your hosting hardware you are going to use either VMWARE or Microsoft's Virtual PC / Virtual Server.

My role in Syndicated Methods requires lots of time researching new technologies.  Additionally, we have many developers that need to work on our solutions.  Virtualization has answered two major problems that have proved challenging to support these needs:

1) Minimizing hardware to support iPhone, ASP.NET, WAMP, and LAMP environments.  We can now have one or two machines that host all of these different development machines.

2) More importantly we don't waste time setting new developers up.  With a local running configuration of VMWARE, developers only need to copy a file over and they have everything they need to start coding. 

We run windows based servers in our local network.  With virtualization one of the things that has always troubled me is that CPU and RAM have gobbled up by a baseline Windows Server install.  The Windows Shell takes up a lot of resources to run services.  These are precious resources that essentially sit idle for a machine that is intended entirely for hosting virtualized environments.  Obviously other customers felt this way because Microsoft released Windows Server 2008 Core.  This special operating system is a Windows 2008 Server without the Windows Shell.  With the lightest foot print possible to host Windows, you can now install your Virtualization engine on top of 2008 Core and have more access to raw resources.  The Tech Republic Blogs have an excellent tutorial that walks you through the installed with Windows Virtual Server 2008.

Like most software developers, I prefer to keep my nose buried in lines of code.  Writing algorithms, patterns, and coming up with creative solutions to domain issues is where I prefer to spend my time.  The reality though is that at some point in time, we all need to hoist some manual labor in parts of the code that we really prefer not to.  One area that I can firmly admit to having a love hate relationship with is html and the overall design process. 

Not because I think that it's beneath me, it couldn't be more the opposite.   It has more to do with browser compatibility.  The mentality of an html / css developer must be a forgiving one, a trait that I can't say that I share ... especially when it comes to technology.  I cannot fathom why browsers handle HTML and CSS differently.  The equivalent for software developers is like telling them that they must embed conditional statements to handle varying compilers in Windows XP, Server 2003, Server 2008, etc.  Imagine what that code would look like ...  After all, HTML is a standard, and I feel strongly that there is a solution in which browsers can process that HTML with equal respect.

I digress, because this post is not a complaint, but rather a solution for this pesky problem!  Allow me to introduce Adobe Browserlabs (thanks Coach).  Adobe has published a service that allows developers to pass a URL for inspection into the Browserlab engine.  The engine will take that URL and process a GET request for the URL to each of the browsers you specify.  From there you may examine how your application looks in a bouquet of browsers.  Browserlabs can be found at the following URL: https://browserlab.adobe.com.  The following image should explain everything

This is by no means a solution to the problem, but more a tool that allows you to do your job faster.  As any good developer knows, you are only as good as your tools!

{  Happy Coding  }

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.

One of the most exciting things for me about taking a position at Syndicated Methods is that I get to play!  Over the past 5 years or so I took a slight detour from building web applications.  During that period I was building SOA applications for financial services   Needless to say, I have been brushing up on a lot of the cool things that have been going on in the world of web since I was on hiatus.  One of the coolest things that I think have happened to the web is with the advancements of libraries on the client.  

Not so long ago if anyone said "That part was coded in JavaScript", you would literally see developers run.  Not that JavaScript is a bad technology to use, but primarily because of cross browser complexity.  Thanks to JQuery this phenomena has been corrected.  

Going back to SOA for a minute.  Something that I have come to realize about software is that no good code lives in a vacuum.  Code needs to be distributed ... enter services.  Traditionally, JavaScript prevented you from making calls cross domain.  If your application needed to call out to a web service in a different domain, it just was not possible without creating kludges (yes, iframes and proxies are kludges).  

When I saw that jQuery created the  jQuery .getJSON method I was ecstatic.  I will let their documentation give the official description at http://api.jquery.com/jQuery.getJSON/, but , in general this method allows you to perform a GET request to a target web resource in another domain.  This allows for complete support of consuming SOA services using the jQuery library.

Happy Coding!

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.  

It is about 1:48 here in Boston, and I am writing my first post to the Syndicated Methods blog!  I recently started with Syndicated Methods to help out with a lot of the technology needs of the organization.  Adding the ability for our developers to fling our thoughts about development into cyber space is a must, hence, welcome to the SyndicatedBlogs. 

I plan on updating this with all the cool and trendy stuff that we do here at Syndicated Methods.  You will also find whatever rant, praise, or rambling thoughts I might have on a given day.  I promise to keep them related to development ... well ... yeah I promise :). 

Hope you enjoy, and stay tuned ...