RickGaribay.NET

November PCSUG Meeting on WF 3.5 - Recap + Late Breaking Update on WF 4.0

Rick G. Garibay — Thu, 20 Nov 2008 15:09:34 GMT

If you attended the Phoenix Connected System User Group meeting last week you know what a great talk it was. For those who attended and would like a summary, and for those that were not able to make it, here's what you missed.

Recap

Rob Wisehart, Technical Team Lead at DriveTime Sales & Finance did a fantastic job introducing the group to WF 3.5. He provided an Overview and Essentials of WF and really did a great job of explaining why WF is important and why it matters. People are visual. We've learned thousands of languages since the beginning of time, but our Neanderthal ancestors had it right. We still communicate best with drawings and pictures. At least I do. Rob went on to talk about Sequential and State Machine Workflows and when each is appropriate. Rob really showed his experience with WF applications here, talking about the pros/cons of each worklfow type. Discussed as well was Hosting and Services. Just like WCF, WF needs hosting love too. In fact, any CLR process can host a WF service, and the models are quite similar.

My favorite part of the talk was on Custom Activities. Rob did an awesome job talking about why Custom Activities should be the preferred way to build WF applications. He really hit the nail on the head, talking about how, at DriveTime, they color code their Custom Activities, so that users (developers, and analysts) start to build that emotional connection with the software. For example, brown Custom Activities are always queue based activities while blue might be database related.

Of course, Rob closed out with a discussion on using WF as a WCF Service. While in 3.0 this required heroics, the story got better in 3.5, and today, if you are building a WCF service, using WF to orchestrate the logic should be compelling. On this topic, I believe that .NET 4.0 will really focus on WF from a marketing perspective, and WCF will be somewhat in the shadows of WF. This is OK, because .NET 3.0 and 3.5 was really all about WCF because it was a) a tremendous accomplishment that *will* change your life as a developer and b) fully baked. WF 4.0 will focus much more on the modeling aspects of building service-oriented applications, relegating WCF as a utility player. Of course, anyone that knows WCF understands that this could be further from the truth due to the incredible robustness and richness of the framework, but when a technology becomes commoditized, its a clear sign of success, both as a technology and from an adoption perspective. To say that WCF will commoditize cross-process communication between WF 4.0 applications is a very good thing indeed.

The Goods

Rob's deck can be downloaded from SkyDrive here:

Rob's code can be downloaded from SkyDrive here:

Swag

We closed the event with some great handouts, including WF+WCF 4.0 T-shirts courtesy of the Connected Systems Division, some laptop stickers and a group photo for folks that were lucky enough to get a sticker.

Late Breaking Update on WF 4.0

I also took about 5 minutes to talk about some of the changes that are coming in WF 4.0. Most of this content is a combination of what I learned at PDC along with a draft of a whitepaper that Kenny Wolf shared with me. While I've been asked not to circulate the paper until it is fully baked, I provided some of the biggest highlights and key points.

As I've discussed in earlier posts (http://rickgaribay.net/archive/2008/10/28/wf-4.0-big-changes-ahead.aspx, http://rickgaribay.net/archive/2008/10/30/more-on-wf-4.0.aspx), there are several new features and key changes coming in WF 4.0:

WF 4.0 ships with a completely new designer which very much resembles the look and feel that is being demo' d in Quadrant.
WF 4.0 provides full declaration of activities using XAML. While this is the same XAML that is used in WPF and WF 3.0/3.5, the file extension has been changed from .xoml to .xamlx.
There is a new activity model which makes all WF 4.0 artifacts activities. There is no longer the concept of distinguishing between Workflows and activities. In WF 4.0, all artifacts *are* are activities, and this includes Sequential Workflow Activities, State Machine Activities and a new Flowchart Activity. The key is that activities are the root of everything in WF 4.0 and activities compose other activities, be they custom activities or workflow activities.
Significant runtime performance, between 10% and 100%.
Better persistence and re-hydration performance largely due to the fact that the entire workflow need not be persisted as is the case in 3.0/3.5, but instead, because the XAML model is extended to every aspect of the workflow application, persistence can be managed at the activity level (see, there is a method building here).
Code Activities are dead. Don't write them anymore. Seriously, no Code Activities in WF 4.0.

These are just a few of the major improvements/changes coming our way. The next thing we talked about is what do to to prepare and what the migration story is.

WF 3.0/3.5 will run side-by-side with WF 4.0. WF 3.0/3.5 will run in the 2.0 CLR and WF 4.0 will run in the 4.0 CLR. What?! You didn't know there is a brand, spanking new CLR coming in NET FX 4.0? Better start coming to PCSUG meetings!
WF 3.0/3.5 can be composed within WF 4.0 activities using the Interop Activity. I joked here that this is like the P-Invoke of WF, and I don't mean that in a critical way, it's just necessary. If you look at how we pass variables around in WF 3.0/3.5 and the fact that in WF 4.0, variables are just neatly bound at the activity level with in/out semantics (and thus, different signatures) you need a bridge. The Interop Activity is that bridge.
There is no support for the Code Activity. Is there an echo in the room? Stop using them and start writing Custom Activities.
There will be a migration tool to port from 3.0/3.5 to 4.0, but like any tool, CSD will try their best but it won't be perfect.

Start preparing for WF 4.0 now by:

Choosing the fully declarative workflow template in 3.5
Do not use Activity.Initialize to initialize your activity, instead use Activity.Execute. The former goes away in 4.0.
Being diligent about scoping your variables within your 3.5 activities.
Think in terms of activities. Think in terms of your domain. Build activities.
Using WCF Send/Receive Activities in 3.5
Stop using Code Activities (there's that echo again)

As promised before, as soon as the guidance whitepaper becomes public, I will post it here.

Note: There will be no PCSUG meeting in December as we will be participating at the MSDN Unleashed Presents: The Best of PDC event on December 10th. Be sure to register for this event as seating is limited and when you arrive, be sure to fill out our PCSUG registration card so we can stay connected and inform you of what's coming in 2009.

MSDN Unleashed Presents: The Best of PDC

Rick G. Garibay — Tue, 18 Nov 2008 14:17:02 GMT

The local DE team is putting on an event on 12/10 to recap some of the highlights of PDC.

This is a good opportunity to educate our selves on what's coming and start to prepare now, so please register for the event using the link below.

http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032395730&Culture=en-US

Some may ask "Why would I want to go to this event when I can see all of the sessions online?" The answer is COMMUNITY. Did you know that Phoenix has over a dozen user groups, including the AZ.NET User Group, South East Valley .NET User Group, Tucson .NET User Group and Phoenix Connected Systems User Group? These user groups cannot be successful without YOU. Without YOU, events like this aren't possible.

Only YOU make it possible for the community to host more great events like the Scott Guthrie events AZGroups has sponsored and more opportunities to meet and get to know your local developer evangelists. Why not get off the coach (or come out of the cubicle) and join your local DE team and other peers for a great day of learning and networking? You never know who you might meet or what you might learn.

Plus, Rob Bagby designed a cool shirt for the event with a REST and WCF theme, and who couldn't use another cool shirt?

Hope to see you there!

November PCSUG Meeting on WF 3.5 Next Thursday 11/13

Rick G. Garibay — Sat, 08 Nov 2008 14:32:12 GMT

Join the Phoenix Connected Systems User Group at the Phoenix Microsoft office for an introduction to Windows Workflow 3.5 on November 13th.

Rob Wisehart, technical team lead for internal systems at DriveTime will provide a foundational introduction to WF, Microsoft’s premier framework for building workflow-enabled applications and services. This session will focus covering workflow types, basic activities, custom activities and demonstrating how to workflow enable a WCF service and compose it with other WCF services hosted in different runtimes.

In addition, I will be providing a whitepaper on what you need to know and how to prepare for changes coming your way in WF 4.0.

We will also have a bunch of cool swag from PDC 2008, courtesy of the Connected Systems Division. WF + WCF 4.0 and Oslo T-shirts, laptop stickers, and other cool stuff will be available on a first-come first-serve basis. In addition, I will have a few books on "M" Oslo's new modeling language which is only available in limited release.

As always, details regarding location and logistics can be found at www.azgroups.org or www.pcsug.org.

See you there!

Windows Mobile 6.1 for Samsung BlackJack II

Rick G. Garibay — Sat, 01 Nov 2008 22:45:15 GMT

I have been wanting to upgrade my phone since April of this year when Windows Mobile 6.1 was in pre-release. Even months after the new OS went CTP, ATT&T dragged its heels in providing even a modicum of support. Each and every in-store rep was completely and utterly clueless when I inquired once about every month. Alas, I was able to get my hands on the upgrade package for my BlackJack II directly from Samsung.

The upgrade process was pretty straight forward, and for BlackJack II users running Windows Vista, you should have no problems performing the upgrade if you go by the numbers: http://ars.samsung.com/customer/usa/jsp/faqs/faqs_view.jsp?SITE_ID=22&PG_ID=557&PROD_SUB_ID=558&PROD_ID=957&AT_ID=132707%20

There are oodles of new features in Windows Mobile 6.1, and you can find a great feature comparison here: http://www.microsoft.com/windowsmobile/en-us/meet/version-compare.mspx

Kudos to Samsung for doing the right thing for the consumer.

David Chappell on WF 4.0, Oslo & Dublin

Rick G. Garibay — Fri, 31 Oct 2008 03:52:12 GMT

Very timely brand spankin' new whitepaper has been published on MSDN: http://msdn.microsoft.com/en-us/library/dd200919.aspx

Nice job of tying WF, Oslo and Dublin together for the big picture. You will notice what I think is becoming a theme in messaging around 4.0 marketing which is placing a much bigger emphasis on WF than WCF. That is probably fair, as WCF owned the spotlight in the .NET 3.0 release, but I believe we will see more and more focus on WF as WCF takes a back seat in this release. To be sure, however there are great improvements in WCF coming our way including full schematization ala WF, new bindings and performance/persistence patterns.

David does a great job covering Dublin. My synopsis is that Dublin is COM+ application server (throttling, persistence) and BizTalk admin (tracking, HAT, etc) packaged up for WCF and WF and integrated into IIS 7 management tools.

More to come!

More on WF 4.0

Rick G. Garibay — Fri, 31 Oct 2008 03:38:23 GMT

Per my last post I have been eagerly pursuing more information on the impact of the changes to WF 4.0, and specifically, what these changes mean for applications written in 3.5 and new composable applications.

I had a great conversation with Cliff Simpkins, Technical Product Manager for the WF team who was able to answer a lot of my questions and provide some clarity as to what specifically has changed, why and how it affects WF applications.

Let's circle back to the points that Kenny Wolf made when we discussed the changes at a higher level and use these as talking points.

"First is delivering a truly model-based framework that allows every aspect of the WF to be represented declaratively."

In WF 4.0, all aspects of an activity are represented as XAML. Most importantly, this includes variables within each activity which are bound as input/output parameters from one activity to another. This is a significant change from 3.5 because variables are no longer scoped at the global workflow level, but instead are scoped to the activity level. And this is an important point. In WF 4.0, the paradigm is based on Activities, Runtime and Tooling. Activities form a logical workflow as a consequence of their composition. The focus is on the activities which consist of a root activity and child activities. The root activity is the orchestration of the child activities, and all activities exist as a logical workflow but are truly autonomous. They gain this autonomy by not being dependant on variables and state at the global level, but instead at each corresponding activity scope. This is huge when it comes to persistence as I'll discuss shortly.

"Second, was being able to truly participate in the repository ecosystem, which is key for deployment, management and operations scenarios."

This one should be obvious. XAML is the key to being able to serialize services and workflows in the repository. Reengineering how variables are managed by scoping them to the activity (I'll post some sample code soon) completes the picture. WF 4.0 (and incidentally WCF 4.0) will be repository ready, and this is the gestalt of the Oslo vision.

"And last, but not least was performance."

I don't yet have a full picture of how the performance improvements were attained. I suspect that there has been some runtime tuning, and I am eager to learn more here. However, a major positive consequence of the full schematization of the logical workflow is that the entire workflow does not need to be persisted, but instead, only the relevant activities. For example, if you have a workflow with 4 activities and the first two complete and the third activity waits for a stimulus before it resumes work, only the third and forth activity need to be persisted as opposed to the entire worklfow. I do still have questions about atomic versus long-running behavior, and this, along with other details will soon come to light.

Some more stuff

Another thing that you will immediately notice is that the designer has been completely redesigned, and there is a definite Quadrant influence. What is very cool is that both Quadrant and WF designer are using WPF. On this topic, I have to be honest. The design initially struck me as very drab. If you look at the picture I snapped in my original post you'll see a severe departure from the 3.0/3.5 aesthetic. The interesting thing though, is that as I sat in more sessions and touched and felt the designer it really grew on me. At the risk of sounding cliche, the simplicity of the designer makes for a very fluid user experience, perhaps less is more.

What about WF 3.5?

This is a logical burning question. First, let us all agree that WF 3.0 is not relevant to service developers, so I will ignore it, pretending it doesn't exist. The marriage of WF and WCF in WF 3.5 finally makes WF a compelling tool for composing services and this, by the way is going to be a common theme in the NET 4.0 timeframe and beyond.

So what about 3.5? Should we continue to build composable service-oriented applications with WF 3.5 or bite the bullet and build on early WF 4.0 bits? Well, according to Cliff, Office 14 is shipping with 3.5, and if Microsoft is willing to invest this heavily in 3.5 in a brand new product that hasn't shipped, you can imagine that it should be suitable for LOB applications as well as the enterprise. A better question is probably how bad the pain will be in upgrading from 3.5 to 4.0. I talked about the Interop activity which will be the bridge from 3.5 to 4.0, but we can't be so naive to assume it will solve all compatibility issues. I spoke with Jurgen Willis who commited to the early guidance paper I mentioned very soon. As promised, when I get it, you'll have it here.

In the meantime, if you want to watch live recordings of the following PDC sessions on WF, I've provided the links below:

WF 4.0: A First Look: http://channel9.msdn.com/pdc2008/TL17/
WCF 4.0: Building WCF Services with WF in Microsoft .NET 4.0: http://channel9.msdn.com/pdc2008/TL06/

WF 4.0: Big Changes Ahead

Rick G. Garibay — Tue, 28 Oct 2008 16:42:38 GMT

If attendees in Kenny W's session on WF 4.0 yesterday at PDC 08 are like me, they are both elated, shocked and awed in the lead architect's discussion on major, major changes heading our way in Windows Workflow 4.

When I attended the WCF and WF SDRs in Redmond back in April, Kenny, Ed Pinto and his team talked to us about new workflow types and activities and sought our feedback. It was evident that these improvements that were afoot were positive, and building on a foundation that I had only recently grown to love having been primarily focused on WCF for the last 2 years. In fact, I have pretty much shifted my focus completely from BizTalk Server to WF, WCF and service bus technologies.

Anyway, among the improvements/features discussed were changes to existing workflow types and new workflow styles including sequential, flowchart, state machine and a unification of activities and rules. Also reviewed were improvements to XAML support for modeling and deployment. So, I was very interested to see how far these committed improvements had gone since April, but I was not prepared for such a big surprise.

A framework for writing workflow applications, now in its second release (WF 3.5) is being completely overhauled, from the ground up. Kenny asserted that these drastic changes were necessary to deliver on the changes the team had already been discussing for months, but had expertly kept the details of just what that meant safe within the walls of building 43.

So what does this mean?! This is a question anyone working today with WF is asking. How drastic is the impact to my applications? What should I know about what's coming so that my existing and future investment in WF can be leveraged. Is this another ".NET Remoting has been deprecated" situation?

I couldn't wait for public messaging to address this burning concern, so I talked to Kenny after his session and asked a number of questions, which he was, as usual, very open and willing to answering.

My first question was around the impetus for such a major overhaul. Kenny shared that they focused very, very deeply on key customer requests and opportunities based on earlier versions of the framework. There were 3 feature types that resonated most. First, is delivering a truly model-based framework that allows every aspect of the WF to be represented declaratively. Second, was being able to truly participate in the repository ecosystem, which is key for deployment, management and operations scenarios. And last, but not least was performance.

Earlier in his talk, Kenny cited intriguing improvements, including 10x to 100x performance improvements and persisted workflows becoming essentially "free" with WF 4.0. In our more one-on-one discussion after his talk, he used the analogy of swinging at a baseball with a wooden baseball bat. While the wooden baseball bat is effective, it feels a bit heavy, if not clunky at times. When you pick up an aluminum baseball bat, it is markedly lighter, and feels significantly more aerodynamic. WF 3.0 and 3.5 work, but WF 4 is a new and improved aluminum baseball bat.

While the metaphor was effective, of course, I wanted to know what, specifically I should stop/start doing immediately and ensure my clients receive this guidance. Kenny had partially addressed this earlier in his public talk by pretty much prescribing that WF developers should stop using custom code activities and opt for custom activities instead. In fact, he demo'd a new "Interop" activity that allows your WF 3.0/3.5 custom activities to talk to WF 4.0 activities and workflows. I must admit that this does feel a bit like a P-Invoke for WF, and I don't mean that to be critical, it is just an observation.

Obviously, there are many more questions to be answered, but the first takeaway is to stop using custom code activities and focus existing efforts on developing custom activities, which are really the way we should be developing for WF anyway. To help answer some of the other burning questions we all undoubtedly have, Kenny committed to do his best to provide some prescriptive guidance by the end of the week to fill in the rest of the gaps, or at least provide some early guidance to get begin to prepare.

As soon as I get my hands on it, I will post it, along with any other gems of wisdom here.

On a final note, lest my prose present me as stoic, of course these changes make me nervous. I have yet to appreciate the full impact of these changes, and am eager to learn more. This said, I have to applaud Microsoft CSD for doing what is right, even when it is painful. We've seen this happen before (.NET Remoting) and will likely see it again. It is both the cost and benefit of forward progress in our great field of software engineering.

New Article in Nov/Dec 2008 Issue of CoDe Magazine

Rick G. Garibay — Fri, 24 Oct 2008 14:10:50 GMT

My new article on Microsoft BRE is out in the Nov/Dec issue of CoDe Magazine.

You can find CoDe Magazine at bookstores like Barnes and Noble, or you can read the article here: http://www.code-magazine.com/Article.aspx?quickid=0811071

As always, I'd appreciate any feedback you may have. I would also like to thank Charles Young for his time and knowledge in providing a technical review during the editing process.

If you are not a subscriber, and you like this, or any other articles at Component Developer Magazine, I hope you will consider subscribing: https://www.code-magazine.com/Subscription.aspx

This is a truly exceptional team to work with, and despite their headquarters being severely impacted by hurricane Ike, they still shipped this issue (that was in production during the storm) on time.

On a related note, if you will be attending the AZ .NET User Group or Phoenix Connected Systems User Group meeting in November (info here: www.azgroups.org) Scott and I will have complimentary issues available as usual. Just another example of how dedicated the CoDe team is to the developer community!

Building Service-Oriented Applications with Windows Communication Foundation

Rick G. Garibay — Tue, 21 Oct 2008 04:50:15 GMT

Thanks to everyone who came out to my talk at the Phoenix Connected Systems User Group meeting last week.

As promised, here are the links to the presentation materials and solution download.

Be sure to join us on November 13th for a foundational discussion on Windows Workflow Foundation (WF). Abstract to follow soon.

Not a Typical Day at Work

Rick G. Garibay — Tue, 21 Oct 2008 04:44:23 GMT

Not every day you get to come into work to find a movie being shot across the street, especially in Phoenix.

I came into the client site this morning to find a live crew shooting a scene from the new file “Middle Men” staring Luke Wilson, Robert Forrester and James Caan among others: http://www.imdb.com/title/tt1251757/

This picture is from the parking garage directly behind the movie set. They had Monroe street blocked off from Central and backwards, so I was able to squeeze in a few shots from my phone, this being among the better ones. The scene below is in the alley next to a favorite downtown watering hole called Seamus McCaffrey's. On the left, near the edge is Luke Wilson who approaches Robert Forrester who has the trunk of a Cadillac open and is holding a bat. After a few seconds of discussion, Luke Wilson appears to capitulate and then runs off towards stage left.

Apparently, the film is about the beginning of a certain lucrative business that has some roots in Phoenix- go figure.

For those interested in viewing a sequential frame-by-frame sequence of the scene, you can save the following shots to your local machine and use a slide viewer feature to see the action (row 1, left to right, followed by row 2).

Paul Newman Jan 26, 1925 - Sept 26, 2008

Rick G. Garibay — Sat, 27 Sep 2008 15:53:08 GMT

I very seldom write on personal topics here, but I am very saddened to make an exception today.

Paul Newman was a remarkable human being that I have admired as long as I can remember. His wit, charm, kindness and humility are traits that I have always looked up to him for (OK, he was very, very cool too).

In addition to being a fantastic actor, starring in some of my favorite films such as "Butch Cassidy and the Sundance Kid", "Cool Hand Luke" and "The Sting" (if you haven't seen these, I highly recommend you do one day), he was an avid philanthropist, founding The Newman's Own Foundation in 1982. The Newman's Own Foundation oversees the "Newman's Own" product line which donates every dime of profit to charity, with donations in excess of $250 million. He also founded the "Hole in the Wall Camps", which offers a respite for very ill children who can go to camp to forget about their illness and just be kids for a few days.

I remember watching an interview on Letterman a couple of years ago. David was asking him about some of his passions, which included automobile racing and beer. In that interview, Paul referred to beer as "the common man's drink". This is what always impressed me the most about Paul Newman. Despite his tremendous success as an actor in the hay day of Hollywood, he never lost touch with himself, his family or his place on this earth. He had this keen awareness that in addition to very hard work, success can be attributed to luck just as much as one's own efforts.

So today, with great sadness, I raise a pint to celebrate the life and light of Paul Newman who despite being deeply missed, has left a lasting impression in my life and a legacy that will continue to give for years to come.

Using PowerShell to Manage Network Interfaces and Windows Services

Rick G. Garibay — Fri, 26 Sep 2008 22:02:26 GMT

PowerShell is a new scripting language that allows you to interact with applications, services and objects as objects. It is a .NET application which shells commands out on your behalf. This is very powerful, because it allows you to leverage the strengths of an object oriented model within your scripting tasks with a very terse, yet simple scripting language. Because it is written in .NET, you can access .NET types, objects and WMI objects from a command prompt.

My current workstation runs Windows Server 2008 Standard Edition with Hyper-V. I use the host/parent partition as my office, and have a number of child partitions that are integrated into a Windows Server 2008 Domain. Needless to say, this configuration gives me everything I need to develop, test and integrate multiple Server OS', platforms and technologies, and is my environment of choice for developing production code. It still amazes me how far we've come in such a short period of time. Not too long ago, I remember setting up similar lab environments at home running Windows NT 4 and Windows Server 2000 on dedicated physical machines.

Anyway, I have to say that I am absolutely delighted with my environment, but it took me some time and effort to learn how to tune Server 2008, and this is all well documented in previous posts. One of the the things that I do to keep performance high is that I only have the 3 services required for Hyper-V running when I need them. In other words, if I am only working with email and writing documents or design drawings, I don't need to have the Hyper-V services running because they are resource intensive. In addition, I only want my loopback adapter (that provides me with a virtual LAN for all of the child partitions on my domain to communicate) enabled when I need it to be. One reason for this, is that if I leave my loopback on and reboot, boot times can take up to 10 minutes because the loopback is configured to use my domain controller as the primary DNS server, which is a VM. Because the DNS Server only runs when my Domain Controller VM is up and running, the VM will only come up when I start it. As a result, Windows tries and tries to reach the DNS server for the Loopback adapter until it finally gives up (If anyone knows how to change this timeout, please shoot me a note or post a comment).

So, I only want Hyper-V services running when I need to work in my development environment, and I don't want my loopback enabled unless it needs to be. For a while, I was managing this as follows...

First, I set the following services to "Manual", so that they do not start automatically:

vmms: Hyper-V Virtual Machine Management
vhdsvc: Hyper-V Image Management Service
nvspwmi: Hyper-V Networking Management Service

The service names are a bit obscure, but the "friendly" names are pretty self explanatory. When I need to start my development environment, I would go into Server Manager, and start each service one by one.

Next, I would enable my loopback adapter so that my child partitions can communicate with each other.

All together, this resulted in a number of clicks, which was somewhat mundane to do every time. Worse, once I enabled the loopback, I often would forget to disable it before shutting down (remember, servers running Hyper-V do not support hibernation). For a while, I thought about writing myself a sticky note and posting it to my forehead so that I would not forget to disable the loopback, and finally, I decided to create an easy button for starting and stopping my development environment.

This is where Powershell comes in.

Using PowerShell to Query and Manage Network Adapters

The first thing I did was figure out how to talk to my network adapters so that I could enable and disable my loopback as needed. It turns out that Microsoft provides a WMI object called Win32_NetworkAdapter. The object exposes a bunch of properties for working with an instance of a Win32_NetworkAdapter:

In addition, there are 4 public methods that are exposed, and well documented as shown below:

To enumerate all network adapters on my host/parent partition, I issued the following command:

        1: Get-wmiobject win32_NetworkAdapter | format-table 
  

PowerShell lists each adapter and certain properties in a tabular format because I added a pipe and format-table parameter:

To identify the instance that corresponds to my loopback, I simply need to find the "Internal VLAN" instance above, which has a DeviceID of 17:

Next, I want to retrieve an instance of the adapter with a DeviceId of 17, so I issue the following statement:

       1: Get-WmiObject win32_networkadapter | where {$_.DeviceId -eq 17}
  

The where keyword uses a bracketed expression to evaluate the condition. The "$" is a temporary variable, which is similar to the "this" keyword in C#, which provides context for the current instance. The "-eq" operator is the equality operator in PowerShell. So, we are querying all adapters for the adapter with a DeviceID equal to 17. The above command returns the following:

Notice that each property is an actual documented property of the WIN32_NetworkAdapter object. If we have access to properties, it would be helpful to determine if the adapter is enabled or disabled. To do this, I assign the adapter to a variable called $adapter as shown below, and then I get the value of the Availability property:

The value of the Availability property is 3. Referring to the WIN32_NetworkAdapter documentation, I can see that a status of 3 indicates that adapter is on, and running on full power.

Are you getting the hang of it yet? Hopefully, the interaction with PowerShell should feel object-oriented because it is! We are getting a reference to the WMI shell of the adapter and then using it's get accessors to get the value of the public properties. So, if we can get a reference to the adapter, get properties, we should be able to call methods on it, right?

To disable the adapter, I simply call the Disable() method on my $adapter variable:

Now, to confirm that the adapter is disabled, you can look at Network Connections and you will see that the Status is in fact Disabled. To do this programmatically via PowerShell, you can use the ConfigManagerErrorCode property which is also documented. Get a new instance of the adapter, and call the ConfigManagerErrorCode property on it as shown below:

A return code of 22 can be matched to the table in the MSDN documentation:

Now, enable the adapter by calling the Enable() method:

A return code of 0 indicates that the adapter is enabled, and working properly:

As you can see, PowerShell is a very easy to use, yet powerful tool for managing system objects in an object-oriented manner. You don't need to worry about writing VBScript or C# to accomplish simple administrative tasks such as enabling and disabling a network adapter. As you might imagine, the real power comes in being able to run a series of PowerShell commands in a batch, perhaps at the click of the button. This is exactly what I'll cover next.

Using PowerShell to Query and Manage Windows Services

You'll recall that I only want the 3 Hyper-V services to run when I need them, so what I want to do is create an "easy button" to toeggle my development environment on and off.

The "On" should:

Enable my Internal VLAN Adapter
Start the Hyper-V Virtual Machine Management
Start the Hyper-V Image Management Service
Start the Hyper-V Networking Management Service
Get me a cup of Starbucks coffee

The "Off" Button should:

Disable my Internal VLAN Adapter

Disable the Hyper-V Virtual Machine Management

Disable the Hyper-V Image Management Service

Disable the Hyper-V Networking Management Service

I've already covered how to manage network adapters using PowerShell as a primer, so I'll jump right into working with Windows Services. As with any program, sometimes it is helpful to group commands into a subroutine. In PowerShell, these functions are referred to as cmdlets (prounounced "commandlets"). You may not realize this, but you've already been working with cmdlets if you've tried the commands I covered above on your own machine. The get-wmiobject command is actually a cmdlet that provides a reference to the WMI object specified as the parameter. You could accomplish this without the cmdlet, but why would you want to?

Fortunately, a cmdlet is also available for working with Windows Services: get-service.

To get information about a particular service, simply call get-service with the service name. The actual service name of the Hyper-V Virtual Machine Management service is "vmms", so issuing the get-service vmms command returns a few properties including the Name, DisplayName and Status of the service.

Starting and stopping the Hyper-V Virtual Machine Management service is as simple as calling the appropriate method: Stop() to stop the service and Start() to start it. While you could use a variable called $service to store the reference to the service object, an abbreviated way to accomplish this is shown below:

         1: (get-service vmms).Stop()
    

Now, when you issue the get-service vmms command, you can see that the Status property is "Stopped":

Starting the service back up is as simple as calling Start() on the cmdlet expression:

Building the "Easy Buttons"

There may very well be a more sophisticated way to do this, but I created two batch files, one called "Start.bat" and the other called "Stop.bat" and placed them in my documents folder. Each file contains the appropriate PowerShell syntax as shown below:

Note, to re-use variables across PowerShell sessions, you must first configure a PowerShell profile: http://msdn.microsoft.com/en-us/library/bb613488(VS.85).aspx

Next I created two desktop shortcuts, appropriately named "Start" and "Stop" and set the target to each corresponding file.

Now, I have two "Easy Buttons" for toggling my development environment on and off. While I can't guarantee that I won't forget to press the "off button" before shutting down, it is a heck of a lot easier than going through the contortions manually.

One last note. If anyone finds or builds a cmdlet that runs to Startbucks and picks up a medium drip with 1.5 Sweet & Low and delivers it to my client site, please let me know :-)

Comparing WCF Binary Encoding to .NET Serialization

Rick G. Garibay — Fri, 19 Sep 2008 14:42:03 GMT

A common question that I get from folks at my talks as well as clients is how binary performance of WCF stacks up against .NET Remoting. To quickly level-set, the lingua franca for all messages that WCF exchanges is SOAP/XML. However, out of the box, WCF provides 3 means for representing the message payload on the wire:

Binary
Text
MTOM

Of the encodings above, only Text and MTOM are interoperable (and I'll cover these in upcoming posts), but sometimes, in a .NET to .NET messaging scenario, encoding the message in a binary representation will yield smaller payloads and thus more efficient message transfer (especially when pairing a binary message with TCP). It is important to note that regardless of the encoding used to serialize the message, the message itself is SOAP and thus can be de-serialized according to the SOAP standard in use on the client and server stack.

It is widely documented that the System.Runtime.Serialization assembly introduces an optimized byte representation for packaging XML/SOAP via the XmlDictonaryWriter which can be found in the System.Xml namespace within the System.Runtime.Serialization.dll.

In short, WCF leverages the XmlDictionaryWriter which provides a factory method for getting a binary writer which is capable of taking an XML document and serializing it to a proprietary binary format:

XmlDocument doc = new XmlDocument(); 
doc.Load(from); 

FileStream stream = new FileStream(to, FileMode.OpenOrCreate); 

XmlDictionaryWriter binaryWriter = XmlDictionaryWriter.CreateBinaryWriter(stream); 
doc.WriteContentTo(binaryWriter); 

binaryWriter.Flush();

The code above takes a file containing the following XML and loads it into an instance of the XmlDocument:

Then, using the binary encoder, the stream is written to a file called "CustomerWCF.bin" on disk, which when opened looks like this:

Similarly, if I want to use the "legacy" BinaryFormatter, which ships in the System.Runtime.Serialization.Formatters namespace of mscorlib, I can write the following code which loads and serializes the same Customer.xml file:

XmlDocument doc = new XmlDocument(); 
doc.Load(from); 

FileStream stream = new FileStream(to, FileMode.OpenOrCreate); 

BinaryFormatter formatter = new BinaryFormatter(); 
formatter.Serialize(stream, doc.InnerXml);

This time, the contents is written to a file called CustomerNET.bin which resembles the following:

Of course, both of these files are encoded in binary, so when you open them in notepad or some other tool (in this case I am using Visual Studio) you will see some semblance of the original message with corresponding octal representation for each byte of data. It is evident, in just looking at the octal representation that the CustomerNET.bin is larger.

In fact, it turns out that the CustomerWCF.bin file has a size of 98 bytes, compared to the CustomerNET.bin file that has a size of 205 bytes.

Customer.WCF.bin:

CustomerNET.bin:

Given this very simple example, you could say that the WCF binary encoder produces a payload that is roughly half the size of the BinaryFormatter!

It is important to note that the these are different binary representations, that are each proprietary and therefore not interoperable outside of the .NET Framework. In fact, the WCF version of the Customer.xml contents is only supported within .NET 3.0 and later, and is naturally the encoder that is used when exchanging binary messages with WCF. The cool thing is that you can leverage this encoding outside of WCF, provided you have .NET 3.0+ on both sides of the wire.

Forthcoming: Exploring Text and MTOM message representations.

Comprehensive Series on WCF & REST

Rick G. Garibay — Mon, 08 Sep 2008 18:35:23 GMT

My friend Rob Bagby has done an excellent job putting together a series of primers on REST with WCF.

REST is gaining more and more attention recently as a great way to expose services over HTTP that do not require WS-* features. I think if you spend some time with REST, you will not only learn an alternate way of working with services, but you will also learn or re-learn the fundamentals of the HTTP protocol, which will be helpful regardless of what approach you take to building Web Services.

Rob's blog series can be found below:

Rob has also put together a series of screen casts on the subject which can be viewed here:

endpoint.tv - Controlling the URI in RESTful WCF with Rob Bagby

deCast - Creating a HI-REST GET Service with WCF 3.5

deCast - Consuming a HI-REST GET Service From Silverlight 2 (Beta 2)

endpoint.tv - Caching and Conditional Get with Rob Bagby

To catch up with Rob, be sure to check out his upcoming live events here: http://blogs.msdn.com/bags

Hyper-V Parent Partition Filesytem Access Not Working?

Rick G. Garibay — Fri, 05 Sep 2008 16:30:27 GMT

With Hyper-v, if you want to access the parent partition (host) file system, or attached USB drives, the only way to do so is through a UNC or IP connection from the child partition (guest) to the parent (host). To do so, you will have to create a network and bind it. You can read about how to setup an Internal Network in a previous post.

At times, you may find that despite being able to ping the parent from the child, and even resolve DNS names, you get a networking error:

For whatever reason, I have found that restarting the "Server" service on the parent resolves the issue. As you might imagine, the Server service is responsible for managing file sharing, among other things. What is strange is that it is already running, but every time I run into this issue, restarting the service is the fix.

Hope this helps someone out who could otherwise spend hours pulling their hair out debugging networking issues.