Visual Studio LIVE! Orlando Day 2

Today is when we get into the meat and potatoes of the conference as the keynotes and session tracks begin. Today Andrew Burst was doing an introduction and stated as I had presumed that this is the biggest Orlando conference in years. There are (4) tracks, Visual Studio LIVE!, SQL Server LIVE!, SharePoint LIVE!, and Cloud & Virtualization LIVE!. There are so many good sessions across the separate tracks, but I'm focused on the Visual Studio LIVE! content.

Visual Studio LIVE! Keynote: Application Lifecycle Management: It's a Team Sport
Brian Keller, Principal Technical Evangelist, Microsoft

If memory serves me correct, I've heard Brian speak before and enjoy his presentations. This keynote focused on some of the new features of VS.NET 2012 and specifically the functionality and enhancements to Team Foundation Server.

TFS is a beautiful and now maturing product that makes one forget the days of SourceSafe quickly. In fact the (2) don't even belong in the same room. Unfortunately to date, the SS trail left such a bad taste in the communities mouth that I find people don't give TFS the look it deserves. Although based on the feedback from the room of the features included, it seems to have a heavy following. 

TFS has a focus on developer productivity, continuous integration, and agile methodologies. Things like the 'My Work' queue in Team Explorer provide a nice workflow for open items. Having the ability to submit a shelvset and request a 'Code Review' is a nice feature. The ability to audit reviews to show they happened could be beneficial as well. The 'diff' tool has some updates (apparently has not been modified since 95' according to Brian) and displays differences in files directly in VS.NET.

The workflow offered in TFS is so robust that odds are there can be some overlapping with existing external workflow engines you may be using. I know in my experience having 'open tasks' within TFS could be a repeat of a change request logged in an external system. The distinction comes in that I think you bring the work list items in TFS down a level and more specific on what to do (i.e. modify class 'x' to do 'y') as opposed to a higher level change request (i.e. Add functionality 'z').

The best part about TFS is it's seamless integration directly into VS.NET. Being the flagship product from Microsoft for supporting source control, project management, and overall SDLC support, it's second to none in terms of VS.NET support. The real hurdle with TFS is it is a massive piece of technology. It's so difficult to keep up on all the development and related technologies required to keep current, and yet adopt a new platform like TFS. While it warrants the look, it is probably best to have a small team or consultant firm assist if ever moving over to TFS.

Local workspaces were added so that when working offline files are no longer just made read-only. The local workspace allows the developer to continue working offline and push updates to the server once back online via 'Included' or 'Excluded' changes.

The following were the (3) coolest features presented. 1st was 'Coded UI Tests'. This best I can describe reminds me of how automation macros worked in Office. Essentially you can set up a coded UI test that will take control of the mouse and keyboard to simulate a user interacting with the UI of the site using a designed test. AWESOME! Actually I've seen this before but never used it, as there are 3rd party companies that make tools for sale like this. Regardless this definitely has potential.

Next was a new feature called 'Code Clone'. How many times do we wish to go back in the code and refactor repetitive methods? This utility within VS.NET 2012 will search the solution to fins similar blocks of code to suggest refactoring. Score!

Lastly, Intellitrace. This has been around since VS.NET 2010 and something I would really like to get into. It provides the ability to output files consumable within VS.NET to 're-create' a low level trace breakdown of exceptions that occurred  Along with this comes the ability to double click an exception and have it go straight to the part of the application that caused it and have full history of the call sequence. Wow, how often do we get a "Please investigate problem 'x', and it occurs only every so often.' Then comes the process of trying to recreate the use case and cause the error which is often difficult. Intellitrace takes the guess work out of this process and streamlines time for developers to debug issues.

LIVE! 360 Keynote: Visual Studio and the New Web Enabled Apps for Office and SharePoint 2013
Jay Schmelzer, Director of Program Management, Visual Studio Team, Microsoft

Jay is responsible for the design time tools in Visual Studio, and as he was introduced these tools were touted as, 'everything that's important in VS.NET'. The focus of this keynote is on Office and SharePoint Applications built in VS.NET. 

Well for a web guy (for the most part) such as myself, doing any kind of Office automation on the server is a big 'no, no' and even is documented *here*. The only place appropriate in in a thick client Windows or WPF application which is not my forte over the last several years. I had my days of heavy office automation early in my career doing a lot with VB6 and VBA interacting with Excel or Word. In .NET I worked with the COM interop .dlls with Excel... make sure to dispose of those unmanaged objects, nuff said. The mindset over the last 6-8 years in my world was to veer toward making applications web based and independent of platform specific applications, i.e. Office. Maybe a wrong line of thinking; they have office for Macs too, right? (hint sarcasm)

However with the push of Windows 8 and the Windows App Store, there is more than certain a push to bring developers back close to the OS (could write an entire separate post on this). With this closeness to the Windows OS, re-enter (or at least for me) Office applications. I mean I'm not the only one on this track because I've seen very few keynotes or sessions on Office apps in the last 5 years at this conference.

Watching the demos though, I am pleased to see the flexibility in choice of technology use for creating these Office and SharePoint applications. Jay created a MVC 4 application (MvcApplication1.Sharepoint) for SharePoint, deployed to SharePoint with ease, and was then running and hosted in the context of SharePoint. How many times can I say SharePoint...

Here's one thing I hope I'm never told to investigate: "Allen, can you please take a look at the JavaScript object model for SharePoint." Sorry, no thank you I will pass.

Jay continued on with the plethora of new functionality regarding High-Trust apps and LightSwitch. They tout LightSwitch as "the easiest way to create modern business applications for the enterprise" My fear with LightSwitch is the days of old having rogue business developers creating enterprise applications and then dumping them on 'real' developers once they move on in life. Sound familiar: "yeah we have these apps John built using LampSwitch or something, and he left and there isn't anyone to support them. Can you help us?" 

The thing I give total credit to Microsoft is not boxing us into a narrow set of technologies to solve problems. While these products are not directly applicable to me today, I still thing they hold merit for the overall community in situations where they do make sense.


What's New in Visual Studio 2012
Rob Daigneau, Practice Lead, Slalom Consulting

This was a great session by an experienced leader of our industry. Rob used to be a director of architecture at Amazon.com, also wrote the book "Service Design Patterns". Book approaches doing services from a WSDL or REST style. (check slides for coupon code). This guy has a wealth of design and architecture experience, so I'm sure I'll be seeking him out in the future.

I always love when presenters ask a "who's using what" show of hands on technology. In this room there are probably 200-300 people.

• Windows 8 apps: 10 hands
• Web applications: 99% of the room
• WebForms: 35%
• MVC 65% (Quote from Rob: "Yeah, we're better. Haha, just kidding")
• WCF: About 30% of the room (I'm convinced service developers are a smaller subset due to the skills and is not a reflection of using a competing technology like the other votes)
• WinForms: 60-75% of the room
• Office Apps: 3 hands (see my keynote comments)
• Azure Apps: 2 hands.
• Windows Workflow: 2 hands.

Starting right off he highlighted the fact that with VS.NET 2012 you can upgrade a project without changing the project files (Yeah!). Also individual projects can target different .NET versions (Yeah again!). It can also target different platforms: Server, XBOX, Windows Phone, etc.

The following are the versions of VS.NET 2012: Test, Pro, Premium, and Ultimate. He states to get anything reasonable done you need to get at least the entry level 'Pro' version. The 'Test' version is targeted for QA professionals, that use 'Labs' that leverage VMs in the cloud to do testing. Odds are many here will use 'Ultimate'. 

Next he did the drill down on the different project templates in VS.NET 2012. All the players are still there with a focus on creating templates that are intuitive to help know which type of project to make. He also noted Silverlight is not dead, and still a citizen of the framework  A lot o SL code out there and it must still be supported.

He was speaking about the 'Metro' naming mess as others have. New name: 'Windows Store Apps'. A misnomer because they certainly do not have to be sold in the store. I think Microsoft could have come up with a better name.

The search capability in Solution Explorer is really nice. Ability to use pascal casing searches like 'CC' to narrow down to say 'CharityCampaign'. I am spoiled because a lot of these type features exist in tools like ReSharper which I use. However, if you don't have this tool, they have definitely made improvements to the search functionality.

Remember in any version of VS.NET the slowness of loading assemblies in the 'Add Reference' dialog? They finally fixed/improved this feature. The second the dialog is presented the entire set of assemblies is available for selection. New searching ability here as well, which before was done just via scrolling.

With ASP.NET MVC 4 they have optimized razor, added mobile templates, added Web API, and single-page applications (Knockout.js & Web API). Web API is for the development of truly RESTful services. As opposed to yesterday, Rob is clear on his choice between WCF based REST services and Web API, which is Web API.

Minification and Bundling are great features to organize and optimize the JavaScript files within an application. As JavaScript becomes more and more a 1st class citizen of writing applications (and not just a sprinkling of JS in web apps), these features are in here at a perfect time.

Navigation and development in HTML is much improved. Must of the features are small tidbits, but they add up. Changing the opening tag will change the closing tag for you (as opposed to searching for it), snippets (Tab twice), and improved intellisense based on document type (i.e. HTML5). The embedded page inspector helps replace the need for things like Firebug as well which is nice. The inspector is not totally new functionality in that it really is just the IE developer toolbar, but the main difference is not having to start and stop the project to have access to this functionality. It can now be done at design time.

I keep hearing with each version of VS.NET that JavaScript intellisense is 'improved'. I wasn't that impressed from 08' to 10', but it appears they actually have made decent improvements in 2012. Rob was highlighting some of the intellisense capabilities and I could see right away that it is better. I like the intellisense on functions which stems from user added XML documentation, quite similar to managed code. Debugging and adding quick watches was making me feel much more like I'm debugging C# which is a huge compliment.

Rob moved to the 'async' and 'await' functionality in C# 5.0. I've had a draft of a blog post on this for about (2) months now, and need to finish and publish. "Asynchronous programming can't get any easier than this." I couldn't agree more and I have other blog posts that speak to this. No more merging of threads, words like 'Mutex', etc. are the days of old.

I had a keen eye on WCF improvements because I use the technology heavily and on a daily basis. Web Sockets offer the same functionality at NetTcp binding but is based on open standards and is communicated via HTTP. There is a new binding named 'netHttpBinding' which will do web sockets. Super cool and I know I will be looking to use this in the future.

He also highlighted a new feature on an advanced feature option when adding a WCF reference that allows for task-based asynchronous programming. Ok this is awesome, but contradicts with some of the content from my post yesterday about WCF architecture. I'm not sure how this feature would be incorporated manually when creating the WCF communication layers manually and not having the proxy classes automagically built. Guess I could always cheat and see what the proxies look like and see how it behaves to port over to an implementation that uses manually created proxies.

Oh wow, Dependency Graphs (Architecture -> Generate Dependency Graph) are something I could really leverage, especially when inheriting a larger project. It creates a visual diagram of all assemblies, there relationships, and dependencies. This is super useful when trying to understand how the moving parts all interact. Sometimes swimming around in the unknown of a new solution and trying to at a high-level see how parts interact is not an easy task. These architectural views will help alleviate this challenge.

To sum it up, I'm sold on VS.NET 2012 (WITH ITS GREAT NEW MENUS :-P).


Smackdown: Windows Store Apps vs Websites
Ben Dewey, Senior Consultant, Tallan, Inc. Author of Windows 8 Apps

Ben touts this class is a good fit so developers can know the difference and make good choices when questioned or tasked with selecting a traditional website or a new Windows Store application.

Windows 8 now exposes a new API named WinRT. WinRT is C++ code built upon the runtime to allow the development of windows store apps. .NET was built atop of COM and the Win32 API. WinRT is an OO API with a projection layer that allows development in various languages such as JavaScript, XAML, or C++ to make Windows Store applications. Devices where the real driver of WinRT. Cameras (CameraCaputreUI), GPS, Accelerometer, blue tooth, Near Field Communication, etc. Microsoft promises to build upon WinRT for new devices.

One note he made and I've spoke of over the last year or so is that it is still difficult to develop using HTML5 because in the enterprise there are too many still on non-supporting browsers like IE7 and IE8.

One reoccurring premise I see consistently is that you are going to have a much more rich user experience when creating a Windows Store app (obviously) because of the closeness to the OS using WinRT as opposed to rendering HTML to the client (even with HTML5 ability) from a remote server.

Windows Store applications must have a 'clean' experience offline. Thus means you will want to download all the images, etc. so users can run offline with a seamless experience.

When using JavaScript and Windows 8, there is access to that WinRT C++ code directly. There is also enhanced support for touch, new controls, and asynchronous support. JavaScript is a 1st class citizen when it comes to writing WinRT apps. Therefore is you like JS, you will be happy to create your Windows Store apps using it as a primary language. I've used JS as required in my web apps over the years and more so recently, but I still am not comfortable using it like I am in C# or VB.NET. I know one thing is for sure, JS is not going away so I need to keep refining these skills especially in the areas of JS asynchronous programming. What I would love to see is a session highlighting the different languages that can be used to create Windows Store apps. I understand opening the door to all the languages is to attract the masses, but why in the world would I by default pick JS to write an app and not C#/VB.NET? I'm sure someone could justify it well, I just haven't been enlightened on it yet.

Ben presented a few Windows Applications built with JS, using a camera, using the GPS, and using a simulated accelerometer. I have to admit, for this type of functionality these apps are ideal to make as the WinRT API exposes functionality directly to bring these devices to life. With just a few lines of code + a Bing 3rd party tool, he had it wired up in JS to show our exact Geo location using the GPS in his laptop. I was impressed how fast it switched from New York on the map to hear in Orlando. He noted when using rapid fire events that are subscribed to is to only listen when required to preserve battery.

File I/O in WinRT has an enhanced file upload control for Windows Store apps. One cool feature is the ability to select a file on the client and manipulate on the client without uploading to the server. After all if the server is not required, then why involve it. The upload control also has the ability to upload multiple files, which was not native with the traditional HTML or even ASP.NET upload control. I can say from personal experience the ability to extract a thumbnail of an image so easily is awesome.

Some of the new features of Windows 8 are the 'App Bar' and charms. If using IE on Windows 8 you will see the app bar across the bottom of the screen in the form of global buttons on the right (i.e. navigation), and current selection buttons on the left. Charms are available from a bar that runs down the right hand side of the screen, and may include charms like 'Search' or 'Share'.

'Hybrid' apps allow creating a native JS Windows Store app and also a web app by simply using an iFrame. This gives you the best of both worlds by allowing access to the rich native WinRT functionality while still having a website accessable via any URL. Ben mentioned some frown upon this approach but it is doable.

Obviously another plus for Windows Store apps are discoverability and monitization, Having some random web app can be difficult to sell functionality or draw traffic. Windows Store apps now have a centralized home in the Windows Store and provides the ability to sell apps and make money.

By the end of the session one thing is apparent. From the perspective strictly for providing a rich user experience and deep functionality, the winner hands-down are Windows Store Applications. This is of course throwing out the large elephant in the room which is the requirement of Windows 8. So web apps vs. Windows Store apps is a little Apples and Oranges. I also must say a lot of these sessions highlighting Windows Store apps remind me of the Silverlight sessions 3-4 years ago. All the examples were simple little video players or Twitter apps. The real comparison to shape up in the future is selling the masses on the new format and interactivity learning curve in Windows 8.


What's New in the .NET BCL
Jason Bock, Principal Lead Consultant, Magenic

Jason is an elite member of our industry, supporting his status as a MVP with his quality sessions at Visual Studio LIVE! I have had the pleasure of attending Jason's sessions before and the guy has more low level framework knowledge than almost anyone I've interacted with previously. And he likes the band Rush too, so that's cool!

The .NET framework is now 10 years old and we have come a long way. It's amazing how much  its evolved since Framework 1.0 and how much functionality has been added over the years.  The .NET framework 4.5 is whats called an 'in place upgrade' and actually places all of the new files into the v4.0.30319 directories. This is important to understand because the 4.0 assemblies will be overwritten. However, Microsoft says this will not be a problem as it's an in place upgrade, but it's still good to understand the behavior.

The BCL is made up of the following as diagrammed below (image courtesy of Visual Studio LIVE! and Jason Bock):

Jason was highlighting a tool he used that would output the differences between the different frameworks and output it to XML. The purpose of this is just for reference since there really isn't not a good repository showing the comparisons between the frameworks. He mentioned there was a tiny bit of functionality marked Obsolete in the Framework, but it was so esoteric and unused odds are it will not affect the masses.

A topic on asynchronous programming came up because by his estimation there are 230 new methods that are asynchronous in .NET 4.5. In fact all of the File I/O operations from the last session I attended for Windows Store Apps are asynchronous  Over the years if you look at CPU speed it would almost double every few years. Well in the last few years the speed has decreased, but more cores are added. Each core has a thread so many machines today (like mine) have 4 cores and 8 threads (Hyperthreading enabled). What we as programmers need to be doing is utilizing these cores to allow asynchronous programming. And today in .NET 4.5, there is almost no excuse not to because the complexities of asynchronous programming are more and more being extracted away. Queue TPL and async and await keywords. He recommends as do I agree to use the 'Task' class and not 'Threads'. In fact what's interesting is he states how disgustingly complex the code to support these simple keywords is under the covers. He said to look at the IL and see how nasty the implementation code is. We are not supposed to see that code anyways, but leverage the hard work others have done for us. 

There is a new ability for you RegEx fans to add a timeout to the expression evaluation. This is good so that if something is quite complex, you can cause it to timeout explicitly. The timeout value is placed in the overload of the constructor.

Next he moved into memory management in Framework 4.5. He (as am I) always dumbfounded by those that do not like deterministic disposal and rely solely on the Garbage Collection thinking it is perfect and there can be no memory leaks. To prove that the GC is not perfect, allocate really, really large arrays and let them sit around. It will introduce memory leaks. He also demonstrated how wiring up events(+=) and not unhooking them (-=) (which is important) can cause some memory leak issues that are quite significant. In applications, it is possible that handlers that are attached to event sources will not be destroyed in coordination with the listener object that attached the handler to the source. This situation can lead to memory leaks. A new class named 'WeakEventHandler' has been introduced to help prevent the memory leak condition acting like a manager on that handler and ensures to unhook the handler automatically.

He also covered compression. There is finally a way to read a .zip in .NET 4,5. There was compression previously like 'DeflateStream' or GZip, but nothing for .zip native to the framework. No longer do you have to get NuGet packages or 3rd party components. 

Lastly he spoke to web sockets which is probably one of the favorite technologies I'm looking forward to using in the future. He finished out with some of the other bulleted items added like UDP in WCF, Generic support in MEF, and System.Json.

Wrap Up Day 2

Well it's been a busy day and it has flown by! It seems like I just woke up and now the day is complete. All presenters are 1st class as usual as well as the attendees I interact with. If you think about it, conferences like this amass the best of the best in the industry and so it's easy to get along with those around. It's like 1 big team of sorts.  My brain is filled with lots to digest and I look forward to what tomorrow will bring!

Visual Studio LIVE! Day 1 - WCF and Web API

So it's day 1 here at Visual Studio LIVE!, and I'm here attending Miguel Castro's WCF & Web API full day workshop. There is a great attendance with probably 300-400 people from my estimation. I'm here on the 2nd row so I can get the most and interact without yelling. I am definitely refining my air traffic controller multitasking skills today trying to listen, take notes, and learn simultaneously.

I actually had the pleasure of having dinner with Miguel and his family along with Rocky Lhotka, and Andrew Burst at last years conference over at Bubba Gump Shrimp. I sat across from Miguel and had some great conversations on WCF. I also had lunch today with him as well which was cool! The man has a Black 560 HP Mustang GT he customized. Yes please. Here's a guy that has a wealth of knowledge on WCF, services, and SOA which you wish was sitting in the cube or office next to you on a daily basis. He validates himself easily as a Microsoft MVP for Connected Systems, and I enjoy his knowledge transfer.

This class was interesting to me because I have been using WCF since CTP in Framework 3.0, and by no means do I consider myself an expert (on this or anything), but I wonder about tracks I have a deeper experience in already. Meaning, will it be a lot of information I've digested previously. Fear not, one can never know it all. Case and point this class by Miguel. The byproduct of the architecture used behind some of the simple WCF samples shown is the real gem.

When Miguel asked how many in the room are WCF developers, to my surprise it was not the overall majority in the room. I am confident this was not telling of the technology but rather there were a lot of developers that have not been involved with writing services. I feel for some of these people because WCF is so deep as a technology that's it's hard to digest in a single day. This is exactly the reason though that I found this class so informative. This was a 300 level track masquerading a a 101 during introduction, and he states this is a 5 day class compressed to a single day. When DI, SOA, SoC, and OOP are all being discussed within the 1st hour or so... this is great stuff.

Where I really align beliefs in architecture with Miguel is on SoC. I always can get a feel of how an architecture is laid out simply but looking at all of the projects in a VS.NET solution collapsed and seeing the logical layers. Miguel is a strong proponent of separating the individual pieces of WCF into their own layers. He does not care for the bloating of the auto generated proxy classes created by 'Add Service Reference' within VS.NET, in addition to the tightly coupled nature of the service contract, implemented classes, and the associated channel communications. I too agree for the majority of applications. I still think there is a place for consuming a service and having the proxies created, along with a WCF Service Library on the back-end. I think if you have a simple 1 page app using a simple service (keeping in mind YAGNI principal, while still observing scalibility of functionality), there is a place for a compressed architecture. WCF Service Library or WCF Service Application + Consuming client application using 'Add Service Reference' within VS.NET is simple, straight forward, and easy to understand and consume. I try never to be what they call an 'Architecture Astronaut' and over-architect when not required; not implying Miguel is this by any means, but just that I rarely will use the word 'always' (he didn't either, just making a point) when using the sentence "This application should be architected like this ____" I also don't believe in spaghetti crap applications either, so hopefully I make proper decisions on building and constructing applications.

However for true enterprise applications using SOA as a basis, or even any large scale isolated applications I couldn't hold the flag with any more pride on properly separating the logic when working with WCF. I'm a big fan of the ideology around architectures like Domain Driven Design, MVC, MVVM, and heck even simple 3-layer UI-BLL-DAL. They all have at least a basic commonality which is the idea of logically separating responsibilities and concerns. Since WCF inherently has a lot of different responsibilities end-to-end it to makes sense to separate the major players into their own pieces. This isn't really a new concept as most advanced literature in our field will at minimum separate out the host and WCF functionality, but most even take it a step further and break the pieces down further. Why all of this work? In the long run it allows us to be extremely flexible and make isolated changes without a large ripple effect, and to allow switching out pieces like the host easily.

First let's look at an overall SOA architecture. This gives a great visual on a decent layering of the application (slide courtesy of Visual Studio LIVE! and Miguel Castro).

Here is a breakdown of the WCF components that will need to be created, each responsibility being its own project (slide courtesy of Visual Studio LIVE! and Miguel Castro):

Next let's look at the breakdown of the actual project layers and their high-level purpose:

Business Engine: This is the typical layer which contains the business rules and logic. Also referred to as the Business Logic Layer, Business Domain or just Domain Layer.

Client: This represents any UI client that will be making calls to our WCF service. This might be a ASP.NET, WPF, WinForms, etc. application.

Contracts: These are the Service Contracts and any DTO DataContracts used for transporting data across the wire. There are no implementation classes in this layer. Miguel had a nice suggestion to post fix the word 'Data' on a DataContract DTO, like 'ZipCodeData'. This helps distinguish them from service or business logic methods. DTOs are typically nothing more than getters and setters to move serilizable data across the network.

Host: This is the hosting layer for WCF. This might be contain the files necessary for hosting via a  self-hosted Windows Service or IIS (.svc file). Remember that  a svc. is a 'browsing point' for a WCF service. It invokes the appropriate WCF handler. ASP.NET needs a browsing point to know what world it's in.This also contains the .config file, and the only one that matters which is the one from the host. Within this config there is the WCF configuration

WebHost: This is an optional layer that provides an additional avenue if the 'Host' layer is implemented using an alternate self-hosted mechanism like a console application or Windows Service.

Again as you decipher each layer you see it has a very specific responsibility  It really is not a lot of extra work to segregate the layers and the benefit is the ability to make isolated changes or even switch out components more easily (like hosting methods) without a lot of 'unhooking'. The main thing here is *not* to couple the host and the service code in case the host needs to be changed out later. This architecture and layout of the layers has it's obvious benefits.

He then led into a great discussion on WCF Proxy Instancing and Concurrency. I was more interested in the instancing portion as I think there are more use cases for making changes. The following are the (3) main types of instancing:

Per-call instancing
    -each call spins up a new instance of the service.
    -On the client it appears that it's a single object, but it's not. Stateless behavior.
     -Advantage is stateless, scalable, and nothing is held on server's memory.
      -Not the default, but Miguel sets his services up like this.
Per-session instancing
    -WCF default
    -1st call spins up instance and calls constructor
    -2nd call uses SAME instance
    -Can maintain state using class-wide members in service
Singleton Instancing
    -when host opens, host instantiates service
    -one instance serves all proxies for all clients
    -very specific usage scenarios
    -With IIS hosting and the potential for app pool recycles, the Singleton instance is destroyed and dispose is called. This is a disadvantage and something to keep in mind if trying to use a Singleton for the WCF proxy.

On the topic of proxies, they are unmanaged objects. They are not CLR managed. Always dispose of proxy classes, and use a 'using' statement when possible to wrap instantiation of the proxy classes. Until the proxy is closed, WCF will keep an open connection and add to the value for service throttling thinking the connection is still active. Throttling is ability for WCF to manage concurrent calls, prior to queuing up to prevent server from breaking. This is really important to be on notice. If that proxy class is not disposed performance can hinder significantly  Miguel had instance where a DI proxy in MVC was not disposed. Calls went from 1.5 secs to 100ms once the issue was tracked down and the proxy was disposed. A few in the audience complained of problems with the 'using' statement throwing exceptions, but I would like to see the IL differences from calling manually. Bottom line, dispose of explicitly if the 'using' statement gives any issues.

Next he went into doing WCF callbacks. Very useful stuff. Callbacks have a place for keeping a proxy channel open to allow the server have the ability to make calls back to the client. The use of this could be as simple as updating a progress meter bar, updating sports scores during a game, updating stock prices, updating dashboards, etc. This is in my opinion a much more appropriate 'tool' for what often is done via a timer and polling. Polling definitely has its place and I use it and have blogged on it, but when the responsibility is on the server to notify the clients of updated data, then using duplex services are a good idea. If you have a need to constantly keep a client updated and are using a WCF SOAP based service, then using callbacks and a duplex service should be considered, especially if you are implementing some sort of polling to fetch data.

The topic of WCF exceptions was also highlighted. As always the main exception rules still apply when handling exceptions. Here are the main reasons to catch exceptions:

• wrap and re-throw
• log and re-throw
• consume and dissolve

However with WCF operations it is acceptable to have one big Try-Catch with Throw FaultException.
My particular favorite way is using something like the following:

throw new FaultException("Blah, blah");

Something interesting, if you do not explicitly throw a FaultException server side or throw an exception of a specific type (i.e. DivideByZeroException), the proxy on the client will *not* be preserved and will be closed. However, if a FaultException or FaultException (where 'T' can be an exception or any data contract) is thrown by the service, the proxy state will be preserved. I asked why we would want to preserve the proxy state on the client? After all we are busted server side, should the client proxy survive? Odds are no it should not. But maybe you want to give the client a chance to absorb and go through some re-try logic without closing the proxy. This would be a rare use case, but it's important to understand.

Miguel also highlighted Transactions is WCF. I have not used transactions in WCF in a production setting, but as typical the best example to show how to use transactions is with a bank account example. The example used was one of a method called 'TransferMoney()' and underneath (2) additional methods are called 'DebitAccount()' and 'CreditAccount()'. Obviously if 'DebitAccount()' worked and 'CreditAccount()' did not, we do not want the transaction to complete and have it roll back. This is not the same as those that have worked with SQL transactions in ADO.NET. The rollback is independent of any SQL calls. You might still have a database call involved but you might not as well.

A few things to note on transaction in WCF. They are at the operation level. By default transactions are not turned on (Value = 'NotAllowed'). However there are (2) other settings which are 'Allowed' and 'Mandatory'. As Miguel mentions, setting the operation to 'Allowed' is a low risk as it actually does nothing until transactions are implemented; it just opens the door to allowing them if desired. Also, all methods downstream must participate in transactions or the transaction functionality will not work properly. Any method in the chain that does not support and implement transactions will not allow the rollback to occur if there is a failure. Lastly, the client does not need to worry about wrapping the initial call into a transaction. As long as the WCF service implements them properly it will still have the transaction implemented correctly. Transactions are not needed for all use cases, but the actual implementation when planned out properly is not too difficult.

In come REST services, my favorite topic of the day. I know not the end-all answer to everything, but its power and simplicity are great. WCF SOAP services for line-of-business intranet .NET to .NET apps using NetTcp bindings are still lightning fast and the way to go for performance. However the minute a non-.NET client is introduces especially outside the firewall, using RESTful services are the required solution. Miguel stated that even know the wsHttpBinding is supposed to have interoperability, it doesn't do uplevel perfectly so need to go with REST in these situations. Deciding SOAP services vs. REST services will mostly come down to the consuming clients, internet vs. intranet, and interoperability factors. Also remember with REST services many of the topics discussed previously like transactions, concurrency, etc. are not applicable. There is still a place very much so for SOAP based services albeit a much heavier implementation that that of REST based services.

REST based services are much lighter weight than SOAP services returning either XML or JSON typically. There is no heavy SOAP message to deal with and the constraints of what the consuming client will look like. REST services based on the REST architecture are an extension of web standards and the GET, PUT, PLACE, and DELETE verbs (note: PUT and DELETE verbs are turned off in IIS by default, so make sure to turn them on if you need them). In fact you can make REST based calls directly in a browser (browser calls are by default HTTP GET). Although the purists, the so-called 'RESTafarains' will never acknowledge a pure REST implementation most of the time there is at least one place I totally agree with them on implementing these types of services. Make sure to use the HTTP verbs properly  For example, don't abuse the verbs and do an 'update' behind the scenes as part of a GET. While possible it's incorrect and there are really no checks in place to prevent this.

With a WCF implementation, the deciding factor on the return type, XML or JSON, is configurable at the service level. Ideally you would expose (2) endpoints, (1) for each return type. Then it's up to the client to call the appropriate URL containing the endpoint that will return the desired type. However, technically the server is still deciding on the actual service what the return type will be.

What I REALLY like about Web API services is the ability for the client to set the 'Content-Type' value in the request header to indicate the return type! Yep no configuration or heavy implementation. Set the header and you get back the type you requested. If testing from a browser, Google Chrome by default returns XML, and IE returns JSON. My recommendation if you are not familiar with JSON is to begin using it because it is more compact and lightweight than XML. With so many JSON deserializers in .NET it makes it super simple to convert it to a DataContract once received and then work with a strongly typed object. You *can* do the same with XML via LINQ to XML into a type like a DataContract but it's much more cumbersome to work with in my opinion.

WCF REST service and ASP.NET Web API are competing products at Microsoft and have a single intended purpose to deliver data in a RESTful manner. However, REST was introduced 1st in WCF 3.5 with introduction of WebGet and WebInvoke attributes and webHttpBinding. Web API was originally born out of the WCF Starter Kit and was RC in MVC 4. You can use the Web API with .NET Framework 4.0.

The main deciding factor when looking at architecting an application is the decision to use a WCF REST based service vs. a Web API service. There are subtle advantages to both and Miguel warns of not getting all caught up in the 'Web API is the greatest thing since sliced bread' deal. If you already have a full blown WCF service layer implementation and need to add REST atop of that, then a WCF REST service may be the easier way to go. However if starting from scratch it appeared to seem that the general census was to use a Web API REST implementation.

Interesting tidbit - technically the largest REST based deployment in the world... the world wide web.

The final part of the day was to cover WCF security in 45 minutes. WHAT?!?! Yeah pretty much impossible. The good news is (at least for me) I was have done so much over the years with WCF security, authorization, authentication, and securing services that the security information 'blitz' made sense to me. However anyone in the audience that has not done anything with security will need to do a lot more research on the topics. May I recommend perusing this blog as I have dedicated several posts to WCF security and securing WCF services.

The main points I wanted to highlight here are the following. TCP is a secure binding by default. It's binary. You can't break the pipe. HTTP on the other hand is an open binding and the 'message' needs to be secured. You can actually secure the 'Transport' which will also secure the message with either a SSL certificate (HTTPS) or via X509 certificates  I prefer using a SSL cert and like I mentioned have several posts on the topic. However the points on NetTcp are important to restate. If you *can* use a TCP binding, you will get some blazing performance and native Windows Security so it's an attractive option when working on an intranet application with a .NET to .NET scenario. Check out the WCF Security Guide on CodePlex if you really want a deep dive. In reality an 8 hour course could easily be given just on the topic of security.

To wrap things up on this busy day, I must say I onloaded a LOT of information for the services world. If you have a chance check out Miguel at any of the mainstream conferences around the country, on his blog, or on Twitter @miguelcastro67. I only have one piece of advice for Miguel since he has provided so much information to me today... dump the Mac.

I will also leave you with some of Miguel's best quotes of the day. I always enjoy his candid style!


"What is exception handling? A slash block and then 'ToDo'"
"Can we even call them Metro apps anymore, or not because some food store in eastern Europe sued Microsoft."
"Compilation is the 1st unit test, right... sometimes it's the only unit test"
"I get to start shit and not have to finish it" (contractors)
"My shit don't break"
"Who does SharePoint in the room.... Why?"
"no, no Google, we use Bing here right?"
"Dude, i'm not covering security 2 hours in! I do it at the end of the day when you brains are fried so I can bull shit my way through"
"You just broke my shit, I'm going to be pissed"
"Rhode Island sucks! It's not even a real state."
"What do you have to do to slow a Windows system down... Nothing"
"I feel like I just gave birth to a callback."
"Most New Jerseyans can't spell DB2"
"The RESTafarains are as whacked out and smoke as much ganja as the Rastafarians"
"Regular Expressions are cartoon characters cursing"
"I don't agree with anything a DBA says except in table naming"

It's Visual Studio LIVE Eve!

I pumped and excited for another great year at Visual Studio LIVE! I'm attending the 2012 conference here in sunny Orlando, Florida which is a great selection based on the cold, rainy weather I see around the rest of the country. It's my 5th Visual Studio LIVE! conference, and I can say it has been a HUGE contributor to my DNA makeup as a software developer over the years.

I noticed this year the conference has expanded back out to Visual Studio LIVE!, SharePoint LIVE!, SQL Server LIVE!, and Cloud & Virtualization LIVE! The last time I saw the conference segregated out like that was in 2007 in Vegas when it was the old TechMentor and VSLive! conferences. Nice to see the conference is back in full swing and there are going to be a boatload of talented folks from all over the country attending.

Of course I will be focusing on the Visual Studio LIVE! tracks and will veer toward a lot of the ASP.NET sessions in MVC, Web API, JavaScript and the like. I'm also looking forward to sprinkling of sessions on Windows 8 applications, VS.NET 2012, and .NET Framework 4.5. As usual I'm looking over the tracks and there are always multiple great sessions occurring at the same time, so it's always difficult to choose.

Another great part of this conference is networking with elite developers and the like to get a litmus on the industry and what people are using, found not good to use, and overall direction on the Microsoft stack.

I've already registered tonight and getting ready for a full day workshop tomorrow on WCF and Web API with Miguel Castro. I've always been a fan of programming services and enjoy them a lot so tomorrow should be both fun and intriguing to continue my knowledge push on these technologies and best practices.

All right, it's almost that time so here we go!!

Windows Store Open To Developers

It's time Win8 devs! The Windows 8 Developer Store is now open to begin submission of your Windows 8 applications. You can sign up for a Windows Store Developer account today, and if you happen to be an MSDN Subscriber, then you should have access to a registration code to offset the cost of signing up. If you are not an MSDN subscriber, than the account will cost you $49 annually. 

From the site you get the following with your account:

• Your Windows Store developer account
• Access to the Windows Store dashboard
• The ability to publish apps in the Windows Store
• Detailed info about your apps in the Windows Store
• Auto-renewal every year (paid subscriptions only)
• Two free assisted technical support incidents per year

It's a small price to pay if your app hits the jackpot, right!?!?! To get started click the link below and sign in with your existing MSDN or Live account to begin registration:

Windows Store Dashboard

Windows Store now open to all developers in 120 markets

Using ValueInjecter With ViewModels and Entity Framework in ASP.NET MVC

If you decide to use ASP.NET MVC with the Entity Framework, you will quickly come to see that the perfect one entity per view scenario that most of the examples show is not realistic. Enter the need for ViewModels. The ViewModels are specially shaped classes that act as an intermediary between the 1...n entities that will eventually comprise a single view (or partial view).

The challenge is when it comes to repopulating the original 1...n entities that comprised the ViewModel upon the user making an insert or an update. In our perfect one entity to one view scenario, MVC model binding takes care of all the work repackaging our entity in the controller, and it is a matter of a few lines of code to add that object to the EF context and save the changes. Code in this scenario would be as straight forward as the following:

[HttpPost]
public ActionResult Create(Contact contact)
{
    if (ModelState.IsValid)
    {
      using (var context = new AdventureWorksEntities())
      {
        //Add the model bound object to the context and save:
        context.Contacts.AddObject(contact);
        context.SaveChanges();
        return RedirectToAction("Index");
      }
    }
    return View(name);
}

When using ViewModels, a convenient option to help reduce any manual mapping back to entities is to use an open source product named ValueInjecter. You can download the binaries from NuGet located here.

Value Injecter allows us to easily map properties from a source object to a destination object without what would be normally required to rehydrate the multiple entities. The main method we will use is the exposed InjectFrom() which will allow us to inject the values from the source to destination object. Once complete, we can then persist our entities back to the data store using EF with only a minimal amount of additional coding.

To begin let's take a look at the following ViewModel class I created based on (3) different tables from the AdventureWorks database: Contact, Employee, and EmployeeDepartmentHistory. The idea here is that we need to add a new employee record here that spans these (3) tables. The focus here is not on the schema from the AdventureWorks database but rather just to display how Value Injecter can be used to persist data to these (3) entities. As you can see below the ViewModel class has fields from each of the tables; however for brevities sake I have kept the class small. In reality there are quite a few more required fields that would have to be defined.

namespace Mcv4ValueInjecterSample.ViewModels
{
  public class EmployeeViewModel
  {
    [StringLength(50), Required]
    [Display(Name = "Employee First Name:")]
    public string FirstName { get; set; }

    [StringLength(50), Required]
    [Display(Name = "Employee Last Name:")]
    public string LastName { get; set; }

    [StringLength(50), Required]
    [Display(Name = "Email Address:")]
    [DataType(DataType.EmailAddress)]
    [RegularExpression(@"[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}", ErrorMessage="Please enter a properly formatted email address.")]
    public string EmailAddress { get; set; }

    [StringLength(25), Required]
    [Display(Name = "Phone Number:")]
    [DataType(DataType.PhoneNumber)]
    public string Phone { get; set; }

    [Required]
    [Display(Name = "Birth Date:")]        
    public DateTime BirthDate { get; set; }

    [StringLength(50), Required]
    [Display(Name = "Title:")]
    public string Title { get; set; }

    [Required]
    [Display(Name = "Employee Start Date:")]
    public DateTime StartDate { get; set; }
  }
}

Next I have an EmployeeController class with a Create() method that takes in my ViewModel type as its parameter. I am going to inject the values from the model bound ViewModel object data into the individual underlying entities and then save the changes.

[HttpPost]
public ActionResult Create(EmployeeViewModel employeeViewModel)
{
  if (ModelState.IsValid)
  {
    using (var context = new AdventureWorksEntities())
    {
      var contact = new Contact();  
      //Inject the values into a Contact entity using ValueInjecter                  
      contact.InjectFrom(employeeViewModel);

      //Do NOT use the title submitted by the client, 
      //but rather override with a default value
      contact.Title = string.Empty;

      var employee = new Employee();  
      //Inject the values into an Employee entity using ValueInjecter                  
      employee.InjectFrom(employeeViewModel);
        
      var employeeDepartmentHistory = new EmployeeDepartmentHistory();
      //Inject the values into a EmployeeDepartmentHistory entity using ValueInjecter
      employeeDepartmentHistory.InjectFrom(employeeViewModel);
        
      employee.EmployeeDepartmentHistories.Add(employeeDepartmentHistory);
      contact.Employees.Add(employee);

      context.Contacts.AddObject(contact);
      context.SaveChanges();

      return RedirectToAction("Index");
    }
    return View(employeeViewModel);
  }
}

Note the explicit assignment of the Title property on the Contact object above. In the Adventureworks database, both the Contact and Employee tables have a Title field. My Employee view had an input for the client intended to fill out the Employee's title and not the Contact's title. Value Injecter by default will not discriminate and simply hydrate the destination object based on the matched property name (as designed so this is OK). Just make sure to intervene where needed if you run into a situation with identically named properties on objects.

That's it! There is actually a lot more functionality to ValueInjecter than what was shown here so I encourage you to look at the Documentation section on its CodePlex page. However even just this example can be scaled nicely to large legacy or existing databases where the 1:1 view per entity scenario rarely occurs. In this case consider using ValueInjecter to save on a lot of additional coding when using ViewModels in ASP.NET MVC.

aspConf - A Free Virtual Conference on ASP.NET

There is a fantastic free opportunity upcoming next week on July 17th & 18th 2012, to attend the 'aspConf' ASP.NET virtual conference. There is an array of great presentations being done on a variety of ASP.NET topics which is exciting. Also, there are (2) well know keynote speakers: Scott Guthrie and Scott Hansleman from Microsoft.

Click on the logo above or the link below to check out the agenda and to register. These guys are typically at the conferences that cost well over $1000 for admission, so it's great to have an opportunity like this to participate and learn for free!

One note for those attending on the East coast: looks like the conference is being held with a focus on West coast time, so the (2) days it goes from 10:00am - 7:00pm EDT.

aspConf - The Virtual ASP.NET Conference

Using Basic Authentication In REST Based Services Hosted in IIS

So a colleague of mine asked a good question earlier today in reference to my last post on using Basic Authentication techniques in reference to REST based WCF services hosted in IIS. It turns out that there is conflicting documentation on whether or not a Custom User Name and Password Validator that has been configured works properly. In my last post I created a self-hosted service with full implementation and it does indeed work.

However best I can determine is that the IIS call stack is executed and handled, using Basic Authentication for your service does not allow you to override the IIS behavior and intercept those credentials using a custom username/password validator. This is because IIS is handling the authentication prior to the WCF service being called. Thus resulting in a lot of buzz around, "...why doesn't my custom user name and password validator" code get hit for a my WCF REST service hosted in IIS." I also believe I have found some definitive information on the support of this in IIS from Phil Henning's MSDN blog:

"In the version of WCF that shipped with .Net Framework 3.0 we didn't support custom validators with transport level HTTP security. We received much feedback from the community that this was a highly desired feature, so I'm happy to say we added support for this scenario in the 3.5 release of the .Net Framework. Note that this is only supported under self hosted services."

So that to me reads clearly. Also I found this tidbit from Yavor Georgiev of Microsoft confirming this and stating: "As the blog post mentions, this scenario is not supported while hosting in IIS. The reason is that IIS does the authentication before WCF receives the request." So there we have it - dual confirmation that the custom username/password validator is not supported in IIS hosted services.

In addition to this we have even yet another problem. Using Basic Authentication with REST based services hosted in IIS period. Even this vanilla security authorization technique is not supported. I didn't find much in the way of official documentation, but between my own failed tests, this forum post, and this blog post, it points in the direction that there is no 'out of the box' support for this combination.

At this point the easiest option if you need to use REST based services with a custom username/password validator and use Basic authentication may be to use a self-hosted service. I often hear and read, "Use an IIS based service unless there is a need to self-host." This is a scenario where self-hosting stands out as the winner... initially. But you know I wouldn't post without an IIS solution, right!

We do have another workable and legitimate solution to have a REST based service hosted in IIS using Basic Authentication. As I mentioned before in a few posts and shown examples for, we can implement our own CustomAuthorizationManager that inherits from ServiceAuthorizationManager and configure this for our service. This method is perfect for service level Authorization to your RESTful service. The best part is we can still inspect the incoming message headers to siphon out the client's passed credentials. In this manner we can still provide service level authorization.

As far as the 'Basic' authentication handling, we are going to need to do that ourselves. We can easily send back a response header to challenge for Basic Authentication credentials, and just have IIS wired up to "Anonymous Authentication." We are going to just let IIS do the hosting and take care of all of the authentication ourselves. After all IIS is just a huge, sophisticated wrapper in itself handling security (and a million other things) for us, so we will just shift control of this specific piece back to our service.

To begin, go ahead and configure the service to use a custom authorization manager, and point it to our class named: 'CustomAuthorizationManager'. Keep in mind that the format is [Assembly Namespace].[Classname], [Assembly Namespace] for the serviceAuthorizationManagerType value. Here is the configuration I used:

<serviceBehaviors>
  <behavior name="SecureRESTSvcTestBehavior">
    <serviceMetadata httpGetEnabled="false" httpsGetEnabled="true"/>
    <!-- To receive exception details in faults for debugging purposes, set the value below to true.  
    Set to false before deployment to avoid disclosing exception information -->
    <serviceDebug includeExceptionDetailInFaults="true"/>
    <serviceAuthorization serviceAuthorizationManagerType="RESTfulSecurityIIS.CustomAuthorizationManager, RESTfulSecurityIIS" />
  </behavior>
</serviceBehaviors>

Next, let's build out our class that will override the 'CheckAccessCore' method. This allows us to intercept calls early in the call stack and decide after analyzing things like the user context or request headers if we want the call to succeed. This method simply returns a Boolean. Returning 'false' will prevent the call from continuing. The code I use below is not completely filled out for production. You probably want to test to see if the header contains "Basic" within 1st, and also make sure all the credentials are supplied. If not, returning a proper .NET exception would be in order. Here is the code I used:

protected override bool CheckAccessCore(OperationContext operationContext)
{
    //Extract the Authorization header, and parse out the credentials converting the Base64 string:
    var authHeader = WebOperationContext.Current.IncomingRequest.Headers["Authorization"];
    if ((authHeader != null) && (authHeader != string.Empty))
    {
        var svcCredentials = System.Text.ASCIIEncoding.ASCII
                .GetString(Convert.FromBase64String(authHeader.Substring(6)))
                .Split(':');
        var user = new { Name = svcCredentials[0], Password = svcCredentials[1] };
        if ((user.Name == "user1" && user.Password == "test"))
        {
            //User is authrized and originating call will proceed
            return true;
        }
        else
        {
            //not authorized
            return false;
        }
    }
    else
    {
        //No authorization header was provided, so challenge the client to provide before proceeding:
        WebOperationContext.Current.OutgoingResponse.Headers.Add("WWW-Authenticate: Basic realm=\"MyWCFService\"");
        //Throw an exception with the associated HTTP status code equivalent to HTTP status 401
        throw new WebFaultException("Please provide a username and password", HttpStatusCode.Unauthorized);
    }
}

Looking above, I siphon out the "Authorization" request header value to inspect. This is just a Base64 encoded string, so we can just convert it back. This is the very reason why we need to secure our service with a SSL certificate because the credentials are not secure. Once I parse out the username and password I can use the same tests I did before when using a custom username/password validator for self-hosted services. You can use the identical test calling code that I used in the last post to add the basic authentication credentials to the request header.

HttpWebRequest req = (HttpWebRequest)WebRequest.Create(@"https://DevMachine1234:8099/MyRESTServices/Customer/1");
//Add a header to the request that contains our credentials
//DO NOT HARDCODE IN PRODUCTION!! Pull credentials real-time from database or other store.
string svcCredentials = Convert.ToBase64String(ASCIIEncoding.ASCII.GetBytes("user1"+ ":" + "test"));
req.Headers.Add("Authorization", "Basic " + svcCredentials);
//Just some example code to parse the JSON response using the JavaScriptSerializer
using (WebResponse svcResponse = (HttpWebResponse)req.GetResponse())
{
  using (StreamReader sr = new StreamReader(svcResponse.GetResponseStream()))
  {
    JavaScriptSerializer js = new JavaScriptSerializer();
    string jsonTxt = sr.ReadToEnd();
  }
} 

At this point we have the Basic Authentication credentials coming into our service and we are providing authorization based on the outcome. However, like I mentioned prior we now are responsible for enforcing Basic Authentication to be used. The way we can do this is to send a response header prompting for credentials (which will happen in a browser) if they are not provided. In our code above, we are alerted of this condition when the Authorization header is not present. This in turn sends the client back a challenge for credentials. After submitting valid credentials, they will be authorized to our service. Just keep in mind again, since we are handling all authentication and enforcement of security mode in Basic Authentication, you will configure IIS to use "Anonymous Authentication."

So we still can use Basic Authentication with IIS hosted REST services using the webHttpBinding. Once this all sinks in and you test the code, you will see how all the parts come together. You have a choice at least with self-hosting or IIS with REST services and in both environments we have workable options. Since Basic Authentication is a HTTP standard widely known, and not some specific .NET practice or implementation, it is an obvious choice for securing your services. I would have to believe there be some improved support for WCF REST services in IIS going forward, but in the meantime we do have legitimate workable solutions for this hosting scenario.