William (Bill) Vaughn's Musings

March 31, 2006 • Vol.28 Issue 13
Page(s) 25 in print issue

As some of you know, I live within artillery range of the main Microsoft campus. That’s a term my dad (a former Army artillery and air-defense officer) would use when he wanted to keep the city elders in El Paso, Texas, aware that his home overlooked the city and he could easily lob a few rounds of 105mm artillery down on city hall if they strayed from their elected duties. The relationship I have with the folks on campus is not quite that strained but gets pushed to the limit from time to time.

After their last reorg, the latest Product (or is it Program?) Manager assigned to the Visual Studio team gave me a call so we could talk over some ideas about improving the design experience for building CLR executables. Since I had just finished the chapter on this subject for my new book, I had quite a few ideas for him. I thought that I would share these with you as well so you could provide some additional real-world feedback. It’s not too late for you to submit your ideas about the next version of Visual Studio, so I encourage everyone to turn them in. A few ideas I suggested to help developers create CLR executables include:

Protect your IP. One of the issues that’s come up recently (besides the issues I raised last time) is protection of intellectual property—in other words, protecting the investment you’ve made in that fancy CLR executable that makes your application different, faster, and sell better than its competitor. As it is, when you use Visual Studio to build a CLR executable like a stored procedure, function, aggregate, trigger, or user-defined type, the deploy operation copies the compiled DLL to SQL Server. Unfortunately, by default, the same process copies the source code and all of the files used to manage your Visual Studio project into the system catalogs alongside the binary executable DLL. What this means is that anyone who has access to the database (such as your customer) can run a simple query against the sys.assembly_files system view and return the source code along with the comments—and in the language you used to implement the executable.

Unless you disable source-code deployment for your production builds, anyone can see your source. To deal with this issue and those I mentioned last time, I suggested that Visual Studio change the way that the build scripts are executed and persisted in the project. I think that Visual Studio should simply build “suggested” build scripts as it builds suggested test.sql scripts. Developers could comment out those parts of the deployment script that they didn’t want (like the sections that copy the component source and support files to the database catalogs). This would also give developers a chance to alter the scripts to include the request to overlay a dependent CLR executable (like a user-defined type) instead of having to remove and rebuild all dependencies before deployment.

Improve the “object pickers” in the Visual Studio IDE. As it is when you start exploring the list of stored procedures, tables or other database objects, or classes to reference, you’re often presented with seemingly endless alphabetically sorted lists of items. Given the size of the fonts used in these lists (which can’t be easily changed), it would be far more helpful if Visual Studio used the same technique used by SQL Server to filter the list on schema (owner), name, or date created.

Create a live SQL query window in Visual Studio like the “New query” window in SQL Server Management Studio. This would permit developers to test and refine SQL and make administrative changes to database objects without having to open another application.

Improve the way that hotfixes are supplied. As it is, once you find out that a fix for the bug you’ve been experiencing has been created, you still have to endure a (best-case) 40-minute call to PSS to convince them to send it to you. I would like to see these freely posted on the Web so anyone can download them (at his own risk).

Microsoft is currently in the process of reinventing Visual Studio (again) to fold in a few of these changes and enable better access to Vista, WinFS, and the other emerging technologies the kids at Microsoft keep inventing. This project (called Orcas) is due about the time that Vista goes to manufacturing, more or less, but no firm date has been made public. Note that one of the ground rules at Microsoft for Orcas is that the .NET Framework is not to change. Everything must work with the latest (2.0) version. This is important because if Orcas requires developers to convert their existing Visual Studio 2005 applications, I expect I’ll have to unpack that 105mm howitzer I inherited from my dad.

Posted by William Vaughn at 07:19 PM | Permalink | Comments (0)

Posted by William Vaughn at 08:59 AM | Permalink | Comments (0)

Posted by William Vaughn at 02:24 AM | Permalink | Comments (0)

Posted by William Vaughn at 03:38 AM | Permalink | Comments (0)

March 18, 2005 • Vol.27 Issue 11
Page(s) 20 in print issue

With apologies to the other William, this is the question many Visual Basic 6.0 developers are asking as they migrate to .NET. Should they transition to Visual Basic .NET or retool and switch to C#? It's clear that those of us that like, nay love, Visual Basic are troubled as we see more desertions from our ranks.

Those loyal to Visual Basic are assailed by many who would have them switch to some other language like (dare I say it) C#. There are many who whisper gently but persistently in their ears that Visual Basic is dead; for sissies, beginners, and hobbyists; not for "real" programs. Some even say, "Microsoft doesn't use it for its programs, why should we?" Some of these whispers come from people everyone should trust—people on podiums who know better and people acting as trusted consultants. So these Visual Basic developers—even those that have already transitioned from Visual Basic 6.0 to Visual Basic .NET—are confused.

The Rumors Of Visual Basic's Death Are Premature

I don't think C# is evil. I do think, however, that it's the wrong choice for Visual Basic developers transitioning to .NET. We need to keep in mind that Visual Basic is the most widely used programming language on the planet with 4 million to 9 million followers, depending on how they are counted. If you as a consultant, pundit, or writer offend or insult the intelligence of these people, you aren't doing yourself or your business any favors. The Visual Basic bashers that would have you believe that you can't create "real" applications with Visual Basic are just misinformed or have another agenda.

No, Microsoft does not use Visual Basic for the bulk of its work on systems software; it uses C++ and C. Why not Visual Basic? Perhaps it's because those developers (many with a decade or more of experience) have to work with millions upon millions of lines of code written in C and C++. Some found it easier to transition to C# and Managed C++.

Why are so many examples written in C# and not Visual Basic .NET? For the same reason: Those developers writing the code, white papers, and presentations are C or C# developers. That's what they know how to do. They either don't know Visual Basic well enough to write a good example, or they were not given enough time to do both. And Bill (the other one) didn't make them. But that's the best reason of all to choose one CLR language over another— your own personal skills. In the end, they both compile down to the same IL—and wait at the same speed.

Visual Basic: A "Second-Class" Citizen?

We've also heard that when developers are asked in a group of their peers if they use Visual Basic, some are hesitant to admit it, but when asked individually, they freely admit to having Visual Basic as one of their skills. It is almost like Visual Basic experience is one of those "don't ask, don't tell" issues. That's ridiculous. Just because a language is easier to use or less disciplined does not mean it's not more than suitable for a serious job.

Yes, less disciplined developers writing less structured code is an issue for a serious job, regardless of the language. While Visual Basic 6.0 has severe limitations in some areas, Visual Basic .NET does not. It can be just as structured and OO as C#. Yes, there are some things that it can't do when compared to C#, things that only 2% of the developer community would ever miss.

Visual Basic 6.0 developers will find no features that Visual Basic .NET does not support but C# does. Sure, using drag and drop can be a productive way to write code—the same drag-and-drop features are in C#. (Actually, these are features of Visual Studio that work equally well with C# and Visual Basic .NET.) That said, we know that many developers (myself included) are hesitant to use drag and drop and the wizards to generate much code. We simply want the flexibility to do our own thing. Visual Basic .NET gives you that flexibility—just like C#.

Should You Transition To .NET?

Another issue we've discussed is whether to transition at all. Is this trip really necessary? Sure, if it's not broken, don't fix it. But as the world gets more dangerous, it becomes more and more of a burden to protect ourselves and our customer's information from those who would despoil it. Our systems have been descended upon by a plethora of pirates, plunderers, panderers, privateers, and those who would steal our very identities. We need better tools to protect ourselves. A well-written .NET application written in Visual Basic .NET (or C#) can be that shield. It's tough to fight the bad guys with muskets when the people coming over the wall are using laser-sighted M16s.

If you want to follow along or participate in this discussion, be sure to check out my new blog at www.betav.com/blog/billva.

Posted by William Vaughn at 07:24 PM | Permalink | Comments (0)

March 17, 2006 • Vol.28 Issue 11
Page(s) 26 in print issue

Lately I’ve been pounding away on the CLR chapters of my new book “Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition).” Before starting the CLR chapter, I wanted to poll the current state of the industry to see what they think about using Visual Basic .NET or C# (or one of the other CLR languages) to create an SQL Server 2005 stored procedure, function, user-defined type, trigger, or aggregate.

Joe Celko is against their use, based on his editorial comments (www.sswug.org/see/22557), and he’s one of the most respected in the industry. Others whose opinion I respect are more ambivalent. They feel there are places that cry for the functionality and performance promised by sophisticated compiled code and other situations where it makes no sense at all.

Evaluating CLR Executables

At this point I needed to decide for myself whether CLR executables make sense. Since I’ve been working with SQL Server 2005 since the earliest versions of Yukon, I was fortunate to get some advanced bits long before the general public and had already formed a few opinions. All during the alpha/beta cycle, we fought many battles in an attempt to make the CLR executable development process easy and the integration into T-SQL seamless. Unfortunately, most of the CLR routines I wrote during the betas were slow in comparison to the T-SQL equivalent code—sometimes pitifully slow. Sure, I wrote useful functions that could not even be attempted in T-SQL, but for the mainstream stored procedure or function, the CLR code was like bowling with oblong river rocks.

No, it's not fair to judge any product under development, especially for performance. Microsoft kept reminding everyone of this for years. Since Yukon (SQL Server 2005) is a radical departure from the "old" SQL Server 2000, there were bound to be areas that needed to be tuned up and redesigned during the final development process. But now that it's shipped, we can take the gloves off. To this end I wrote a whole new series of tests and examples. I rewrote my temperature converter and currency UDT (user-defined type) and created several other “typical” examples that are often touted as functionality that should be implemented using CLR executables. These include a GPS function that computes the distance between two points using latitude and longitude, a GPS UDT to store a map coordinate in a single column, and a series of “text munging” examples. While I’m not quite done with the chapter, the performance results have been crystallizing. And they’re a bit surprising.

A Few Surprises, A Few Glitches

The temperature conversion function that changes Fahrenheit to Celsius is a bit faster than the same routine written against Beta 2, but it’s about as fast as my Model A on the tollway between Lawrence and Emporia. An operation as simple as temperature conversion is not a good choice for a CLR function. In contrast, the new currency UDT generated a dramatically smaller data footprint and seemed to run at a respectable speed.

The most surprising were the GPS executables. These use several trig functions to calculate the distance between two lat/long points. Most folks would believe T-SQL could hold up under the CPU strain. While T-SQL did okay, the CLR routine was just as fast—within 0.005%. This means if you have even a moderately complex math formula, it makes sense to code it in a CLR language. The text crunching examples also ran as fast or faster than the T-SQL equivalent but were far easier to write.

The other benefit to writing your SQL Server executables with a CLR language is developer performance. The stored procedure and function preambles are simple to understand, and the code body is even simpler to write. User-defined types are a bit daunting at first, but you can build them fairly quickly. Intellisense and Visual Studio help. This means your routines can be coded with every construct the .NET Framework languages expose, and any CLR language is far richer than T-SQL. You get sophisticated branch logic, real exception handling, far better string handling, real collection and array constructs, and more. The only stumbling block might be Visual Studio 2005 CLR executable debugging. Visual Studio 2005 is far better than coding, compiling, and deploying CLR executables by hand as they illustrate in the SQL Server documentation. But Visual Studio 2005 can be frustrating when the IDE or “Debug Manager” repeatedly fall over.

Microsoft didn’t figure out how to build, deploy, and test a UDT without jumping through hoops. Despite these issues, the step-through-debugging process is better than ever and seamlessly step-debugs into T-SQL or other CLR executables. Microsoft knows of these issues and I expect them to be fixed sometime this summer.

Posted by William Vaughn at 07:21 PM | Permalink | Comments (0)

Posted by William Vaughn at 04:02 PM | Permalink | Comments (0)

Posted by William Vaughn at 03:07 PM | Permalink | Comments (0)

While I was invited to VSLive Orlando and DevTeach Montreal this year, I was forced to turn down these kind invitations. I am taking time off to speak at SQL/Visual Studio Connections in Orlando the week of April 4th. I'll also be passing through the Kansas City .NET user group on the way to give a talk on ADO.NET “Connecting“.  I'm also giving a talk at TechEd in Boston and I hope to visit user groups out there if invited.

 I'm focusing very heavily on my new book “Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)”. For the last month or so I've been focusing on the SQL Server CLR Executables chapter that has grown to over 90 pages so far. I've discovered a wealth of un and under documented features and issues that once discovered will make developing CLR stored procedures, functions, user-defined types, aggregates and triggers a lot easier. I also include a section on leveraging these executables from other applications--where it's possible.

Next on the agenda is the Visual Studio ReportViewer control and the reporting features of Visual Studio 2005.

Peter Blackburn and I hope to have the first draft done in the next couple of months and published by this summer. So far we have over 600 pages and we're still going strong.

Thanks for waiting.

Posted by William Vaughn at 08:27 AM | Permalink | Comments (0)

Please report any problems posting to this blog. I have some pretty tight anti-spam tests in place that might have prevented some legitimate posts from being accepted. Generally, if your post contains more than two links, it's rejected. This approach was taken as the spammers invariably list a long list of links in their garbage posts. I also reject or delete posts that extole the virtues of President Cleveland--those simply can't be tolerated. 

Generally, I don't like to answer 1:1 technical questions--I simply don't have the bandwidth. I do lurk on the public newsgroups and the MSDN forums which are good resources for free advice. I don't charge any more to answer questions on the forums than I do for questions sent via email, but you have a lot better chance of getting through my junk mail filters.

If you have comments that are not accepted, please feel free to email them to me. I will be happy to post them--whether or not I agree with the comments. My email address is --be sure to put “Comments on blog subject <subject>” in the subject line.

Thanks

Posted by William Vaughn at 08:18 AM | Permalink | Comments (2)

Posted by William Vaughn at 12:18 PM | Permalink | Comments (0)

Posted by William Vaughn at 11:54 AM | Permalink | Comments (0)