.NET

Generic or Specific

Bill Sheldon — Fri, 02 May 2008 23:46:00 GMT

This is one of those musing posts and comes from one of the challenges I have when teaching a feature that Microsoft chose to call 'Generics'. I think this name was picked by someone, who while reasonably familiar with English wasn't a native speaker of the English language. Thus they found a definition and thought it applied - allow me to elaborate.

What is a .NET Generic - well in short - under the original implementation of .NET collection classes contained a set of other objects. However, these classes didn't know specifically what kind of object they contained. Instead a given collection might contain more then one different type of object, for example numbers stored in a collection with strings and image objects. It wasn't possible to say thata given collection would contain only a specific type of class.

With the introduction of 'Generics' it was possible to indicate that a given collection would only contain a specific type of object. That's right the feature Generics describes a set of rules and syntax for ensuring a collection is of a specific type. Now the challenge comes from how the definition of generic is phrased in some dictionaries: "Relating to or descriptive of an entire group or class"

Notice that the preceding definition basically associates the definition of a generic with a class. Thus if you were searching the dictionary for a word that described a class - well there you have it. Unfortunately this use of the word "class" doesn't relate to the use of the word "class" in object oriented programming. In this use a class is more of a category of like items - not the definition of a single item.

Webster's Revised Unabridged Dictionary - Cite This Source - Share This

(http://dictionary.reference.com/help/web1913.html)

Generic

Ge*ner"ic\, Generical \Ge*ner"ic*al\, a. [L. genus, generis, race, kind: cf. F. g['e]n['e]rique. See Gender.]

1. (Biol.) Pertaining to a genus or kind; relating to a genus, as distinct from a species, or from another genus; as, a generic description; a generic difference; a generic name.

2. Very comprehensive; pertaining or appropriate to large classes or their characteristics; -- opposed to specific.

That's right the word I most frequently use to describe the feature Generic is the one which defines the opposite of the definition of the word generic....

I don't think Microsoft can really do much about this, it's just one of those things that make you wonder...

The new phone books are here, the new phone books are here...

Bill Sheldon — Thu, 17 Apr 2008 17:27:00 GMT

This is one of those 'hey look at me' posts that always make me feel like... well if you recognize the title of the movie that the quote which is the title of this movie comes from - that pretty much sums it up.

Anyway a few 'ads'.

First off, I have a new article available over at SQL Magazine. It's a very introductory article to LINQ for SQL so if you are looking for a good starting point for just getting started with LINQ, here's a short article that might be of assistance: http://www.sqlmag.com/Article/ArticleID/98205/sql_server_98205.html

The second item fits the post a bit better. Back in the first Quarter I signed on to do another book - yes my wife is ready to kill me - which since she is pregnant get's the pregnancy multiplier (we're currently around 7 or 8 so the danger level is getting pretty high). At any rate if you are interested it's still way out in the future - like October 2008 - if "we" (me) make "our" (my) final due date - here is the page: http://www.amazon.com/o/ASIN/0470377313/105-1544171-6096430

As you can note on that page this next book is an Office Business Applications book. Of note, it will have both C# and VB samples (ok VB sample - but more on that later) and covers using WPF with Outlook Form Regions and Excel not to mention server side document generation. That's the good news - the bad news - well I'm late on my chapters - of course that's pretty typical for me - the question is can I catch up in the next few weeks - especially given the increasing pregnancy multiplier...

Finally, I thought I should mention that my last book is finally getting read to be available. At 1600 pages it pretty much is a phone book, and it should ship for the first week of May which apparently is fast approaching: http://www.amazon.com/Professional-Visual-Basic-2008-Evjen/dp/0470191368/ref=sr_1_1

WPF Now? Why should you?

Bill Sheldon — Thu, 20 Mar 2008 00:39:00 GMT

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.

Knowing Who Executed a Custom Workflow Action

Bill Sheldon — Tue, 11 Mar 2008 22:43:00 GMT

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.

SharePoint 2007 custom Workflow Debugging Quirk with Visual Studio 2008

Bill Sheldon — Fri, 07 Mar 2008 10:54:00 GMT

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.

Visual Studio 2008 Launch and Updates

Bill Sheldon — Sun, 24 Feb 2008 15:22:00 GMT

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...)

Microsoft Mainstream Support - Early .NET reaching the end of lifecycle

Bill Sheldon — Wed, 09 Jan 2008 16:56:00 GMT

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?

Support provided	Mainstream Support phase	Extended Support phase
Paid support (per-incident, per hour, and others)	X	X
Security update support	X	X
Non-security hotfix support	X	Requires extended hotfix agreement, purchased within 90 days of mainstream support ending.
No-charge incident support	X
Warranty claims	X
Design changes and feature requests	X
Product-specific information that is available by using the online Microsoft Knowledge Base	X	X
Product-specific information that is available by using the Support site at Microsoft Help and Support to find answers to technical questions	X	X

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.

Happy Holidays...

Bill Sheldon — Sun, 23 Dec 2007 22:37:00 GMT

VS 2008 and Blend 1.0

Bill Sheldon — Fri, 30 Nov 2007 12:32:00 GMT

So one of my biggest pet peeves with the release of VS2008 was the fact that if I created a WPF project in VS 2008 or even converted it to work in VS2008 - then I was stuck - no more taking that project into Blend to work on the graphics. This to me was a significant issue. Fortunately Soma announced that this issue has been resolved and Blend SP1 which supports the VS 2008 project files is now available. Here are the links:
Soma: http://blogs.msdn.com/somasegar/archive/2007/11/30/designers-and-developers-working-together.aspx

Blend SP1: http://www.microsoft.com/downloads/details.aspx?FamilyID=a07196d1-971b-4710-99c8-d3d9603ccfcb&DisplayLang=en

Team Explorer 2008 Install Error

Bill Sheldon — Fri, 23 Nov 2007 13:02:00 GMT

Once I installed Visual Studio 2008 it was time to add the Team Explorer for Visual Studio 2008. The Team Explorer aka Team Foundation Client is found on the Team Foundation Server installation DVD.

So I took the .ISO file which I downloaded from MSDN and copied the TFC folder which contains the Team Explorer installation onto an actual DVD. This gave me a copy of just the Team Foundation Client 2008 which I could install onto my development machines.

I put the DVD into my Vista/Office 2007 machine and kicked off the install. The install ran and after things were going I moved onto another machine. When next I checked I found that the installation had failed. So I reported the failure via the automated process that the install package provided and tried again. The install failed again - which left me... concerned.

So I took the DVD out of my Vista machine and moved to my Windows XP / Office 2003 machine and ran the installation. While that was running I started searching the web for any known installation errors with Team Explorer 2008. I finally found a note in the Microsoft MSDN Forums that mentioned someone else was having an install problem and found that it went away when they used the install from a DVD which had all of the TFS products, as opposed to a CD with only the TFC folder.

Now what was interesting is I found this as my Team Explorer install on Windows XP with Office 2003 completed successfully. In other words on an XP machine running Office 2003 you only need the TFC directory to install Team Explorer.

So I went to my .ISO file and burned a DVD of the entire image this time and put it into the Vista/Office 2007 machine. I must admit I really like the updated install package for the TFS product, having the different product options available is a nice way of handling the different install packages. At any rate I clicked on the Team Foundation Client and started the install. The first and subsequent screens to start the installation looked just like the stand-alone DVD's and the install started with the same packages. However, in this case the installation ran to completion.

Thus if you are using Windows XP with Office 2003 you can install a standalone installation package for Team Explorer however, if you are running Vista or Office 2007 and you get an installation error - then make sure you get a copy of the full Team Foundation Server (TFS) DVD and run the install from that media.