*Words of Wisdom From The Elder

A few weeks ago we launched a new feature for one of our internal applications that leveraged Workflow Foundation extensively.  When working through a new technology you will always find curve balls along the way.  I like to call these shiny pennies and rusty washers.  For example, something may seem like a shiny penny when you first see it in a demo.   After much consideration of weighing the features vs the learning curve of the new technology you decide to use it a production environment.   Once something goes into production the game changes.  This is the point where you are going to be held accountable by the business or your client for the technology you chose to use.   This is the point where you have to go deep with the new technology because you have to support it once the “copy to production” button is pressed.  It is during this phase you find some of those shiny pennies are actually rusty washers. 

You will always find rusty washers when you work through a new technology.  There are even some recent examples of this I ran across in blog posts.  For example Jeff Barnes has a blog post about how WCF proxies can only fault once. If you’ve done ASMX proxies you know we don’t have to deal with this.  With WCF apparently the game has changed.  It is an example of a rusty washer with WCF that you wouldn’t know until you tried to put it into production.  Another example of recent that comes to mind is Ayende’s post about NHibernate one-to-one mappings.  Again, another example of something you wouldn’t find out when watching a demo.

To help you limit the amount of rusty washers you will run into with Workflow Foundation, I wanted to share our team’s experience in working through Workflow.  In this multiple part series we’ll look at some of the challenges the team faced and how we solved some of these.  I say “some” of these because we took side steps around the rusty washers we found due to our short time frame.   Hopefully this brain dump of information will save others time who are about to start using Workflow Foundation.  I’ll cover some of the in and outs where you will want to look into workflow and some of the pitfalls we had to work around (the rusty washers). 

First let me say that all in all we are extremely happy with the end product after launch.  We are going to be able to easily modify business rules and adjust quickly for the business.  As a matter of fact we have already had to modify our business rules and add new features.   Our end goal for selecting workflow foundation for this particular project was future agility.  Using Workflow allowed us to hit this mark, but not in the way we originally intended.  If we would have had more time we could have worked through the rusty washers and turned them into shiny pennies.  This brings me to my first point of this series.

It is just an API

The first thing I think everyone needs to understand about Workflow Foundation is it is just an API.  Or to borrow the word from its own name, a foundation to build upon.  It is really no different than building a house whereby you first pour the foundation and then you build something on top of it.    A lot of experienced .Net developers (including myself) think of Workflow Foundation as more of an extension to the core .Net 2.0 framework although it was released with .Net 3.0.  Technically this is true since .Net 3.0 is just that, an extension to the .Net 2.0 framework release whereby WPF, WCF, and WF were added. 

The reason I point out that WF is just an API is to set the initial expectation.  A lot of people I’ve come in contact with seem to think Workflow Foundation is in fact a shiny penny that will magically solve all of their problems.  I’ve heard them say, yeah it is cool, you just drag and drop and you’ve got workflow.  This is where I have to jump in.  The reality is it a core framework for building workflows and Microsoft provides several key components with the workflow framework.   Out of the box you get a:

1. Runtime – the brain of the workflow engine that is constantly running in memory and processing workflows
2. Component model – the pretty user interface that let’s you build workflows within applications or visual studio
3. Rules engine – well, it really isn’t an engine (it is just an API) but a processing mechanism to process business rules against workflows or use as a stand alone rules processor
4. Services – they provide various things such as how workflows should be processed (manual or default) and also things like persistence and tracking.   Services allow you to customize and tweak how Workflow Foundation works.  Example, if you don’t like the built-in persistence table structure you can create your own service and persistence store.

As you can see you get a lot out of the box.  All for the low low price of $0.00.  Not a bad investment huh? 

Question:  What do I do with all this?
Answer:  Anything you want that fits this tools job description.

The point I am trying to make here is Workflow Foundation provides a base model to build anything on top of it.  Take Winforms for example.  Microsoft didn’t ship a collection of pre-built out of the box applications.  Instead they provided the base framework so you, the developer, can build any type of Winform application you need.  Please don’t think of Workflow Foundation in any other way.    In other words, leveraging Workflow Foundation should be treated like an infrastructure investment, not an application investment.   In part two we’ll cover some of the key points you should focus on when building out your workflow infrastructure.  See you in part two!

It is easier to modify a workflow than it is to modify thousands of lines of C# code.

Like this post? 

I was setting up an internal blog site at my company today where developers and engineers can post blog entries.  After SubText was installed on the site I went to setup Live Writer.  This is the defacto blog editing tool I use for my blog and I was going to use it on the internal blog. 

When I went to setup the Weblog in Live Writer, IIS was configured with Integrated Authentication turned on (even though SubText uses forms authentication) and I got an error when configuring the blog of 401 unauthorized.  Obviously Live Writer wasn’t passing my windows credentials and this forced me to have to turn integrated authentication off on this site in IIS.  Not happy.  I really wanted to leave integrated authentication on because it would allow me to do some other things with custom permissions and the other reason being we can easily control who has access to the internal site via active directory roles. 

I can’t be the only person who has tried to do this.  Nevertheless this got me to thinking if Live Writer worked with Sharepoint 2007 to write blog articles which does use integrated authentication by default.  This isn’t supported it looks like either.  

If you haven’t ever used Live Writer, here are the screens you go through to setup a new blog:

1.  Choose either Live Spaces or another blog

2.  Enter Blog Site and Credentials

It is this screen that needs to have the option to pass Windows credentials so I can connect to my internal site or Sharepoint 2007.  Live Writer is still in beta so the team does still have time to get this feature added 🙂

For the past several days I’ve spent a lot of time trying to get up to speed using Windows Communication Foundation.  I’ve seen or watched enough “Hello World” demos of WCF over the past year to choke a good mule to death but I haven’t had a chance to write anything using WCF for real world experience.  I knew I’d get around to it eventually.  This is the point where you actually learn how to use a technology anyway.  Having done large scale applications with Asp.Net web services for quiet sometime I honestly didn’t figure it would be that difficult.   I was wrong.  My first real world venture into WCF left me scratching my head and feeling like a 12 year again. 

My reason for using WCF is I’m staring a new project which will be a Smart Client application used to build and manage business rules for different .Net applications leveraging the Windows Workflow Foundation rules API.  Since I was leveraging the .Net 3.0 framework anyway, I thought now was as good a time as any to jump into WCF. 

Once I defined my database structure and calculated which web service methods I was going to need, I created my ISomethingInterface contract which defined my methods.  I then implemented those methods in my service.  Very simple stuff at first, then I pressed F5 in Visual Studio and I was greeted with errors because my web.config file wasn’t configured.

I knew I had to configure the service and so off I went researching how to write the web.config file to expose my service.  I went to MSDN only to learn that I was going to spend the next several hours reading all of these different configuration options (WCF is flexible, but with flexibility comes more to read).  I gave it a college try trying to configure the web.config by hand and then eventually got frustrated because it wasn’t working.  Finally after doing some other searches I see a screen shot of a new item menu in the context menu when you right click the web.config file called “Edit WCF Configuration”.  I click it and get this:

If I’d only know this was there earlier.   After I got my service configured so it gave me a result other than an error page I *thought* I was going to get the same type of page you get with normal Asp.Net web services which is a page that shows you the methods available.  I was wrong.  I got this:

Where’s my list of web methods!?  Not there.  Again different from what I was expecting.  By this point I had resigned myself to throwing everything I knew about ASP.NET Web Services out the window because obviously previous knowledge was not really helping. 

I decided to absorb my new service in my client.  Since I had gotten burned by the right mouse click thing earlier I decided to see if the WCF CTP put a menu item in my project so I could generate the class file with svcutil.exe instead of wsdl.exe. Sure enough it was there.  This was the only thing that left me warm and fuzzy, something I had done before.   I then wrote a quick line to leverage the service (which I had placed in a separate Class Project) and it didn’t work.   The app.config file generated was placed in the project file where the service was generated, but not in the project the application was going to run from.   Luckily I was smart enough to just copy the one created for me and it worked.  Again, different. 

Feeling I had made progress I made the methods I wrote work, wrote unit tests for them and then baked them into the user interface of the application.  Then it hit me that I needed to call these services asynchronously.  So I typed “service.” and waited for intelilsense to see what the async calls were named.  They weren’t there!  Uh oh.

Doing some more digging I learned the svcutil.exe has a switch to generate asynchronous calls. The switch is /async.  Reading further there are different types of async calls and this is where I am currently at, trying to figure out what I really need to do and all the ins and outs of async calls in WCF.  Obviously lots of differences as I move further into WCF.

I did find a really good article which tells the developer what the differences between the two are, you may save yourself some headaches.  There are also some other documents nearby this one in the menu on MSDN that you may want to read as well.

If you’ve been waiting for the right job to come along, specifically a job opening at one of the top companies in the country, your wait is officially over.   If you are passionate about programming and designing large scale Enterprise systems where you get to have a direct impact on the business, we need you!

We have several .Net Engineer openings available at my current employer Quicken Loans.  You can’t be considered if you don’t apply and you won’t get preferential treatment with your resume if you don’t contact me directly!

We have openings in several different areas and need people who have skills in all sorts of areas including Asp.Net, Smart Clients and back-end people with certain talents ( Biztalk, Workflow, WCF, etc).  The great thing about these positions is you will become part of a team who loves to automate business practices, embrace industry standards, embrace change and adopt early.  You’ll be given all the tools you need to succeed as well as a culture that is unlike any you’ve probably seen. 

If you would like my email address run this code in a console application, or guess the output. 

I’m sitting in the Asp.Net tips and tricks sessions given by Scott Guthrie at the CodeMash conference.  Below are some of the items Scott covered.

Visual Studio Tips and Tricks

First up is the web site project model and the web application project model.  Essentially there are two types of web solutions.  One is a web site project which is the default in Visual Studio 2005.  It essentially allows you to store your web site in a folder0. For most content driven sites this is fine but this isn’t what we were use to in VS2003.  The other solution type is a download that was provided after VS2005 was launched.  Those of us that were using VS2003 didn’t like the new way with the App_Code folder and so on.  The web application project download provides developers the ability to get back to the way we were used to in VS2003.  Typically enterprise customers building large scale applications will utilize the web application project model and content sites use the built-in web site project.   There are also tools to migrate between the two projects if you decide to change your solution later on.  Here are the main things the web application project provides:

• All files contained within the project are defined within a project file (as well as the assembly references and other project meta-data settings). Files under the web’s file-system root that are not defined in the project file are not considered part of the web project.
• All code files within the project are compiled into a single assembly that is built and persisted in the \bin directory on each compile.
• The compilation system uses a standard MSBuild based compilation process. This can be extended and customized using standard MSBuild extensibility rules. You can control the build through the property pages, for example, name the output assembly or add pre- and post-build actions.

Optimizing VS 2005 Web Site Build Performance

If you’ve had build performance issues with Asp.Net there are some tricks and reasons why sometimes when you make a small change the entire solution rebuilds.  Instead of me getting into this to deep, Scott already has a lengthy blog article with screen shots that outlines what is happening under-the-hood and how to speed up build times.

Default Button

Since I write mostly in Windows Forms within .Net, this is something I knew but just forgot from lack of using it.  There are times when you have a web page that has multiple buttons on it.  By setting the defaultbutton property of the form tag you can declare which button will have its click event when the user presses the enter button.  This enables developers to identify the default button behavior when the enter key is hit.  It is cross browser and works on all modern browsers.  Without this feature you would have to write the JavaScript on your own.  The <asp:panel> control also supports this.  Here is an example:

<form defaultbutton=”button1″ runat=”server>

<asp:button id=”button1″ runat=”server” />

<asp:panel defaultbutton=”button2″ runat=”server>

<asp:button id=”button2″ runat=”server”/>

</asp:panel>

</form>

How to shift focus

You can write java script to shift focus to a certain input control but in .Net 2.0 you don’t have to.  In .Net 2.0 there is an attribute called defaultfocus which you can set on your form control to automatically shift the focus to the input control.  To take this a step further you can also do this in code: Page.SetFocus(control).

Another way shift focus comes into play is on validation errors.  When you are using the validation controls set the property SetFocusOnError=”true”.  By default it is false for backwards compatibility so it is something you have to set.  Setting it to true it will auto shift to the control throwing the error validation.  Very nice!

Using CSS Adapters

In Asp.net 2.0 the Control Adapter API was introduced which provides alternative rendering of controls.  What this gives you is a hook to modify or override a control’s rendering output.  All events and other things stay the same, but the output of HTML can be altered.  The CSS Adapter Toolkit, which can be downloaded from http://www.asp.net, makes this possible.  For example instead of the menu control outputting tables, it can output a div tag with ul and li tags.  This of course allows a designer to then style the menu as they would want. 

I asked the question if this is going to be baked into the next release of Visual Studio and Scott said it would be, but to what extent he wasn’t sure.  It is an interesting problem to discuss because you have an interesting design experience to overcome in Visual Studio.   While they could change the output of the menu control to display div tags by default it wouldn’t render properly without a style sheet.  While it is a little more work, I think the solution would be for the Asp.Net team to provide a configuration wizard to configure the control, or maybe extend the smart tag.  I would like to see the default option that is rendered from the controls to be all compliant HTML and then just simply switch a property to change the style to A, B, C, D, or Custom.  This is just an initial quick thought but hopefully you see where I am going. 

Register User Controls in web.config

 If you use user controls in your pages you typically have to add the user controls in the top of each page.  If you add this following code below into your web.config file, these controls will be automatically loaded for you and save you this step.  And for the record there is no performance penalty in taking this approach.

 Server Side Comments

If you have ever had a time when you wanted to not render a control in a page you may have just done this:

<!–  <asp:Button runat=”server” id=”button1″ /> –>

Taking this approach is still going to render the button and fire events it is just going to be hidden in the browser.  However, if you really want to remove the control from the page see the sample below.  Doing it this way will just skip this button all together. 

 Other Tips and Javascript Intellisense in Next Version of Visual Studio

 Scott also showed a lot of Ajax tips.  The one take away he mentioned that I didn’t know was the javascript debugger trick.  And while I am thinking about it he also noted that in the next version of Visual Studio code named Orcas, we were going to have full blow javascript intellisense and debugging capability.  No other IDE provides this right now (at least that I am aware of) so this is going to great for those doing lots of Ajax.  Folks, this is HUGE!  

About the debugger trick.  Essentially place this line in your javascript:  debugger;

When you do this the Visual Studio debugger will open to allow you to start a new instance of Visual Studio so you can step into the javascript and also view the contents of variables.