dougherty distilled

SharePoint 2010 Workflow

One thing I wanted to get out of the SharePoint Conference 2009 is to see how much has been added to the built-in workflow and how it compares to capabilities of some of the external tools, K2 being the one I'm most familiar with.  Whoops...the the K2 and Nintex sessions were scheduled at the same time as the SP workflow session...by accident?...a little friendly competition, maybe? (they did reschedule sessions)

So what is new with 2010:

• Visual display of running workflow progress
• Do not need to be tied to a tied to a list item
• Site workflows - not just tied to a content type or list
• Reusable declarative workflows can be designed
• Import workflows from SharePoint Designer to Visual Studio
• New actions (read/write to external lists, doc set and record mgmt, manager, user profile lookups)
• Solution packaging (.wsp)
• SharePoint Designer 2010
• Ability to edit out of the box workflows (Copy or Modify, Example: logic for whether approver is needed or not)
• data binding enhancements for including workflow data and specifying format
• sort of straightforward UI for If/Then/Else targeted as business users
• has the ribbon (it's everywhere now)
• Impersonation control (run as workflow author instead of workflow initiator for access to resources)
• Two-way import/export between Visio and SharePoint Designer
• Task process customization (what to do when a task is assigned, pending, expires, deleted, completes)
• Create custom declaritive activites in Visual Studio that you can then use in SharePoint Designer

So, while there are bunch of good improvements, there still seem to be limitations that keep the other workflow products and/or custom Visual Studio development:

• Create non-declarative workflows (non-sequential state machines, looping) - seems like a pretty big deal
• Custom forms or use of different forms at different points in the workflow (I think you have to use the same InfoPath form or list form throughout) - another big deal
• As far as I can tell workflows are till tied to a site so no easy way to see all my tasks across sites
• I'm still not sure what the versioning story is and need to get more understanding there
• No statistics across workflows or view of all the running instances of a particular type
• The SharePoint Designer is improved, but still kind of confusing - still need tech-savvy user in my opinion
• Visio designer was ok for light-weight framing, but didn't add a ton of value and it looks like once you import it, you don't get to work with it in the visual display which seems like an odd experience

In a future post, I want to start comparing in a grid the different workflow options (SP2007, SP2010, blackpoint, blackpearl, Nintex, others) and the features they have and really understand which tools are right for different scenarios.

SharePoint Conference 2009

SharePoint Conference 2009 kicked off this week with a keynote address from Jeff Teper (CVP, Office Business Platform) and Steve Ballmer (you know who he is).  I thought I'd highlight some of the main themes touched on during the presentation and try to drill in to detail in some other posts as I dig in more.

• Developer Experience Improvements
• Install on Vista or Windows 7 (huge - no more need to do dev on VPC)
• Visual Studio 2010 tooling enhancements (F5 experience, designers for packaging)
• Developer dashboard - can enable page trace info with more detail
• SharePoint Designer improvements (they say it's even for devs who are used to Visual Studio...hmm...)
• SharePoint Online
  • Hosting SharePoint in the cloud instead of onsite
  • This could be for intranet or extranet solutions
• Business Connectivity Services
• New two-way access to outside business data that was previously read-only
• Enhancements to Search
  • FAST search (FAST was acquired by MS)
  • Improved search options and display, including preview support of Office docs
• Improved User Interface/Interaction
  • UI is ajax-enabled and the Ribbon is now used for context-sensitive actions (Check-out, insert web part, etc.)
  • Better support for xhtml standards and multiple browsers
  • Remote/Offline access through SharePoint Workspace (next generation of Groove)
• Lists and Document Library Improvements
• Support for tens of millions of docs or items
• "Taxonomy management" - controlling the metadata values at the enterprise level
• Improved UI for slicing the data
• Easier Administration
• PowerShell is now what is used for everything (over 500 commands, "what if" command to preview what would happened, Remote managment from Windows 7)
• Usage logging to database that will have a published schema to allow custom reports
• MS has been "dog fooding" by doing the SharePoint Online hosting (i.e. they want it to be easy, too)
• Social Computing
• Social tagging and additional ways to follow and find people (Facebook-like features in the workplace)
• Encouraging more use of my sites
• Multiple SKUs now depending on intranet/extranet/internet/search

I was a little surprised that workflow wasn't really discussed much since that is something I've looked at a lot.  There was a lot of focus on the SharePoint Online offering which is probably because of the complexity of managing a SharePoint infrastructure.

The talk definitely highlighted that SharePoint is a platform.  As I've been talking to people attending the conference, that is apparent.  SharePoint 2010 (and 2007) is a beast and everyone is trying to understand how to best use it for their needs.

Using VSTS to Quickly Test Scenarios with Add-In Applications

I've been working on a project that has a suite of applications that act as Add-Ins to various host applications.  Testing a variety of scenarios can be slow if there is setup is involved, especially in a development environment.  While you want to test going through as much of the your extensibility interface as possible, but you don't want to have to launch the host application, navigate through a few screens, and then launch just to test a small code or situational change. 

This is a great situation to use a VSTS Unit Test.  Some might say "Duh," but for people who haven't thought about using unit tests for interactive testing, as opposed to the more traditional tests that assert success criteria and get executed after every build, I thought it might be helpful to walk through a simple example.

So I built a simple application, MyIntegrationApp.  It has a Controller class that controls the flow of the app and exposes a Launch method that would be called by our fictional host application.  In a real scenario, we may expose that method to be called via COM by an existing application.

Then I created a unit test project, MyUnitTests, that has test class, MyIntegrationAppTests.  MyUnitTests also has a couple config files under a Configuration folder and subfolders that will be used during the tests.  Finally, the unit test project references MyIntegrationApp.  The figure to the right shows what the source tree looks like.

So let's look at the tests themselves.  In my fictional scenario, the Controller class needs to load a configuration file, MyIntegrationApp.config.  So I want to test three scenarios:

1. There is a good config file in which case a success message will be shown
2. There is a bad config file in which case an error message will be shown
3. The config file is missing in which case a different error will be shown

So there are three test methods as seen in the next image. 

The first two methods use the DeploymentItem attribute to copy the specified config file.  The third method doesn't copy the file.  All three call a common private method that launches an instance of MyIntegrationApp.

One tip to keep in mind is that you need to set the deployment items to Copy Always and build the unit test project so that they get copied to run folder.

The last thing to do is simply run the tests.  To do this you open the Test View and right click on the test to run.  Then select Debug selection as seen in the final image below.

So in summary, I think this can be an easy way to set up some tests that can help speed up the development and testing of Add-In applications.  All the source code can be downloaded from here.

SharePoint Dispose Check Tool Is Here!

Check it out: http://code.msdn.microsoft.com/SPDisposeCheck

I just fired it up and it looks like it will be really helpful.  It confirmed a chunk of bad code I was just looking at along with a handful of others.

 The XML mode seems to bomb out (as others have posted), but piping to a file seems to work fine.

Diagnosing and Fixing SharePoint Out of Memory Exceptions

I’ve been working on supporting and enhancing a client’s custom SharePoint solution for a while now.  The solution involves custom application pages and custom web services hosted in SharePoint, both which use the SharePoint object model heavily.  As the number of users (1000+) and number of sites (45000+) increased we started seeing some Out of Memory Exceptions cropping up.  Simply stated, these errors are not good.   They generally require restarting your app pool or performing an iisreset to fix and get your app back up and running.

I thought it might be helpful to others to document how we went about identifying suspect areas of the application and how we fixed them.  First it helps to understand a little more about what is really going on.  We’re not actually running out of memory on the server.  According to the technet article Dealing with Memory Pressure Issues in WSS and MOSS, what is really happening is that unmanaged resources are not being disposed of properly when using the SharePoint object model.  Eventually the worker process, not the server, is not able to allocate more memory and the exception occurs. 

We have a good infrastructure with beefy servers and a load-balanced farm of front ends.  So really we shouldn’t have issues due to hardware.  The volume alone shouldn’t cause the problem, either.  From the infrastructure angle, we have do have plans to move to 64-bit servers soon which will further reduce possibility of memory pressure.  We also set a memory threshold on the app pools to restart which may have helped in the short term.  But in reality, the problem is probably due to an application issue that has just become more noticeable under volume.

So for starters you need to be sure code is to following Microsoft’s Best Practices for using the SharePoint Object Model:

• Best Practices: Using Disposable Windows SharePoint Services Objects
• Best Practices: Common Coding Issues When Using the SharePoint Object Model

I also recommend Roger Lamb’s SharePoint Development Blog as a good resource to help reinforce and supplement the Best Practices articles.
When you have a large code base like the project I’m working on, it’s time consuming and not necessarily easy to review every line of code to make sure it was written with proper disposal in mind.  There is supposed to be a tool coming from MS that will help with this which will be great. (UPDATE: Apparently the SharePoint Dispose Checker Tool is ready now.  I haven't tried it yet but you can find it here. I haven't tried it yet.) But if you’re actually having an issue with Out of Memory Exceptions, you need to help pinpoint the problem quickly.

Looking at the SharePoint logs in ..\12\Logs, you can will see entries that read “An SPRequest object was not disposed before the end of this thread.  To avoid wasting system resources, dispose of this object or its parent (such as an SPSite or SPWeb) as soon as you are done using it…”
To find more info on what code is responsible, you can find or create the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\HeapSettings and then create a new DWORD named SPRequestStackTrace with the value 1 under this key.  If this is not set, the error message above will contain this info.  Once it is set, you’ll be able to see the stack trace in your custom offending code.   Then you can go identify the cause of the problem and fix it, by adding “using” clauses, for example.

One scenario that wasn’t apparent in the Best Practice documentation (at least to me) is that you need to use SPxxx objects (SPList, SPFile) retrieved from an SPSite/SPWeb before disposing the SPSite/SPWeb.  Otherwise the SPxxx object may recreate the SPSite/SPWeb or similar SPRequest object that doesn’t get disposed.  So in general, writing methods that return SPxxx objects is not the best way to go, because you probably disposed of the site and web in the method.  However it is often nice to break up logic in to smaller private methods for readability and reusability.  In this case, you just have to make sure the SPWeb and SPSite are passed in to those methods instead of using and disposing them in the methods. 

I'd avoid passing SPxxx objects outside of class interfaces if possible so that you retain control and make sure the objects are handled correctly.  I would have preferred that Microsoft designed a little more for discoverability of this last issue.  My preference would be that if I checked SPFile.Exists I would get an error that said "Parent site has been disposed" as opposed to "helping" me by recreating the parent site/request which causes the memory leak. 

Your Code Sunk My Battleship!

Check out my new article on Coding4Fun.  It describes a game I built for an internal coding challenge here at Clarity.

Practicality when Branching in TFS

Here at Clarity, we hold infomal internal training events a couple times a month to discuss new technologies, tools, or other things related to software development.  Recently, Don Peterson led a discussion on source control management strategies for development teams using Team Foundation Server.  Some of what was discussed was based on Microsoft's Branching Guidance white paper.  I've read the paper before and I think it is a good read, full of good info.  The focus of our discussion the other day was Release Isolation since that is probably the most commonly used strategy.  The paper shows branching for release isolation in this way:

I agree with the approach in spirit, but I think it's worthwhile to ask yourself a few questions to see if you need this much complexity:

1. How big is my team?
2. Do we need isolated feature changes? 
3. How does development process work?

For small teams (< 10 developers), I think it can be in your best interest to simplify your branching structure to something more like this:

First, let's recognize that TFS, like any product, has some issues.  As I've experienced lately, merging large structural refactoring changes can cause problems.  I think you're best off limiting merges and merging often. And with smaller teams you don't necessarily have a lot of independent work going on and may not need separate Dev and Main branches.  Main is meant to be your stabilization branch, but if your development team works together well in a single branch you can limit some of the merging needed by conceptually combining those branches.  Feature separation is still possible by creating branches off of Main as needed.  When it's time for QA, I think it's okay to simply branch off for the release and build your QA release out of the release branch (i.e. Release 1.0).  Bugs found in QA testing can be fixed in the Release Branch and then merged back to Main.  The final signed off QA build becomes the release version and then the release branch can have security locked down so that the only changes that will ever go into the release branch will be for approved hot fixes.

In summary, I'm not suggesting the approach described in the white paper is flawed.  These are smart guys and everything makes sense.  I simply think that it's best to be practical and consider what you really need to succeed.

Benefits of K2 [blackpearl]

K2 [blackpearl] is the newest version of workflow software from SourceCode.  I believe it can be a valuable tool for developing line of business applications, specifially solutions that involve routing and tracking work and information between people.  While I haven't built a production solution in blackpearl yet, I think I have a fairly good background from which to evaluate the product.  I have experience building process applications in a completely custom fashion, I have some experience with Windows Workflow Foundation (WF) and SharePoint, and I have built a production application using the previous K2.net 2003 product.  I recently attended a partner training event to get some more hands on experience with blackpearl and speak with K2 folks who really know the product.  This evaluation serves as a mental exercise for me and also information for those who may be considering blackpearl.

The Basics of a Workflow Application

Applications that improve business processes usually have some basic concepts in common: users, tasks, data, rules.  Users are assigned tasks to process data.  A simple example: Employees (users) submit purchase orders (data) for approval.  Depending on the cost of the purchase and the department the requester works in (rules), a manager has to approve it (task). 

So how do you build a system like this?  Obviously you're going to start with requirements gathering and in a business process app (any app really), that can be one of the biggest challenges.  I think blackpearl can help you early on in the process.  I'm a big believer in early prototyping.  Being able to mock up an early system that walks users through the functionality is much more effective in fleshing out requirements for the final solution than simply talking with the business and drawing up how the app should work.  blackpearl allows you to rapidly build out workflows so you can walk users the flow of tasks that each user will get, at least in a rudimentary fashion, early on in the process.  I'm intrigued by one of the new built in UI options blackpearl introduces.  It auto-generates a tabular-label/textbox-style aspx page for the tasks.  The final solution will no doubt involve complex business logic and a fancy user interface and lots of other goodies, but to get moving you should be able to get a simple prototype up and running writing little or no code.

Visual Designer

I'm a visual person.  I think you have to be to understand complex business process applicaitons.  K2 blackpearl offers three different designers to model processes in: 1) Visio 2007 2) an ajax web-based designer 3) Visual Studio 2005 (and 2008 shortly, I think).  The latter is great for developers.  And the K2 marketing folks will tell you that the first two options enable your non-technical business analysts to design workflows.  I'm not buying it, though.  I don't see non-technical folks building out production workflows.  Wizards and all, there are still too many blackpearl and technical details in a real world scenario that make this unlikely.  I can see two ways this could be helpful, though.  Business analysts can start with Visio to diagram a process which can later be "blackpearled" by developers, giving the process a jump start.  Then, viewing in Viso, developers and business analysts can continue to refine the workflow by looking at it in a "common language".  I haven't tried this yet, but it seems viable.

Looking at the alternative approaches, SharePoint workflos are WF-based and therefore give you a designer to work with.  With a custom solution, you could use WF as your workflow engine and get design capabilities.  However you have a lot of plumbing to build out.

Plumbing

Building a system that tracks tasks is non-trivial.  In a custom solution, it most likely involves building a database table for tasks, writing code at write to and update the tables as events occur, properly assigning to the tasks to the correct user(s), notifying the users of their tasks, and allowing them to manage them.  It doesn't sound extremely difficult, right?  But like I said, it's certainly non-trivial.  WF gives you a good framework to build on and some basic service implementations for things like persistence via SQL Server, but you're still going to have to build out a host process, define your workflow related classes and wire everything up.  And unless you're really forward thinking, you have to do this for every application you build. 

SharePoint workflows have the concept of using SharePoint lists for tasks.  These tasks are scoped to a list within a site and without some custom work, it is difficult to create an aggregate view of tasks from various sites.  Another interesting point is that by default SharePoint deletes completed tasks after 60 days to improve performance.  You can turn that "feature" off but the onus is on you to archive task history, which could be a necessary requirement for compliance. You may want to do this with a blackpearl solution, as well, but the underlying database is built in a way that you don't need to.

Taking tasks a step further, after getting through the basics, you have to write even more code to monitor the tasks and react to tasks that have not been acted on in certain timeframe.  In K2 blackpearl this functionality can be defined in an Escalation.  You can specify rules like "if this task isn't completed in 24 hours, send an email every day" or "if this task isn't completed by a certain date specified in my business data, move to another point in the workflow".  Certainly non-trivial coding here.

We haven't even touched on how tasks are assigned or how you know when tasks are completed yet, either.  Simple assignment isn't that hard, right?  Just an AssignedToUserID column in my Task table, right?  Well for one applicaiton that might be ok.  But what if your process is more complicated.  "This purchase order needs to be approved by two of the managers in the Accounting Department."  blackpearl has the concept of Destinations, Slots, and Succeeding Rules for each activity, or milestone, in a workflow that allows you to easily define scenarios like this.

Additional Benefits

K2 blackpearl has additional benefits over a SharePoint or custom solution including versioning support, robust logging and exception handling, and MSBuild integration.  And K2 blackpearl also offers addtional advanced features.  Smart Objects provide the ability to build facades that encapsulate multiple backend datasources for use in workflows and reporting.  Another interesting feature is the Event Bus, which allows you to register events and build out an event driven architecture.  These concepts are interesting, but I'm reserving judgement until I have a chance to realy work with them.  I may try to expand on the benefits in these areas in future posts. 

Summary

In the spirit of full disclosure, I have to point out that Clarity is a K2 partner, so it would be easy to assume that I have an obligation to recommend blackpearl.  However, we're not in the business of selling K2 licenses.  We're in the business of serving our clients by building software solutions and their needs always come first.  Writing and testing infrastructure code that manages workflows and tasks is not a activity worth spending time and money on.  K2 blackpearl provides that framework, allowing us to focus on designing and building applications that solve the business problems at hand, enabling us to quickly deliver high quality process related solutions that meet their needs.

Visual Studio Team Edition for Database Professionals: A Developer Productivity Tool

I wanted to share a few quick thoughts on Visual Studio Team Edition for Database Professionals.  Over the past several months I’ve found this to be an invaluable tool.  Aside from being a mouthful, the name is a little misleading as it implies that it is only targeted at DBAs.  This is not the case.  This component of the Visual Studio Team Suite is something that developers can use to gain productivity.

On most of the projects I’ve been involved in, developers are making changes to databases and a DBA may not even exist.  Coordination of those changes during the development phase can be a challenge.  Even more challenging can be the deployment of those changes to integration, testing, and production environments. VS DB Pro allows developers to track the database structure in a Visual Studio project, just like a class library.  A project can be created from an existing database or a new project can be started.  The main component of the tool is ability to perform a Schema Comparison, comparing one database or database project to another database.  Developers can use the comparison to apply the changes to their local database, or to make changes to the project.  I’ve found that this is very helpful for getting changes from one developer to another quickly.  The integration with source control helps track your changes.  Later in the application life cycle, developers and/or the operation team members can generate a script using the comparison to deploy changes to a test or production environment.  In addition to schema comparison, there are other features the tool provides like refactoring and unit testing, which I haven’t used much of yet.

As always, you can’t beat good communication across a team as a key component of a successful project.  However, I think that adding Visual Studio Team Edition for Database Professionals can make your project even more successful.  I’ve got some further ideas about “best practices” for using the tool on a project and I’ll try to post those at a later date.

A couple notes for full disclosure: I’ve only used VS DB Pro with SQL Server 2005 databases and TFS source control so I can’t tell you about the experience beyond that.  Also, I’ve never compared its feature set to that of other tools - I’ve simply taken it for granted as part of the Team Suite.  And there are a few gotchas.  For example, sometimes after getting latest from source control, even when clicking the “update schema” button, the local temp database doesn’t get updated and that can cause some problems.  I’ll give MS a little break chalking this up to a first version of the tool (But it better work better in future releases!). 

A Scrum-ptious Methodology?

The other day I attended the Chicago VSTS Users Group meeting where the focus of the meeting was the Scrum methodology. Ed Chaltry from Centare Group led the meeting. He probably felt like he was defending Scrum instead of just presenting it as there was a lot of good lively discussion. It was a VSTS meeting, so a couple of tools that work with TFS Conchango and eScrum were demoed a bit. The emphasis was more on Scrum than the tools, however.

What is Scrum? Scrum is one the agile methodolgies of software development. Wikipedia has an overview here. I have a decent amount of experience working in an agile development model: small teams, including users, SMEs and QA early in the process, following an iterative timeline. Only once, though, have I worked on a project that truly ran under the Scrum methodology. After attending the user group the other day, I was reinspired to evaluate and share my take on Scrum.

The gist of my thoughts on Scrum? Scrum works well in some instances and should not be used in others. I think there are some things to take from Scrum and use and there are some things to get rid of. Some things make sense to me and some I don't Wow! That's genious! Okay, okay. I have more thoughts than that. Below is a breakdown on what I like and don't like. I'd love to hear other people's thoughts.

Burndown

One thing I really like about Scrum is the burndown concept. Your backlog of tasks starts with initial estimates for time and each task is updated on a daily basis to reflect to the amount of work left. What I like about this is that you can see a great view of how your project is progressing. You can see if your estimates were off. You can see when new items have been added. And it is really easy and makes sense. No percentages complete, just what is left. It can all be rolled up nicely into a "Burndown Chart" to show you how your doing. Here's an example.

To get the complete picture, I like to add a line that shows the total estimate. At first you might think that that doesn't help much because it shouldn't change. Well you and I know that that isn't usually the case. This new line on the chart shows how many new items and how much work has been added to the iteration (just in case things slip you can see why, not that that ever happens). Scrum tries to protect the development process: it allows for new tasks to be added to your sprint backlog, there just not supposed to be new features. Again, I think this is not often the way things work out.

All Aboard?

This brings me to my next point. The business side of the development equation has to be on board with the Scrum process for it to work. That might sound obvious, but unless you have a strong voice that will respect the rules, Scrum isn't going to work out. The business will have to know that that new feature will need to wait until the next Sprint. So culture here is really important to your success. That's going to be true with any software development process. With Scrum, I feel like you really need that buy in.

Requirements Aren't Perfect

Like I said before, the idea of a backlog of features is great. "We need to be able to view our orders by state." That's a feature that is pretty straight forward. Put it on the list. Prioritize it. We'll get it into a Sprint and out in a release. Sounds good. But there are always questions to ask about those features. Or there are features that aren't so straight forward. "Our customers need a better view of their orders". They're never perfectly documented or straightforward when they come to a developer. The business analyst might capture what they think the user wants, but there's often back and forth necessary when you start building the feature. So how do you estimate for that? Do you pad for additional requirements gathering time? I think that is what Scrum wants you to do. And the first day of the Sprint is a planning day so you may get some of that done there. So this might be handled in Scrum, but this is one of the things that I think is much harder to do successfully that it sounds.

Long Term Planning

Something that I don't understand about Scrum is how it accounts for long term planning and changes from a technical standpoint. If you're building out a new system, there is going to be a decent amount of technical design required before any coding starts. There might not be any deliverable code at the end of this. Scrum seems to require a potentially releasable deliverable. That isn't always going to be the case. Somethings take longer than a month. For example if you're moving from from oracle to sql server and you know you can't do that in a one month period, do you do it as a sprint do you? Do you start the new work in a Sprint that won't yeild a release while continuing to deliver new features for the current system in a separate sprint? What if you need to do some evaluation of your application. If you were going to evaluate a new third-part toolset or tweak performance? Or if you're changing to a more service oriented architecture that you didn't realize was needed at first. How do you handle this? Can you add technical-only items to you backlog?

This is where I think the 2-4 week strict Sprint timeline breaks down a bit. I get that you can get a rythm going if your consistent, but I just don't think that everything can or should be done in such a strict timeline. What's wrong with a 3-month first phase? This may be where some semantics come into play. You could say that a 3-month phase is just three Sprints. Some things, though, should just be taken out of band.

Daily "Standup" Meetings

My last thought on Scrum is about the daily meetings. Scrum demands a daily "standup" meeting where the team reports quickly on what they've been doing, what they're going to be doing and if they have any roadblocks. Communication is important - no question. And I like the concept of team members committing to what they will be working on. But a daily 15 minute meeting never seems practical to me. Everyone is supposed to stand to keep things moving, maybe even pass something around to designate the speaker. And the Scrum Master is supposed to take issues offline for subsequent meetings. Sounds good.

Realistically people are on a roll come meeting time or they get distracted and pulled in different directions and can't make a daily meeting. At the very least this can cause someone to be late. This is killer if that person is the Scrum Master. Roadblocks that arise often involve the majority (if not all) of the team that is present, so it just makes sense to talk about them a little bit while everyone is there. Autonomy of the developers is a tenet of Scrum, yet developers have to check in every day. Or maybe you don't trust your team? That's one way it could look to a developer. Let's let everyone sink their teeth into something and do a couple days worth of work and then report back.

The daily stand up meeting is likely to fail. This can lead to resentment toward the whole process and subsequently low morale. Weekly meetings and the responsibility to raise issues as needed work better in my opinion.

.NET Technology Briefing Milwaukee

Last week I participated in the Microsoft .NET Techology Briefing in Milwaukee.  I gave a presentation on what's new since .NET 2.0.  Topics included .NET Framework 3.0 and 3.5, ASP.NET AJAX, Silverlight, and Visual Studio 2008.

You can download the slides here:

https://employees.claritycon.com/bdougherty/blog/downloads/NewSince2.zip

Here's are links to some of the demo material:

WPF Healthcare Prototype

http://wpf.netfx3.com/files/folders/applications/entry6608.aspx

WPF Zeus XBAP

http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=53790

http://wpf.netfx3.com/direct/zurich/zeuswpf.xbap

Simple demo projects I created in Visual Studio 2008 (LINQ to SQL demo won't have the database so it won't run)

https://employees.claritycon.com/bdougherty/blog/downloads/DemoApps.zip

Questions to Ask Yourself Before Creating a User Control

User controls are great. They allow a developer to encapsulate functionality that can be reused throughout applications. Like any well designed class, they allow the consumer to care only about the interface and not inner workings. And from a team perspective, they provide logical separation of tasks so that multiple developers can work on related functionality simultaneously.

But just like everything else in this world, there can always be too much of a good thing.

Too many user controls can be a pain to manage, add overhead, and potentially make the data you’re trying to work with harder to retrieve. Plus, building new controls does come with a cost and you don’t want to waste your time. Below are some questions I think you should ask yourself before deciding to build a user control. Specifically I’m thinking in the context of ASP.NET web development, but much of this relates to Winform and development, too.

Does my control have a unique behavior?
It’s easy to fall into the trap of data (not behavior) dictating the need for a user control. Let’s say that a couple web pages need to allow users to select from a list of apples. Before you know it, someone builds ApplePicker. The ApplePicker usercontrol contains a DropDownList control and allows the consumer to set the data source to a list through a DataSource property. And…and that’s about all.

It turns out there is no behavioral difference between the two controls. The task of showing selectable lists of fruit could easily be achieved by simply using a DropDownList control itself. Now if the ApplePicker provided a list of options AND conditionally showed an icon based on whether the selected Apple is good for making pies or just good for snacking, then you’ve probably defined some unique behavior. In this case a custom user control is probably in order.

What if I just used a utility/helper class instead?
So let’s suppose the ApplePicker user control was simply a DropDownList as we initially discussed. But now the control is going to be "data aware". It knows how to load itself full of Apples. While it’s pretty cool to be able to drop a control on a page and "it just works" by filling its data source, in my I’ve found that it tends to not be all that practical or even all that beneficial. The rationale behind such a design decision is usually to avoid having to wire up the data source of your control on every web page and allow for ease updating the actual data source. These goals can be achieved in a better way.

Defining a static method a utility or helper class (Utility.GetApples()) allows for a consistent way to load the ApplePicker on all your web pages. The actual source of data can be changed for all controls by changing the inner workings of the GetApples method. And it also allows you to change the data source in any exception cases. For example, most web pages may show a full list of apples, but one may need to show a list of Favorite Apples that a user has defined. Both lists can be displayed with a single control that is now more in tune with a Model View Controller pattern. This can also help you consistently add the typical "-- Please Pick An Apple --" or blank first item in your list. I really like following this kind of pattern with controls to separate the behavior and display and find that it is almost always beneficial.

Do I need to lock down access to my functionality?
So let’s suppose the ApplePicker user control was simply a DropDownList as we initially discussed. What if I want to lock down the way consumers use my control. For example, I feel strongly that consumers should only pass in a List<Apple> (List(Of Apples) in VB) then maybe I’d want my own strongly typed DataSource property. A better rationale, though, would be that certain methods or properties of the standard control provide more access than you want consumers to have. For example, you may wish to only allow the Text property to be read-only. Access alone is probably not going to justify use of a user control since in most cases you’ll probably want to lock down access to something that relates to unique behavior.

Am I just trying to prevent duplication of code?
I’ll buy code reuse as justification for a user control. But only if there is a lot. If you have two web pages that have to show a list of Apples and the list can simply be achieved with the afore mentioned DropDownList, you’re not going to win me over. If you have 20 web pages that need to display this list of Apples with a red Font and green BackColor, then you’re getting warmer. But I’d probably look to see what we could achieve using skins and themes instead. In general, I think you should try to avoid the "duplication of code" argument unless you have a composite UI (multiple controls) like the conditional icon example.

Should I build a templated control?
Lastly, returning to the MVC and "behavior" theme, I think it’s good to ask whether templated controls are a good fit for your design. You’ve defined a unique behavior, but it before you know it, some web page may require 90% of the functionality in your user control, but they want to make a subtle UI change. For example, instead of a conditional icon indicating the best use of the selected apple, you may just want to display the text "Pie" or "Snack." ASP.NET offers some cool functionality allowing you to define a control that allows the UI to be tweaked via templates. This certainly involves more work when building your control, but it may be a good way for you to extend the reuse of your control.

Summary
I’m a big fan of user controls, and an even bigger fan when they are thoughtfully designed and reusable. As discussed above, there are plenty of great reasons to use them. However, they can become maintenance nightmare and simply add to overhead. I know this topic can spark a lot of opinion and debate, but hopefully these questions will help you make future decisions about when to create user controls your applications.

Microsoft Interop Forms Toolkit 2.0 Released

Microsoft has released the newest version of the Interop Forms Toolkit. You can download it here.  Clarity created the first version of the toolkit aimed at simplifying the process of migrating VB6 applications to .NET.  The new version goes beyond Forms, adding support for easily incorporating .NET Controls in a Visual Basic 6 Form.

MEDC Closing Thoughts

MEDC was a bit of a let down this year.  Last year, MS was championing Windows Mobile 5.0 and rightly so.  It was a big step.  This year nothing like that existed. 

Windows Mobile 6.0 and.NET CF 3.5 have some cool updates. Windows Mobile Pocket PC and Smartphone are called now Windows Mobile Professional and Standard, respectively.  There's a new cellular emulator and a Fake GPS emulator for developers to test with.  Orcas is coming.  But there wasn't that huge jump in technology.

You still have SQL Server CE.  And though the name changed four times, you still only have RDA and Merge Replication.  The Occasionally Connected Sync framework/components/pattern or whatever still seems to be off in the distance.  Gaming and entertainment still makes up a larger portion of market share than Business/Office and Home/Education combined.

Maybe MS didn't put the effort into mobile that they did the year before.  Maybe my perception is off.  This year just seemed to lack some excitment.  It's still mobile development, though, and that is ALWAYS cool.  So hopefully I'll get my hands dirty with some of this soon.  I'll be sure to post on any new excitement I learn about.

Store and Forward Transport

One of the cooler things I learned about at MEDC was the new Store and Forward Transport capability in the upcoming .NET CF 3.5.  This allows one device to send data to a central data store and even directly to another device using the new Email trasport feature in WCF.  This looks like it could really simplify data transfer in some scnearios, especially in a loosely connected enviroment.  Essentially your "service" mail stays up on the server until your code pulls it down.

The new code lives in the System.ServiceModel.Channels namespace.  The basic flow of the code looks something like this.

RECEIVING

1. Create a WindowsMobileMailBinding
2. From the binding, create a listener specifiying the channel name and email address

SENDING

1. From the binding, create a channel factory
2. Open the factory and create and output channel
3. Create a Message that includes your serialized custom data and send it

Of course there's that's the simplified view, but seeing and playing with the code a little, it looks like it's easy enough.  It's also worth noting that messages can be protected using WS-Security.

For more detailed info, checkout Mark Prentice's blog: http://blogs.msdn.com/markprenticems/archive/2007/04/25/introduction-to-the-windows-communication-foundation-for-the-net-compact-framework-store-and-forward-messaging.aspx