Helping Orcas Work For Developers
![]()
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.