@ Head : DevCenter

ElementAtOrDefault

bill — Tue, 15 Dec 2009 01:40:17 GMT

VB 9 or later has a particular feature that can make life easier in some circumstances: the compiler allows you to access indexed items on non indexed enumerables. Let’s say you have code such as:

Dim items as IEnumerable(Of String)
. . . .
For i = 0 to items.Count - 1
Debug.Print items(i)
Next

VB will compile that for you. The Count is an extension method that loops through the list to determine the count; luckily VB calls that only once. The real killer though is items(i) is actually compiled as items.ElementAtOrDefault(i).

The ElementAtOrDefault extension tries to cast the IEnumerable(Of T) to an IList(Of T); if the IEnumerable isn’t actually an IList, it loops through the collection, returning at the given index. As you can imagine this would get extremely slow for large lists especially inside a loop.

The Good:
If your IEnumerable is in fact an IList, such as a List(Of T), then the compiler magically adding this extension call makes life a little easier as you don’t have to cast to IList yourself.

The BAD:
You have to be really careful when doing any code maintenance, especially if you change an IEnumerable source to a different collection base that doesn’t implement IList(Of T). You can end up writing really bad, slow code really easily.

I got bitten by the bad, but I caught it immediately as I was curious about the collection base I was using. In my particular case I had swapped an List(Of T) out with a ConcurrentBag(Of T). ConcurrentBag(Of T) basically uses linked lists where each item is stored as a node. Each node has a previous and next node; the list has a head and a tail. I thought it strange that ConcurrentBag would have an indexer given that would force walking through the nodes. I went to change the items(i) to items.Item(i) and BINGO it wouldn’t compile.

Possible best practices to avoid being bitten by this:

(1) Use For Each loops, not indexers. Your code will be far more flexible/manageable

(2) If you only want the first item, make it explicit by using First or FirstOrDefault extensions.

(3) Try to do the explicit cast to IList(Of T) yourself and work with an IList(Of T) instead of an IEnumerable(Of T)

(4) Consider explicitly using the Item property , eg: items.Item(0) instead of items(0)

I’m not really comfortable with having to use the Item property: hopefully practices 1 to 3 will alleviate the need for practice 4.

Saving and transferring customisations

bill — Wed, 25 Nov 2009 03:54:10 GMT

I got an email from a reader last week asking about saving customisations in Visual Studio:

Hi Bill

I read an excellent article by you

http://visualstudiomagazine.com/Articles/2007/12/01/Customize-the-VB-IDE.aspx?Page=1

Just wondering if you know of a way to export those customisations so I can set up my computer at work restore after HDD fails and share my favorite settings with friends.

Also would like to do same for my VBIDE customisations

I have googled to no avail...... :-/

Well the good news is this is incredibly easy. On the Tools menu in Visual Studio you should see the “Import and Export Savings . . .” command. You can choose what groups of settings to import or export.

IntPtr gets operators !!!

bill — Thu, 05 Nov 2009 01:48:27 GMT

This seems so incredibly long overdue, but at last as of .NET 4, IntPtr has + and – operators added to it !!

This means you can now easily write code such as :

Dim ptr As IntPtr

. . . .
ptr += 4

this is great when dealing with offsets etc.

The actual implementation is kind of interesting. Here I’m seeing the implementation as :

Public Shared Operator -(ByVal pointer As IntPtr, ByVal offset As Integer) As IntPtr
Return New IntPtr((pointer.ToInt32 - offset))
End Function

I guess this is because it is the 32 bit version of the library. Hopefully in the 64 bit version it calls on IntPtr.ToInt64 ;)

Windows Virtual PC now on MSDN

bill — Thu, 08 Oct 2009 04:23:01 GMT

If you’ve got Windows 7 installed, the Windows Virtual PC for Windows 7 is now on MSDN subscriber downloads !!!

I had the Release Candidate (RC) installed, so had to uninstall that first and reboot before installing the RTM release. All worked perfectly, and my VPC’s from the RC also are working fine :)

If you need to uninstall the RC you’ll find it listed under the “Programs and Features” window from Control Panel. Click on “View installed updates” top left of window, and you’ll find it listed under “Microsoft Windows”

Windows crash recovery

bill — Thu, 24 Sep 2009 03:17:31 GMT

Last night I accidentally pulled out the wrong power plugs, crashing my computer. For some reason this meant it wouldn’t start properly. I don’t quite get why that would mean it wouldn’t start as the hard disc didn’t fail, but none the less it wouldn’t : the computer would seemingly just hang and the keyboard was no longer responsive and its lights went out. The good news is that start-up offered a recovery, and that recovery fixed it and life is good again. The thing to be aware of though is the recovery boot seemed to be hung for a long long time ; I’m talking like 20 minutes or half an hour.

If this happens to you, just be patient: it worked for me :)

Updates on the Snippet Editor

bill — Thu, 03 Sep 2009 01:03:56 GMT

First the good news :

The February release of the Snippet Editor has now had 10,000 downloads !

Now for bug fix news:

There were a couple of issues with the paths per language. A problem with Express Editions of Visual Studio occurred due to partial entries in the registry I didn’t for-see. Initial design and testing was done with full versions of Visual Studio, but I want to ensure that it does work with the express versions, that’s why the tool is standalone not an add-in. So the good news is I have fixed those bugs (I think).

If you want those fixes you can use the original source from Feb and just download the updated products.vb file. I’ll probably look at rolling this up into a new release in the not to distant future.

Enjoy :)

Screen-cast recording tools

bill — Sun, 16 Aug 2009 13:56:10 GMT

Recently I got this email from Ted:

Hi Bill!

Love the snippet tool, it's great!

I'm curious, what tool did you use to produce the screencast for the tool? The quality is awesome!

Thanks a lot!

Kind regards,

Ted

The answer to that is I used Camtasia Studio 5. It’s really easy to use and lots of options on output formats. And it will even produce the basic html file for you with the embedded video etc.

Note: I really like Camtasia. I do also get it for free from the nice folks at TechSmith as they value the contribution MVPs make to the community, and that makes it even easier to like :)

An alternative worth looking at is Expression Encoder 3 Screen Capture which comes with Microsoft Expression 3. I’ve only given it a quick test drive and it seemed pretty good. Picking formats was a little daunting, but I got it to produce some good quality wmv files that were really good for the bandwidth (small file size). I haven’t driven it enough to find how to produce web files that embed the video; my guess is it would be more silverlight orientated. Still if you have a MSDN subscription that includes expression, it’s definitely worth a look at.

Expression 3 is on MSDN

bill — Mon, 27 Jul 2009 08:01:58 GMT

With all the focus on Windows 7 RTM announcements, the availability of Expression 3 on the MSDN site last Thursday may have sneaked under folks radars. For MSND subscribers, grab your copy of Expression 3.

XML namespace prefix 'xmlns' is not defined

bill — Sat, 24 Nov 2007 14:58:27 GMT

When working with VB9 you may get this cryptic error :
XML namespace prefix 'xmlns' is not defined

If you are using only default namespaces you can fix this by including a definition for the xmlns as an Import statement or as an xmlns attribute on the XML literal. But if you are using prefixed namespaces imported at file level, then you must add an imports at project level via the project properties reference tab.

You have two choices:

Import System.Xml.Linq for the entire project, or
Import a namespace for the entire project

If you decide to import a namespace it can be any namespace at all. I named one _do_not_use. Problem is it will show up in XML axis properties in intellisense, but with a name like _do_not_use, that isn't really a big problem. Of course you could add one that you might want to use.

You may prefer to simply import System.Xml.Linq, but I thought I'd at least throw all the alternatives out there for you to decide what suits you best.

hopefully this is another bug that will make it into 2008 SP1 ;)

Cleaning up your XML literal namespaces

bill — Sat, 24 Nov 2007 05:16:00 GMT

If you use XML literals in your code, adding one to another:

Dim e1 = <a:books></a:books>
dim e2 = <a:book></a:book>
e1.Add(e2)

You will have the xmlns declaration repeated in each of the elements, when really it is only needed once per the document or outer element. The problem is caused by VB adding a xmlns declaration as an attribute to the root element. It can get a bit more complex if you have duplicate namespace declarations with different prefixes. So I decided to write a CleanUpNS extension, that keeps the xml written clean by removing un-necessary namespace declarations. To use it, simply add a call to CleanUpNS to the end of your literals, e.g:

Dim e1 = <a:books></a:books>.CleanUpNS
dim e2 = <a:book></a:book>.CleanUpNS
e1.Add(e2)

   <Runtime.CompilerServices.Extension()> _
 Function CleanUpNS(ByVal el As XElement) As XElement
      Dim current = el.LastAttribute
      Do While current IsNot Nothing
         Dim temp = current.PreviousAttribute
         If current.IsNamespaceDeclaration AndAlso el.Name.NamespaceName = current.Value Then
            current.Remove()
         End If
         current = temp
      Loop
      Return el
   End Function

I go into more details about how this works and how the XML is stored and emitted in my January On VB article in Visual Studio Magazine.

Snippet paths and duplicates in VS 2008

bill — Wed, 21 Nov 2007 01:07:17 GMT

If you install VS 2008 on a machine that has VS 2005 on it, you'll be prompted to let VS 2008 import as many of your settings from 2005 as possible. Generally this is a good thing, but you might run into some issues with code snippets as you might have both the 2005 and 2008 collections loaded in VS 2008.

The problem is Visual Studio stores snippets by default in the %InstallRoot%, which for VS 2005 is Program Files\Microsoft Visual Studio 8 and for VS 2008 it's Program Files\Microsoft Visual Studio 9.0. But when Visual Studio migrates your settings from 2005 to 2008, it just copies the registry value which include %InstallRoot% in the paths as a replacement variable. So what this means is if you modified the snippets by hand or using some other tool, your new snippets will NOT include the ones you previously modified.

If on the other hand you used the snippet editor in 2005, it saves the paths as the full path, so in VS 2008 you'll have both the 2005 paths and the 2008 paths. This also is not ideal. You can quickly remove the root folders you don't want by right clicking on them and selecting remove. (Note: root level folders are the folders stored in the registry and have a blue asterisk on them in the snippet editor)

In either scenario you are still faced with maintaining multiple collections of snippets by default. The best thing you can do is to create a folder in your user do documents folder, and then move sub folders and snippets to that path. This makes it easy to share snippets between versions of Visual Studio. You'll need to open the collections to remove the paths that are in the %InstallRoot%, but once done you have a centralized common folder tree for your snippets.

In fact, I like the idea of doing that so much, I think I will add a wizard to the Snippet Editor that does this for you. This would also let you have your snippets where you don't need administer rights to modify them.

There's also a couple of other minor changes I plan to make later this week, such as surfacing the collection selection onto the folder pane.

Oh, and if you are using the Snippet Editor as is with VS 2008 alongside VS 2005, you might be seeing duplicates for snippets in Visual Studio but not in the Snippet Editor. This is yet another one of the undocumented "quirks" about how Visual Studio deals with snippets. If you look in the languages\CodeExpansions key registry you'll probably see some values stored under "Basic" and others under "Visual Basic". This is a "temporary" state. If you run Visual Studio's Snippet Manager and click on the OK, it will remove the "Basic" key and put all the values under the "Visual Basic" key, at which point the Snippet Editor and VS's Snippet Manager will all be showing the same collection. When I wrote the Snippet Editor, once the "Visual Basic" key was established in the registry, it meant that the collection was already initialised. If it wasn't there then I'd initialise it for you. Same kind of thing with "CSharp" and "Visual C#". But now with 2008 that pattern has changed, as in both keys can be there.

Unfortunately little of this if any is documented, so it means my code has to be reactionary rather than pro-active: That is, I have to fix it when they do things that break it ;)

Bug in XML literals around the Imports keywords..

bill — Tue, 20 Nov 2007 08:22:06 GMT

In VB9, there's a bug when using XML literals with any type member that is a protected keyword. For example, given the following psuedo types,

Class Doc
Public Property [Imports]() As List(Of DocImports)
End Class

Class DocImports
Public Property [Namespace]() As String

End Class

The following code won't compile:

Dim d As New Doc

Dim xml = <?xml version="1.0" encoding="utf-8"?>
                <Imports>
                   <%= From item In d.Imports _
                      Select <Import><Namespace><%= item.Namespace %></Namespace></Import> %>
                </Imports>

The trick is to escape the Imports property inside the the XML query:

Dim xml = <?xml version="1.0" encoding="utf-8"?>
                <Imports>
                   <%= From item In d.[Imports] _
                      Select <Import><Namespace><%= item.Namespace %></Namespace></Import> %>
                </Imports>

This seems to only apply to some keywords, not all. Imports, Sub, Function all cause the problem, yet Class, Private and Namespace don't. One thing you'll see is the <%= substitution block won't get the characteristic highlight colour.

And another quirk is if the property is called Option, VB will colour that as if it is a keyword even when it is a property such as stock.Option. This one only seems to impact Option, and does not impact the actual compile, only code aesthetics ;)

VS 2008 is LIVE !!!

bill — Mon, 19 Nov 2007 09:25:08 GMT

Just spotted it on MSDN subscriber downloads.

Enjoy :)

Update on Snippet Editor

bill — Tue, 13 Nov 2007 03:45:20 GMT

I've finally given the Snippet Editor a major make over including a new look.

To go with this, I've given it a new home on my web site:
http://billmccarthy.com/Projects/Snippet_Editor

And I've added a Snippets category to this blog for feedback, info etc. I'll update the web page with new releases if/when they occur including a change history.

Enjoy :)

P.S. I'd love to get feedback on the new UI, especially the "About" screen ;)

Old error, new look !

bill — Wed, 07 Nov 2007 02:16:17 GMT

In playing with Windows.Forms in VS 2008, I got the same old error I use to get in VS 2005 sometimes:

Type must be a type provided by the runtime. Parameter name: type

The good news is it looks so much prettier in VS 2008. It's not fixed, but look, isn't it pretty ?

So why is it that the phrase "lipstick on a pig" come flooding into my mind ???

BTW: The fix is to show the DataSources window before trying to open the form designer

Snippet Editor 2008 release

bill — Tue, 06 Nov 2007 11:49:00 GMT

I've updated the Snippet editor to work with Visual Studio 2008 and 2005 releases.

Note this release requires .NET 3.5.

Changes/fixes:

Added 2008 product range to the list of products
Fixed replacement of the install root variable for Visual Studio that was resulting in a double \ midway of file paths
Removed VB's single instancing and replaced it with named pipes messaging. This fixes various issues to do with firewalls, and the remoting VB tries to do. See Visual Studio Magazine November for details on the NamedPipes usage.
Set the required permissions to run the application as Administrator for Vista. Without this, the app would run, but snippets would be saved in the VirtualStore where Visual Studio wouldn't see them properly. The problem revolves around Visual Studio having the snippet stores in the Program Files tree.

~~The download includes the source and the release build. (in the bin\release path)~~

UPDATE: The files are now available from my web site (http://billmccarthy.com/Projects/Snippet_Editor)

Enjoy :)

Oh so you want polymorphism ???

bill — Mon, 05 Nov 2007 05:47:00 GMT

I recall almost four years ago to this day, I was at the 2003 PDC in LA. On the last day of the conference, the head architects of different .NET languages got together and talked about language directions, generics and some of the "VS 2005" stream of things. There was a Q&A session at the end, and I stood in line to ask a question about generics. They were about to cut off all questions, but I managed to ask the final question for the day. I asked about generics and "polymorphism". Anders didn't seem to quite get what I meant at first, then when I gave the example of being able to treat IList(of Apple) as IList(Of Fruit), he said "oh you mean generic covariance and contravariance" or words to that effect. The reply was no, saying the cost would be too high although he did suggest one of the other less common languages on .NET (no not VB <g>)

Fast forward four years, and now the C# team are finally talking about this ! At first I thought cool, Eric and the C# team are onto this. Then around his seventh or eight post on the topic he started to loose me as it seems they've shifted the focus on to a new syntax for defining the interfaces, which isn't really going to address the issue IMO. And I question just how that will surface in the IDE, and whether T is + or - really even makes sense at the interface level as it really needs depends on whether T is a return value or a parameter. Potentially I could see some advantage there, probably to do with that functional programming cloud, but it seems to have drifted away from the real need.

The most common need I see is when you have things such as a List(Of Customer) and you want to work with it as a List(Of BusinessBase). It's also especially difficult when you are passed the list as an Object, such as from a DataSource and you want to check to see if it is a IList(of BusinessBase). Really what we need is a view of the object.

Some views are safe, such as treating an IEnumerable(Of Customer) as IEnumerable(Of BusinessBase), but others are not, such as IList(Of Customer) to an IList(Of BusinessBase), but for the most part when we want those views we are interested in only the safe part. It's not like we can retrospectively change IList, or that at present we could have one Interface definition for the Item Get, and another for the Item Set. What would be nice is being able to use a view, and the compiler/IDE warn if you use any of the unsafe part, like Item Set, or if you pass the view to a method etc, yet allow you safely to do things such as access Count, get the Items and do operations on them as if they were business object base classes. These things are safe, yet today generics does not allow for that (note if you have generic parameters cascading throughout this issue does not arise, but that doesn't work with Object parameters, or current event design etc)

So some psuedo verbose code to explain what I would like:

' assume datasource is As Object, but is a IList(Of Customer)

If datasource IsViewable As IList(Of BusinessBase) Then

   Dim view As ViewOf IList(Of BusinessBase) = ViewOf( datasource, IList(Of BusinessBase))

   For i As Int32 = 0 to view.Count - 1

           view(i).Validate ' legal as Validate is defined on BusinessBase

          Dim temp as BusinessBase = view(i) ' legal

          view(i) = temp ' compiler warning of potential runtime error
Next

Likewise you could create a ViewOf IList(Of Customer) from an IList(Of Person), but here the inverse would apply in code, meaning you could add a customer to the datasource, but you'd get a warning treating a person as a customer as that might not be the case.

If the datasource is as object though, the compiler can't know if the datasource is contra or co variant to the view. By default a "View" should be treated as a widening, that is a ViewOf IList(of BusinessBase), would mean the datasource is assumed to be a ViewOf IList(Of DerivedFromBusinessBase). The same rules for variance as we see today with delegate variance would apply. If the view wanted was one that is potentially unsafe, such as IList(Of Customer) from an IList(Of Person) then the view should be specified as a NarrowingView.

I don't want to redefine IList, or have to mess with defining which generic parameters are covariant and contravariant and where. What I want is to be able to deal with generic types with variance and create views such as the compiler tells me what is and isn't legal with that view, what's safe and what isn't. And most importantly it has to work with existing generic types and interfaces out there today.

So perhaps my response is four years late, but no I don't mean contravariance and covariance, I mean polymorphism :)

Counting deck chairs on the titanic

bill — Fri, 02 Nov 2007 05:57:27 GMT

Paul Vick released some statistics in relation to VB, which for discussion sake I'll repeat here :

Visual Basic is the #1 .NET language (as reported by Forrester Research)
Visual Basic is the #1 downloaded and #1 registered Express Edition (topping the #2 position by 20%)
Visual Basic is the #1 MSDN language dev center and blog in terms of traffic
The Visual Basic Team blog is in the top 1% in readership of all MS bloggers (I don't know where I fall in that since I host independently.)

I think you'd have to be taking the happy pills to see anything great in those stats, after all they avoid real numbers and they don't tell the underlying trend or growth.

Five or so years ago, before .NET formally launched, Microsoft reported VB as being the *MOST* popular language of *ALL* programming languages. Reports from Forrester backs this up, and this graph from O'Reilly books shows that VB was the most popular titles.

Note in the above graph that VB was as popular as Java at the start of 2003 but has been on a steady decline. C# on the other hand was showing a slow but steady increase.

Forrester also in mid 2005 released these figures:

Java's 66% penetration is the highest among strategic programming languages for enterprise applications.
Visual Basic 6 (VB6) and C/C++ have nearly as much penetration as Java,
Visual Basic .NET (VB.NET) had 34% penetration
C# had 15% penetration
If all VB6 users converted to VB.NET, its share would increase to 70%.

The last statistic is an interesting one, what it tells us is that VB was the most popular language, and by mid 2005 VB.NET had managed to attract less than half of those VB had prior to the move to .NET.

More recent statistics are harder to come by. Anecdotal reports are that book sales of C# related topics are out selling VB at the ratio of 2:1. If books aren't a great indicator of growth trends perhaps jobs are. Searches at seek.com.au show C# jobs running at 7 jobs per every 3 that specify VB. There's some overlap but that's still a greater than 2:1 ratio. Likewise jobs at monster.com tally up similarly. Interestingly both also show J2EE about on par with C# and Java slightly higher. If you combine VB and C# there's not much in it compared to Java overall in the job market.

So what of stats from Microsoft ? Surely Microsoft would have figures and be touting it's success ?? Well no, not really. These cryptic figures Paul released are all I can find except for anecdotal quotes such as the quote from Joe Stagner that there are more VBers than "C# folk but the gap is narrowing". So what is it Paul actually is telling us ?

1. Visual Basic is the #1 .NET language (as reported by Forrester Research)

Okay so VB has gone from being the most popular language, to being just the most popular on .NET, a relative decline in market share. And the titanic was still the biggest floating ship right up till the moment it sunk, even when it was taking on water. To take a language from the most popular of ALL languages, to one of just a subset of languages is a negative trend :(

2. Visual Basic is the #1 downloaded and #1 registered Express Edition (topping the #2 position by 20%)

That figure alone is to be expected given VB6 was the most popular. You'd expect those people to at least try out VB Express unless marketing really screwed up. Again it tells us nothing about forward trends, just an indication of the past penetration that was there

3. Visual Basic is the #1 MSDN language dev center and blog in terms of traffic

Again that related heavily to the previous versions of VB. If you visit the VB MSDN site, that's where you also find info on previous versions. Look at the downloads for VB, and even today the most popular download is Visual Basic 6.

4. The Visual Basic Team blog is in the top 1% in readership of all MS bloggers

There are about 4500 blogs on MSDN, so 1% is the top 45 blogs. What that is telling us is that the team blog for VB only rates in the top 45 of blogs for Microsoft's Developer Network blogs. What are the other 44 ? And what does that tells us ? That we should all be programming in Scobble ?

I think the sad truth is that VB continues to decline due to market place perception. VB is in fact a very capable language. In fact in many ways it is better than C#. Form a pure technical perspective VB is the best language of the two for working with COM legacy applications. In 2008, VB is also the best of the two for working with XML. C#'s only technical feature that gives it a real edge is unsafe code.

So why is VB declining while C# is on the rise ? Microsoft is heavily to blame here. Although they say you are free to choose what ever language you like, they don't do that, they continue to choose C# over VB and the market place knows that. Given it's their platform we are actually coding on, it's understandable that we view their developers as leaders. And they lead towards C#.

Cost and time also figure into it heavily. Microsoft has sent out a clear message that if you want to work with Windows Live Id, Windows Search, Health Vault, .NET Micro Framework, XNA, then they don't view VB as important enough for them to vest any time on, so why should/would you ? They've made it clear they are going to pigeon hole VB.

Let me give you an example. Let's say today you wanted to incorporate the latest from the Patterns and Practices team. If you go over to CodePlex, you'll find the latest code in C#. If you want to build your app, but still have the flexibility to make changes, you'll need to go with C#. In fact if you look over at CodePlex, you'll find that C# projects outweigh VB at the ratio of about 7 : 1. And many of those projects are lead by Microsoft employees as part of their day job.

This leading of community projects, the work being done internally around C# all lead to C# developing greater market share as well as improving C# itself as the language gets "dog-fooded" more by Microsoft, thus gaining input from some of the world's best developers from practical usage of it. It's self feeding.

For Microsoft as a whole, they look at .NET penetration. The increase in C# at the expense of VB doesn't really matter, it's overall market share that does. Except perhaps for one really telling statistic. As Forrester said, if all the VB community switched to VB.NET back in 2005, VB would have had 70% market penetration. Given such a huge potential, it has to be negligent to let that slip away, and instead favor a new language because internally more people at Microsoft used C++. Really, the question should have been was there ever any need for C# given VB's huge market share ? Now the question is beginning to be the opposite.

And so it goes, we should be happy when they tell us how many deck chairs on the titanic, that the ship is unsinkable, yet we see the water line drawing nearer and nearer.......

OK is not OK, but Close is ?

bill — Thu, 01 Nov 2007 02:22:58 GMT

I've been rummaging through the Windows Vista User ~~Interface~~ Experience Guidelines draft, a 33 MB pdf file, and it poses some interesting questions around warning and exception dialog messages. Now apparently it is not OK to present the user with an exception message and an OK button. Instead the guidelines recommend the button caption should be "Close". Is that close as in "so close but yet so far" ? Or close as in we're about to shut down your application and windows and you'll loose all unsaved work ? (that one always gets people when you use a modal dialog <g>) .

Close seems incredibly wrong to me. In fact I'm sure when I've assisted folks over the phone and some other application or windows has presented them with only the option of "close" it has caused much angst. I raised this with Nick Randolph and he suggested that perhaps a better caption would be "Continue" . I think that's a good option in some cases. In others where you can't continue as such, instead you "Resume" and in others you might go back to the screen/page from where you launched the original request, hence "Back".

Continue, Resume, Back, and dare I even suggest Retry or Ignore, but not Close.

Schemas in the scheme of things...

bill — Sun, 28 Oct 2007 13:17:13 GMT

I got an interesting email today, which, to paraphrase, said:

I would like a syntax where I can say “an XElement that follows this XSD"

This question actually digs deep into the issue of strong typing versus dynamic typing and what it really is we want from a type system.

A lot of people think of strong typing as a forced constraint that ensures that types used are are of a particular type and that this constraint can then be used to facilitate design time checking and the intellisense experience. Although this is true, people often forget that the strong typing doesn't eliminate type errors, it just limits them. For example, whenever you do a narrowing cast you risk a runtime error not a design time one. In .NET the need for narrowing is pretty common: one only needs to think of the standard event signatures where sender is always As Object. So what strong typing does is "shift" some of the errors. When it comes to XML the concept of shifting the validation of the object becomes even more important

To address the problem of strong typing with an XElement, you could use inheritance but this raises a lot of issues. Factory methods such as Load return an XElement, so you'd have to provide your own Load methods. In the end it'd probably be easier to have your object model not inherit from XElement, rather just use XElement as the internal container. This would give you the ability to write POCO (plain old CLR Objects) classes for your data, but in doings so you face a couple of serious design issues. If you choose to validate the data at load time, that can cause excessive delays in loading the XML especially if parts of it are not used. If you don't validate at load, your object model can actually have an invalid state and do unpredictable things such as throw exceptions when a property is accessed. And there's also the issue that XML can contain more data than the schema dictates. Do you loose that data or preserve it ? If you preserve it, then how do you provide access to it while also preserving the other data integrity ?

As you can probably see, there's a mismatch here between POCO and XML

If the goal is to validate the XML, you can do that with XDocument by providing a XMLReader with the XMLReaderSettings set to validate against a schema. Alternatively you can let the exceptions occur when a member is accessed. So XElement provides a flexible way of validating either when loaded or when accessed. But what's missing still is the design time experience......

So how can we get a great design time experience with an XElement akin to strong typing but without all the drawbacks strong typing and POCO present ? I think the answer is in dynamic interfaces that are XElements, not POCO. For example let's say I could write a:

Public XInterface IPerson
    <Name> As String
    <Age> As Int32
    @ID As GUID
End XInterface

You could then define an XElement parameter or variable as IPerson, and get a great design time experience. You'd still have to decide if you wanted to validate your XML when you load it, or just wait and see, but really that's a great performance flexibility :)

The XInterface above is a simple model where you define the values in term of CLR types, so when accessed the appropriate conversions will be done from you from XML to that type. For more complex models it's be nice if you could also define a XInterface from a schema, and the compiler would infer the appropriate CLR types from the XML types. In this case you'd have to provide the schema to define the interface.

Imports XElement IPerson = "myPersonSchema.xsd"

Where "mypersonSchema.xsd" would be the name of a file in the project or a file path or URL/URI.

With dynamic interfaces that are based around XElement, you could provide a really great rich design time experience for XML.