Another O#er is blogging...

Stewart Zanolla

.NET 2.0 Whidbey Presentation in Toronto

On December 9th, myself and Dave Lloyd will present an in depth sneak peak of the next release of .NET: Visual Studio .NET 2.0 (code-named "Whidbey"). This should be a really fun presentation but seating is pretty limited. Adam Gallant from Microsoft is going to come by and also demo Longhorn and Avalon. He's getting daily builds so hopefully he'll show us some cool stuff that wasn't in the PDC build and is maybe even newer than some of the stuff they showed us at PDC. Hope to see some of you there.

NAntContrib "slingshot" vs. NAnt "solution"

I was trying to build the latest NAntContrib project so I could take advantage of their Slingshot task which automagically converts a visual studio solution (*.sln) and projects (*.csproj - not sure about *.vbproj) into a handy-dandy NAnt *.build file complete with all reference, source inclusions, dependencies, debug, release, and clean targets. Nice.

The only problem with this approach of course is that you need to run it daily if you don't want your NAnt builds to break when a new project or reference is added to your solution. Fortunately, NAntContrib exposes slingshot not only as a command line tool but also as a native NAnt task. The pain is that NAntContrib doesn't have a “stable release” but only a “nightly build”.....which of course is not built against the NAnt “stable release”. So I had to throw away my NAnt stable release that I've been using and opt for the latest nightly build for it too. After I got both to compile successfully I started to battle goofy slingshot issues like having to map web projects to my local hd path, avoiding spaces in my paths, and ReallyReallyReallyLongPaths.  I ended up doing a subst to map a directory to a drive letter to make it short. All this to create a build file that will get thrown away each and every night.

While browsing through the new things added to NAnt since the stable release I was accustomed too, I discovered a new task “Solution”. It compiles a whole solution - sln file. No generation of a build file. My build file literally goes from hundreds if not thousands of lines to this.

<target name="Debug">

<solution solutionfile="ObjectSharp.Framework.sln" configuration="Debug" />

target>

This compiles our entire framework, with all 8 projects as referenced in the sln file, in the right order, with the same dependencies used by a developer while using the VS.NET IDE. What a concept: share the build files used by your build server and IDE so that there are no surprises or impedance mismatches. Such a great idea that MS is doing this with MSBuild in Whidbey. I wonder if MSBuild will have add on tasks like NAntContrib, like for Visual Source Safe, sending email, running NUnit, and executing SQL. I like my NAnt - not sure if I'll be able to break free with MSBuild.

MSDN Experimental Annotations Service uses RSS

I miss Win95 winhelp. In particular, I was sad to see in Win98 that HTML Help had not included the annotation feature, the ability to add your own notes to a help topic - any help topic. These were stored in a local .ann file next to the help file if memory serves.

During his PDC keynote, Eric Rudder mentioned and briefly showed some stuff they were doing with the Longhorn SDK to enable threaded annotations, kind of like discussions to a help topic. So I've stumbled on what promises to be a cool site: lab.msdn.microsoft.com. One of the play things is the MSDN Annotations Service. It requires the download of a small plug in for your browser.

It basically works like this...

You visit any page (in theory) on the msdn site (including the longhorn sdk) and you get an annotations window on the bottom. This allows you to add your own comments. Nice. The cool thing is, you get to see other users annotations as well. These annotations are not stored in a local .ann file, no they are stored on the Microsoft site.

Maybe you don't want other people to see your goofy code snippets. Fortunately you can subscribe to your own feeds - so long as they are exposed as an RSS, like say - this blog. If you want to make an entry to a page your visiting, simple paste in the URL to your blog entry (like so: http://longhorn.msdn.microsoft.com/lhsdk/ref/ns/microsoft.build.buildengine/c/target/target.aspx).

The annotation service allows you to subscribe to a feed. While you are looking at a given page - like the one above, if the subscribed feed contains an URL to that page, then presto it shows up as an annotation. Very cool.  The stipulation here is that in the RSS XML feed, the tag has to contain an anchor with that URL.

So does MS listen to your subscribed feeds? No, that's what the small utility plug in is for. It's done on the client.

Yet another creative use of RSS. I'm also told that the MS provided annotations also are scraped from newsgroups.

Sparkle to kill Flash? I think not.

Mary Jo Foley speculates that Avalon is a Macromedia “Flash Killer”.

So I guess that would mean MS is going to extract out the Avalon Graphics subsystem from Longhorn, including the WinFx/.NET Framework which is the API to it, all into a handy dandy ActiveX “Avalon Player“ control and we can all embed that in our web pages. That's cool. I guess that will also mean that MS will back port this to Windows 98, Windows ME, and Mac OS 9.x

Maybe that article should have been posted on slashdot.

C# vs. VB.NET Interfaces

Visual Basic has an interest syntax for implementing interface members.

Public Interface IAdd

Function Execute(ByVal i As Integer, ByVal j As Integer) As Integer

End Interface

Public Interface ISubtract

Function Execute(ByVal i As Integer, ByVal j As Integer) As Integer

End Interface

Public Class Calculator

Implements IAdd, ISubtract

Public Function Add(ByVal i As Integer, ByVal j As Integer) As Integer Implements IAdd.Execute

Return i + j

End Function

Public Function Subtract(ByVal i As Integer, ByVal j As Integer) As Integer Implements ISubtract.Execute

Return i - j

End Function

End Class

The key here is that the function names don't have to be the same as they are in the interface definition. I have two interfaces that both expose a Execute method. They are implemented separately as Add and Subtract. Thanks VB team for the “Implements“ keyword. C# is a different story - and up until a few days ago I didn't think you could do this at all in in C#. Here you go:

interface IAdd

{

int Execute(int i, int j);

}

interface ISubtract

{

int Execute(int i, int j);

}

public class Calculator: IAdd, ISubtract

{

#region IAdd Members

public int Execute(int i, int j)

{

return i + j;

}

#endregion

#region
ISubtract Members

int InterfacesCS.ISubtract.Execute(int i, int j)

{

return i - j;

}

#endregion

}

I used the auto-magic interface template generator built into the VS.NET C# editor. After you type ISubtract on the class declaration, wait for a little tool tip that tells you to hit TAB for a default implementation template. You'll notice the fully qualified function name “InterfacesCS.ISubtract.Execute“ on the second declaration of “Execute”. The whipper snappers out there will also notice that the second method is not public. So it's private you might say. The class view and object browser would agree with you. Don't try putting “private” in front of the declaration. The compiler won't like that. Don't even think of trying to call it directly though. The only way to call this second method either internally to the class (why not it's private) or externally is by casting the reference to the interface, like so..

Calculator calc = new Calculator();

int result = ((ISubtract)calc).Execute(5,4);

 

If you really want to call the method directly without casting it, you'll have to create a wrapper method and expose it publicly or privately if that suits your needs.

public int Subtract(int i, int j)

{

return ((ISubtract)this).Execute(i, j);

}

Thanks to Alex Bershadski for pointing me to a few code snippets in the MS Press C# book about this. The book could really do a better job of identifying the limitations of C# in this regard. At least it can be done. Up until Tuesday, I didn't think it was possible.

October 2003 Visual Studio .NET Documentation Update

It was Eric Rudder who mentioned in his keynote that there was a new update to all the online help for the Visual Studio including something like 5,000 new samples. He mentioned this update like it had been around for months. Well it was posted on Oct 22/2003 in case you missed it.

 It must be good, it's an 80mb download.

MSBuild vs. NAnt

Correct me if I'm wrong but isn't MSBuild a knock off of NAnt or any other derivative of Ant?

Is the only reason MS created such a build tool is so that internal MS employees could use it? Do their employee contracts prohibit them from using Open Source tools? That's my speculation. Please correct me if I'm wrong.

It's not a problem if I'm right - but why not just use it internally at MS? Why make it public for everybody's use. We already have a decent tool and we get the source code to boot - not to mention community support.

I didn't get a chance to go to the MS Build presentation (TLS347) so I apologize in advance if I'm just not getting it. I have looked at the slides but there isn't much there - nothing that I don't see in NAnt.

I'm really looking for the killer reason not to use NAnt and switch to MSBuild. Maybe the answer is this..

MSBuild will be the core build engine underneath Visual Studio and share project file formats with VS.NET. Certainly this has caused me some grief with NAnt in the past, mostly with VB.NET since slingshot (the last time I looked) only converted csproj files to build files and not vbproj. So I think the most important thing about MSBuild is not MSBuild itself but that the C# and VB.NET teams will have to (or already have) collaborated on a unified .proj file format. Hopefully the NAnt contributors will write an XslTransform. As an aside I hear that this level of integration won't be available for C++ developers. Now getting three teams to talk to each other - that's just impossible. I bet that the .proj file format changes again when the C++ team gets around to supporting MSBuild.

In addition to the VS.NET integration, there seems to be only 1 other significant difference between NAnt and MSBuild. MSBuild includes some kind of “full inner-task dependency“ that is supposed to allow for incremental builds. While I might care about this for an IDE experience (slightly) it's less important from a nightly build scenario - IMHO.

Google Smoothies

Apparently google has a booth at PDC where they are giving away free smoothies. I searched and searched and searched but couldn't find it anywhere.

:)

Where is the holistic vision?

Microsoft is needs a holistic view of their platforms and development tools. I didn't see that this week, I doubt any of us will.

What I did see was 7 data access techniques in various stages of ready now, coming soon, and coming much later:

  • Use a DataAdapter to issue SQL  or stored procedures. Useful for working with a DataSet and doing optimistic updates.
  • Use a DataReader to issue a SELECT or stored procedure to walk through rows 1 at a time. Used for fast streaming of read only data.
  • SqlDataSources. From what I can tell, this is a terrible thing. I've seen this in two places so I'm not sure they are the same. The first demo I saw of this it was just called a “Data Source“ It was in a windows forms application and it looks  like a typed dataset (and in fact is/uses them) but it also embeds SQL queries (and updates, inserts and deletes) into the actual typed dataset. But I use datasets through the various tiers of my application from UI to data access and I don't want this marshaled throughout the application. I talked to Paul Yuknewicz from the VB team about this. I told him it would be okay in the design time to do this - but you have to split these out into two classes. He said I could, but he couldn't show me. He said the typed data set and the data access classes could be in separate namespaces. When I told him I needed them in separately assemblies because my datasets go down to the win forms client, but the data access sits in my middle tier and hits the database. He took this as a good feature request, but he didn't give me a good feeling about it. I mentioned this to another guy on the Data team and he said that these Data Sources would not be for me. I suppose if you're building a dog house, it doesn't have to be well architected like a sky scraper. Unfortunately I've had to do many renovations of dog houses in the past.
  • You can now embed some of the logic you'd do post retrieval to massage some data into the database. Yes, create a C# stored proc and return the data that way. You probably want to do this if the processing reduces the amount of ASCII (or the visibility - plain text - no encryption) to be sent along the wire.
  • SQLXML - not new but improved and gaining momentum. Can you say new language to learn? XQuery, XPath. This is nice if the data you deal with outside of the database is in XML. Also good for doing master/detail updates in 1 round trip. I like this.
  • ObjectSpaces. I saw a preview of this at PDC 2 years ago. I'm going to another session to learn more details in an hour. It's changed since then but the message is the same. It's an Object to Relational mapping scheme. You define how your tables relate to your objects - and then you merrily use your objects and ObjectSpaces figures out the SQL to send to the database. Why would you do this? Well if your app embeds a lot of business logic in your objects - which it should damn it. This technique lacks SQL fidelity and you have little direct control over the SQL emitted. Hmm. If I don't know what SQL will be issued how will I determine the best indices? How does the SQL Server team feel about this? I've already heard from Michael Pizzo that you can't expect the same performance as native SQL.
  • WinFS. Longhorn includes a new file system. My interpretation is that it's less of a file system and more of an intermediate object model that sits over top of NTFS and the next version of SQL. WinFS let's you view your SQL data as files. A record is a file. Not all files become records though. (I can hear DBAs everywhere sighing). The idea here is to “give users excellent windows experiences“ by getting data out of the silos of applications and bringing it to the shell to be integrated between applications the way users want it. I like the idea in theory but the security aspects scare me a bit. The nice thing is that this is coming in Longhorn - a long time from now so we have time to think about this more...and for MS to try and get it right. You can bind controls in your forms to properties on files (which are records - so those are just columns). Where is the business logic in that tier? Welcome back client server. Not sure how this all works on a LAN.

I was also saw at least 3 user interface models:

  • Traditional Smart Client Window Forms. These don't' change much in Whidbey.
  • ASP.NET Web Forms. Changing a bit. Still HTML coded into an aspx file.
  • Avalon XAML Forms. See my previous post about this. The key point is that it attempts to bring the benefits of Web Forms to Windows Forms and vice versa.

Let's not get into Pocket PC, Smart Phones, WML, Tablet Ink or Media Center. That would make this blog more ridiculous than it already is. Suffice it say that each of these 3 user interfaces all have their own databinding techniques and they are all different. I saw some of the ASP.NET Whidbey two-way databinding today and its nothing like WinForms binding. It's like that team never talks to the windows team. Sigh.

What I didn't see was anything about COM+, Enterprise Services. Where the hell was COM+. Does that all disappear with Indigo? Indigo is only supposed to be a communication platform right?

I guess it's my job as an architectural consultant to value each of these technologies, how they fit together ultimately - and a road map for doing something useful today - that will be useful tomorrow. Nobody at Microsoft has done this yet.

The scary thing is that it seems like all these teams are working in silos and not talking to each other enough. Seems to be a theme. Don't get me wrong, the are doing fabulous stuff but everybody has a different way of doing things. It seems like they spend lots of time developing their technology but not enough time building real applications that sit on top of them.

The good news is that its early for a lot of this stuff and lots of time to fix it and get it right. A lot of Microsoft guys were seeing some of this stuff for the first time themselves.

I suspect that the MSDN Prescriptive Architecture Group has some work cut out for them.