I'm in week 5 of teaching my Visual Basic I programming class at the University of California San Diego Extension.  The week 5 class is going to focus in on WPF and helping students get a better feel for working with this new user interface paradigm, and it's custom 'script' language XAML.

WPF comes with several new concepts and I think that for developers who are just getting started and or coming from a solid web application background many of these concepts feel very natural.  On the other hand there are a host of developers out there who are coming from a Forms/Win32 based background.  For these developers, even though most people think of WPF as a Forms replacement the new declarative model and in particular the new buzzwords leave them overwhelmed.

After all most people that show of WPF applications are busy making sure they've included as many graphical elements as they possibly can, for example one famous paraphrase of Tim Huckaby is "It's just not a WPF application without some form of gratouitous animation."

However, from my standpoint, in the way I approach introducing developers is to explain some elements on XAML and then focus on the similarities between WPF and Windows Forms development.  For example in Chapter 17 of the soon to be released Professional Visual Basic 2008 which will ship this May, my approach is to literally have you start by designing what could easily be a Windows Forms application using WPF.  Over the course of the chapter the application is migrated with the title bar being hidden, buttons being customized, etc as you introduce more and more concepts that are native to WPF. 

In the beginning you start by working with the Visual Studio 2008 editor.  This editor is well known to be VERY limited in comparison to Blend.  However, if you are moving from Windows Forms to WPF then you'll feel much more comfortable in this environment.  Start here and work towards the same type of applications, then introduce Blend.  Blend not only provides several key examples that you can use to get a better feel for the WPF paradigm, but allows you to start to take that item which you feel comfortable with and migrate it to a WPF paradigm with routed events, complex styling and other elements that are much more in keeping with the declarative programming model.  Of course this book isn't about WPF so I don't go deep on things like styling and databinding and other topics, but it will help you start so that those topics combined with everything else in WPF aren't quite so overwhelming.

Keep in mind that while there are rumored to be several WPF related updates coming in the next update to Visual Studio 2008 (I think I covered when to expect that to appear) even with these updates you as a developer are still going to need to start to transition to this new UI paradigm.  Fortunately because WPF performs better on Vista then on XP, and has no backward compatability below XP there is still time for you to get up to speed... but that grace period won't last forever.  More importantly those performance issues are primarily for heavy duty graphics, if you are working in a more Windows Forms paradigm you won't see much of a difference at all.

Which brings me to "Why do it now?" - Well we already have an announcement that Windows Forms 2.0 was the last of the new development on that model.  By starting to work with WPF now, even though you might not create a gratouitous graphic, you are creating an application tier that as WPF takes over (and with it's relationship to Silverlight 2.0 the pace of adoption is imho going to accelerate) your code even though it still has the standard Windows Forms look will integrate and be able to be adapted much easier then people who are continuing to create new solutions using Windows Forms.  So now is the time to take those existing designs and just start by implementing them in WPF with little or no leverage of the high end graphics - and then as you get more comfortable with just how much power WPF provides you can update them to leverage that power.

As I noted in my last post I’ve been working with a State based custom MOSS workflow.  I’ve actually reached the point where I’m into resolving minor issues during my unit tests.  One of my tests involved having a user other then the assigned user take a pending task and resolve/address it.  So for example a document waiting to be approved is recognized by a manager who is covering for the assigned manager.  The covering manager has “permission” to complete the task but isn’t the assigned user.  This is where I had what I consider to be unexpected behavior.

What happens in SharePoint is that when I start in the debugger (or after deploying my workflow outside the debugger) the workflow is run in the context of the administrator.  Now before you read that as “administrator” let me clarify – it’s run under a fixed account.  The context of the thread executing the workflow isn’t assigned based on the current user.  So whether it’s the administrator account or the Guest account the point is that at runtime if a parameter containing the user who triggered a workflow event isn’t passed into the workflow there is no way to determine the actual identity of the person triggering that next step in the workflow.  This is important because if you are planning a workflow, then like most you are planning to capture a history of events which occurred.  The problem if you don’t explicitly pass the name of the current user triggering an event then the name available as part of your running context will not be correct.  Thus your history can at best reflect the name of the user who was supposed to resolve/address that action.  Lost is the identity of the user who actually accessed your site and did take action on that workflow item.

If someone actually has an answer for getting that user (aside from explicitly setting a parameter) that I'm not aware of please feel free to let me know?

I spent quite a while looking at the parameter and runtime environment data and created a new WindowsPrincipal.GetCurrent() instance to see if I could find the actual current user. I also checked for example the current user value in this.workflowproperties.web, and it also was the administrator.  Of course it might turn out to be a setting within SharePoint that I'm not aware of.  Not that I would have explicitly set it since I can only begin to guess at where the setting comes from when my workflow is deployed from Visual Studio 2008.  (btw, the account I deploy from isn't the administrator account.)

I actually consider this to be a pretty major workflow failing… in theory there is a reduction in security since the process executing the workflow has the permissions associated with (in this case the administrator) the most privileged account that will need to run any workflow.  Additionally it breaks down on tracking reliability since it is in theory possible to apply the wrong account name to some of the history data, or if you haven’t planned for it to not explicitly capture the actual user executing the workflow. 

Keep in mind if you are building and testing your workflow under the administrator account you might not ever notice this.  However, knowing about this issue you can set up an InfoPath form and at least capture the name of the user who actually acted on the associated workflow.

So I noticed an issue the other day.  I have a custom SharePoint 2007 workflow as part of some work I'm doing on an Office Business Application (OBA).  Now if you were at the Office Developers Conference (ODC) in San Jose this year you saw Jay Schmelzer demonstrate how you could with Visual Studio 2008 start up the debugger on a SharePoint State Workflow project and have Visual Studio automatically update and deploy the files associated with your workflow. It's a great capability and very powerful when it comes to working with SharePoint workflow projects. 

However, I recently ran into a problem every time I went to debug my workflow the deployment step failed and the debugger failed to start.  It took a little while but I soon realized that the problem was related to two of the files the workflow.xml and the feature.xml files being marked read only in the deployment directory.  It was only a short time after that till I realized that the problem was related to the fact that I had finally bound my development environment to our Team Foundation Server (TFS).

It turns out that when Visual Studio deploys the files associated with the workflow it leaves the file attributes unchanged from your development directory.  This is an issue because in working with TFS and not having these files checked out they are marked as read only.  The first time you deploy no problem, the old version wasn't read only... but the second time the deploy fails.  Once you check the files out - even though you aren't planning to edit them, Visual Studio will deploy writable copies again.  However, you'll first have to access that directory on your system and manually reset the files to not be read only.

Brett Favre retired... sports pundits (who are of about the same value as political pundits) have spent tons of hot air on the subject and finally get what so many have asked for (a good football story after the Super Bowl and before March Madness)  I have to admit I was hoping for something more along the lines of the day Cal Ripken Jr. took himself out of the Orioles starting line-up (and finished out the season). My personal hope was that Brett would 'retire' to the role of backup early in a future season - help the team and Aaron R. along for that year and fill in if needed - since most first year QB's need some help along the way... 

So another streak ends, but as I listened to the clip I realized that Brett was in this voicemail also illustrating personal motivation and the role it plays for those at the top of their game.  Often  people who are put in charge of an organization forget that the best and only real motivator for your top performers are the expectations they set for themselves.  Listen to the clip, it isn't that Brett couldn't or wouldn't like to play but that his expecation that anything less then a Super Bowl victory would be a disappointment.  Brett recognized what his expectations for performance for the coming year were -which brought him to the conclusion that it was time to leave while he was (based on his performance last year) at the top of his game - plus a team that had a great year.

My remaining question - since Fox broke this story before literally anyone else including the Packers let it out - what is Brett's role when he comes to work for their network?  Lets face it they were so sure of the story - it was like well if he hadn't already signed - they were deep enough in negotiations that the deal was considered done.

This is a combination of humor and warning of lessons learned...

The Heroes Happen Here (http://HeroesHappenHere.com) launch event for Visual Studio 2008 happens this week.  As with the Visual Studio 2005 launch event this is a shared launch that includes Windows Server 2008 and SQL Server 2008.   Visual Studio 2008 actually released back in November of 2007 and since then we've all had a chance to start building applications.  The new features in Visual Studio 2008 are very powerful across the board, but those associated with Visual Basic and LINQ happen to be particularly powerful.  I'm sure the the launch will do a great job of showing off the new features, after all it seems like just last week at the Office Developers Conference that we were showing off several of the features related to created solution based on the Office 2007 products. (There was a truly awesome demonstration of the built in debugging capability of Visual Studio 2008 with custom MOSS workflows during the ODC that I happen to know a little about.)

I don't want to steal any of Microsoft's thunder related to Wednesday's launch event in LA, but instead to look beyond the current release.  Not way into the future (ie. Hawaii - a future version (next?) of Visual Studio) but something much closer - the coming updates to Visual Studio 2008.  That's right we haven't even gotten to the launch and of course the focus is already shifting to the next set of features.  This makes more sense when you consider that SQL Server 2008 - which is part of this week's launch event isn't actually releaseing until sometime in the 3rd quarter of 2008.  Thus I'm going to point out some things which it certainly appears will be releasing for Visual Studio 2008 at the same time as SQL Server 2008 releases.

Why do I say that - well the first example is a set of updates to ADO.NET to support the new features of SQL Server 2008 - http://blogs.msdn.com/adonet/archive/2008/02/21/coming-soon-to-linq-to-sql.aspx Yes as part of the release of SQL Server 2008 ADO.NET will be getting updates to support the new data types which are going to be available.  The nice thing about that post is that it helps clarify those new SQL Server features which are most likely to be used by application developers right out of the gate.

On the other hand a single blog post really doesn't firm up that those enhancements have to arrive with SQL Server 2008 -  they might not arrive until say October or November or even later, rather it is the fact that we also have word on several other new Client features which are going to be releasing "this summer."  Scott Guthrie outlines several new enhancements to Visual Studio 2008's client model http://weblogs.asp.net/scottgu/archive/2008/02/19/net-3-5-client-product-roadmap.aspx 

I personally am very interested in some of the new deployment enhancements, but lets get real there is no way Microsoft is making more then one release of enhancements this summer so the combination of the two blog posts gives us a pretty good idea of when to expect the next set of developer tool updates (http://www.sqlmag.com/Article/ArticleID/98161/sql_server_98161.html).

It's nice to see that new tools and enhancements to Visual Studio 2008 are on the way even if as some at Microsoft admit the new tools are coming at a breakneck pace: http://blogs.msdn.com/rbarker/archive/2008/02/04/test-post-from-windows-live-writer.aspx  (btw, I'm planning to download the Live Writer SDK as soon as I get caught up and have some free time...)

A couple years ago there was a huge crisis since Microsoft was bringing an end to mainstream support for VB6.  At the time some people felt the sky was falling.  The reality of course is that applications still worked but the available support for unexpected behavior stopped.

Well it's that time again. The end of support for .NET 1.1 has been announced - October 14, 2008.  A little over 5 years after .NET 1.1 was released.  This isn't the end of support, just end of mainstream support.  Support will continue until 2013 - if you are like me your next question is what's the difference.  Microsoft provided the following table to explain:

What is the difference between Mainstream Support, Extended Support, and online self-help support?

Note A hotfix is a modification to the commercially available Microsoft product software code to address specific critical problems.

This might have other impacts, for example SharePoint 2.0 (2003) is built using .NET 1.1 for customization, so the impact of this on the SharePoint community and custom web parts could be significant.  Of course since SharePoint 2.0 mainstream support ends around 7/2008 (less then 6 months from now) that probably won't be a problem... at least on the .NET side - not sure about those actually using the product who haven't migrated to SharePoint 2007 (3.0) (Note: I was actually expecting the reverse (.NET 1.1 support ending first) when I started this post...)

At any rate I think it's safe to say that you shouldn't even consider starting a project on .NET 1.1 or SharePoint 2.0 (2003) at this point.  Of course in my opinion anyone not working on VIsual Studio 2008 is behind the power curve.

So it's a new year... and time to get working on getting back on my bike again.  I managed some riding this past year which was good - but not nearly as much as I'd hoped.  I've fallen about 2,400 miles off my target annual mileage... oh well, hopefully I'll hit or exceed my target this year - although in all honesty I think it'll be difficult to hit my target again this year.

On the plus side my light is working again, I was unable to ride to and from work for most of Dec. because when I pulled out my light it stopped working.  I have a very nice Flamethrower from NiteRider (www.niterider.com).  (The flamethrower was the 1st generation the current generation is the Flight: http://www.niterider.com/prod_flight.shtml) This light puts out more light then most car headlights - which is good because when I'm riding at night I want to be seen and this isn't a headlight that you can miss.  Unfortunately on my first ride home this winter; when I fired it up - the LEDs powered up but each time I tried to get my main light to start it failed.  I made it home, after all the 3 LED's do provide minimal light - but not an acceptable situation.

So I used the NiteRider website and gave them a call.  Their service was well coordinated and they gave me a Return Maintenance Authorization (RMA) number to track my repair.  So I sent them my light, at the height of the Christmas season...  A couple days after FedEx showed my package had been delivered I gave them a call to check on the status.  Note I didn't send them my battery because they charge $20 for each returned item (light, battery) and since my LED's worked, my taillight worked and my light was trying to fire up I felt the battery was solid.  When I spoke to the maintenance rep he mentioned he was preparing to call me... the problem was a bad ballast and the light had been given some free maintenance beyond the ballast.  So I paid for the light's bench test and parts.

I got it back a few days later and set up a test at home (no sense repeating my last ride).  Well I fired up the light - and same results.  Now I have no doubt that they tested my light before shipping it back to me so I called them back.  Of note I didn't start screaming or looking to kill the phone guy, I just said hey - got my light but it still doesn't work.  We talked a few minutes and we agreed I would send my light and battery back and they would waive the bench fee on the battery as long as it checked out (we all knew it would) and (still in the Christmas season) they put a rush on the work order.

A few days later I got my light and battery back - no charges, apparently something else related to the starter in the light or the light itself had failed (probably took a hit in shipping) and they had repaired my light and gotten it back to me in a matter of days.  Overall although it did take two trips (for the FedEx guy) they did a great job getting my light back online (although I was on vacation by then). 

Today I hooked up the light and rode into work - yes I had tested it previously. The goal is to get to ride in 3 days a week, and I'd ride tomorrow but it looks like the rain really will arrive tomorrow so I'll wait till next week to ride in again, but my thanks to the folks at NiteRider who did a great job with my light's repair and now I just need to get in a couple thousand miles...

Many years ago there was a common pattern for Office Workers.  Essentially before the true abundance of desktop systems and printers it was common to have a paper form.  Copies of this form would be used for any number of tasks (fax cover sheets are a common example most people can relate to) and then when there weren't any copies left you would make a new set of copies.  The cardinal sin for the admin staff was of course the person who took the original and used it instead of copying it.  Want to really get on the Admin staff's bad side wipe out 3 or 4 originals and they will hunt you down...

At any rate now that we have PC's and easy access to printers the separate set of file folders containing originals hidden from non-admin eyes is pretty much a thing of the past.  These documents are typically stored on a central Intranet server like SharePoint.  However, in many cases a limited version of the same problem still exists.  Now people will take the copy that is on the server and open it for customization.  Then without thinking they save that copy and it goes right back to the server.  In minor cases they've just poluted the baseline copy that's sitting on the server - but in extreme cases they could so modify the original that its almost useless as the original.  The solution of course is to make such original copies read only, except now instead of having them under lock and key in a big old file cabinet - they sit online marked read-only or checked out to the one trusted individual who won't overright them...  It's the same solution to the problem, just implemented with 21st century technology instead of physical copies.

------------------------------------------------------

Sorry for the long delay and somewhat sparse posts over the last few weeks (OK Months) but I've been a little busy with the latest version of the Professional Visual Basic book to go along with Visual Studio 2008 and VB 9.  However, I reached a milestone last night - OK theoretically it was early this morning.  I caught up with my publisher.  I've turned in all my draft chapters and returned all of the edited chapters that were returned to me to date.  I'm not yet done because there are more edits that need to be returned to me - of course the fact I turned in the draft late might be impacting that... but for tonight at least I don't have any authoring commitments... except I'm supposed to start that magazine article...