Visual Studio .NEXT Wish List

At Microsoft’s annual MVP Global Summit, the Microsoft folks asked me for a list of features that I thought should be in Visual Studio (VS) 2010. I've already been keeping a “wish list” on my blog for a while, so now seems like a good time to update that list to reflect what’s in VS 2008 and pass it on to Microsoft. Most of my VS 2010 wish list items are data-centric. That’s because I’m a data guy and most of the applications out there access data one way or another. I'll consider recommendations for other VS wish list items as well. But first, I'd like to run the list by you and see what you think.

The "Real" RTM of VS 2008

VS 2008 isn't complete. Unlike VS 2005, VS 2008 doesn't offer the ability to create, test, or deploy SQL Server Reporting Services (SSRS) reports. It also doesn't access the new SQL Server datatypes or ADO.NET 3.5 features related to SQL Server. I can't even open a VS 2005 Business Intelligence (BI) project—and still won’t be able to even after VS 2008 SP1 ships sometime after SQL Server 2008 goes to manufacturing. Microsoft tells me that this functionality will be brought back to life post SP1, but what about the year in between? Although I would like to use VS 2008, I have to revert back to VS 2005 to do so.

Also, two of the more important innovations in VS 2008 is the new Local Data Cache and ADO.NET 3.5 Synchronization Services. However, if developers try to use these against a SQL Server 2005 database, their catalogs (table schema) must be munged or mangled to support the additional columns used to keep local and hosted tables in sync. I find it hard to recommend this feature (as cool as it is) because the SQL Server 2008 implementation uses behind-the-scenes functionality to enable it. The wizards will add columns to the target table (the one to be synced) on the server. Right after that the DBA comes and sets fire to your desk. It seems to me that Microsoft should have held Visual Studio 2008 until SQL Server was ready or not exposed the feature in Visual Studio until SQL Server was ready.

Add a Sync Button

I think code generation is an accepted practice in general, and it's understood that part of VS's job (regardless of the language) is to generate code to lay out the forms, load and describe the controls, and provide the plumbing to connect these controls with data sources using the selected language.

The fundamental problem with code generation is that VS hard-codes these elements. That's fine for the bulk of the UI controls: You can easily move them around or re-dock them as necessary. However, when it comes to the data structures behind the scenes, hard-coding schema is a serious problem. The TableAdapter Configuration Wizard, like its predecessors, makes one big fallacious assumption: that the data catalog (what we used to call the schema) is fixed, cast in stone. As you well know, in every stage of application development from newly created apps to those being modified for the fourteenth time, the database catalog is always subject to change. Although a disciplined shop might restrict these changes, changes occur nonetheless.

Because VS has hard-coded the generated TableAdapter classes, simply changing a column in a database table from an Int to a Long can be problematic. As it is, after a developer uses the wizard to code-generate a class against a database table, there's no mechanism to get VS to correct that generated code to reflect these changes without a lot of drag-and-drop work.

As difficult as it might be to create, I think the TableAdapter Configuration Wizard should have a “catalog sync” button to walk the schema as addressed by the ConnectionString and compare it to the generated code. If there are changes to be made, it needs to either add a list of tasks to repair those changes or simply make the changes. Hard-coding schema-specific SQL in applications is something we’ve been telling front-end developers to avoid for decades.

Set Up a Metadata Catalog

When we build a forms-over-data application whether it’s hosted in Microsoft Internet Explorer (IE) or on the Windows desktop, it’s the application’s responsibility to validate the data. Unless the data is validated, it shouldn't be saved anywhere. To this end, our applications should validate every entry by every user and validate every record that arrives from another data source—even a trusted one. Validation goes way beyond “type safety,” which only validates that the data conforms to a fairly loose type constraint. I, for one, implement Defaults, Rules (yes, rules), constraints, typed-parameter stored procedures and in some cases triggers on the SQL Server database to make sure that if something evil gets through, it’s not added to the valid data. However, I believe these validation rules should be done while the end user is focusing on the content as it’s entered.

Mapping business rules, validation criteria and other constraints to UI controls could be made a lot easier in VS. While developers can use Visual Basic expert and MVP Billy Hollis’s great UI controls to help incorporate the metadata to validate the keystrokes, a lot more can be done. I propose that VS help the developer community set up a metadata catalog for each product (a set of selected rows over a table or product of a JOIN) that we expose to the application. That way, when the business rules change, the code and UI controls can be morphed automatically. These metadata values would include “min,” “max,” “mask,” “default,” “valid values list,” “caption,” “read-only,” and more; potentially, a lot more. I propose that this metadata be standardized so that it can be stored in the database along with the database tables so that it can be leveraged to generate code and requeried by VS when the developer changes it.

Because developers need a standard way to expose and store meta data, it means there should be a way to define and manage the metadata for an entire table as well as the database itself. Table metadata might provide alternate table “names” to be used to build UI elements, the PK, and other suggested filtering columns. It could contain ownership (schema) details or other easily accessible data to describe how the table should be used.

I call this approach “soft coding” (as opposed to hard-coding) the generated code. If the code generators were designed to be driven from the data catalogs and from metadata that was expected to change not only at design time but at runtime as well, applications would be able to automatically adapt to current business rules, constraints, and end-user preferences.This metadata could also be stored locally in a SQL Server Compact Edition database so it could be accessed when the application is disconnected.

Disable Tables Check Box

After all these years, VS still builds its generated code DataTable classes as if developers should map the entire table in a database. VS even exposes a Tables check box to let the developer choose all of the tables in the database for TableAdapter code generation. While this check box might make it easy if you’re building a toy application or a demo, no developer (or developer's manager) in their right mind would do so. This check box should be disabled. Consider that virtually all of the developers in the sessions and workshops I teach tell me that their DBAs don’t expose the base tables so Visual Studio tools that depend on tables to generate code are counterproductive. A VS UI tool that treats stored procedures as an afterthought is not my idea of a best-practice tool.

Continue on Page 2

Replace Treeview Lists of Tables

The old-growth treeview control (invented decades ago) has long outgrown its usefulness. With VS moving to a new UI mechanism, it’s time to replace these treeview lists of tables with a mechanism that helps developers make intelligent choices from the list of table columns and provides instructions as to how the columns are to be handled during code generation. The catalog metadata could be used to indicate important primary key (PK) columns and feed options like RO, min, max, and mask. The code generator could then have a fighting chance to really help the developer incorporate tight validation rules right into the application.

Add a Prompt for a WHERE Clause

If you want to build a scalable application, you focus the initial SELECT query with a WHERE clause—preferably one driven by a set of parameters. As it is, developers have to take several additional steps to go back into the TableAdapter Configuration Wizard and enter a WHERE clause into the query to regenerate the Fill methods. Again, the metadata could be used to suggest filtering on the PK or on typical filtering columns such as state, postal code, or marital status. The wizard should always prompt for a WHERE clause and make it easy for the developer to set up parameters to further focus the query.

Recognize Read-Only Rights

Just because you can see a database table in the Tables list doesn't mean the DBA has given you rights to change specific columns. VS needs a mechanism to help its code generators recognize that specific columns are RO. Again, the metadata can provide a mechanism to manage these security and access rights.

Include Exception Handlers

While TableAdapters generate code for the Fill methods, they don’t include the necessary exception handlers. These are an integral part of any best-practice application. It’s important to show how to trap the Connection failures, constraint violations, and other issues quite common to data-centric applications—especially for new developers.

And While You're At It, Address These VS Needs

Shown below are other issues that my customers, MVPs, pundits, and the developers I interview have been requesting for some time. I have culled this list of those items that are out of the Visual Studio team’s control.

Fix existing technology. Microsoft needs more emphasis on fixing “won’t fix” or “by-design” bugs rather than inventing new technology that a small fraction of the developer community will ever use.   

Make the VS UI more developer-friendly. Give us code zoom (the ability to see more of the code and zoom in as needed to focus on a specific area, as in Microsoft Word), string-literal spell check, and a debug window that clears on each run or at least gives us the option of “tagging” a run with a message indicating date/time of the last execution.

Fix Help and make F1 work. Far too many Help topics aren't meaningful or are simply wrong. Make the Help search engine as good as Google. Purge the help topics on MSDN to eliminate white papers written about the beta versions or at least bring them up to date. Also, when developers select an operand in code and press F1, they expect to see a relevant Help topic and not be taken to Cleveland.

Implement drag-and-drop code conversion. Since most of the good examples we find with Google are in C# or Visual Basic .NET, get the IDE to automatically convert pasted code.

Help developers implement safe applications. One approach is to implement developer security personas. This means a built-in “run-as” mechanism to impersonate a specific user who’s been granted a limited set of rights. Add database object rights management to the Server Explorer.

Make coding easier. Incorporate the existing T-SQL code generator as a right-click “insert SQL” into the language code editor. Developers could then insert prototype SQL into the source without having to pound in the correct SQL. Add VS IntelliSense options for T-SQL and PL/SQL . Implement a refactoring tool that takes a block of SQL and creates a stored procedure.

Fix Server Explorer. Find a better way to organize the database objects Server Explorer manages. At least add the filtering mechanisms used in SQL Server Management Studio. This isn't important for Northwind, but for a production database with hundreds of tables, stored procedures and views, it’s essential.

Continue on Page 3

Add more intuitive support for stored procedures throughout the UI. Permit management of all results including multiple resultsets, errors, warnings, return values, and output parameters. Automatically code-generate the Parameters collection based on an existing stored procedure. (We had this in Visual Basic —VB—6.0 and VS 2003.)

Add the ability to insert SQL directly into a text string in the code editor. I’ve been asking for this for years. A developer could right-click in the code editor and choose “Insert SQL" and the Query Builder would open and help generate the SQL code. It would be nice if the Query Builder would provide an option to build a stored procedure on request.

Show options in IntelliSense that actually map to the class’ functionality. I would like to see a “smarter” IntelliSense that doesn't show such things as properties, options, and events for objects where the class doesn't support them. Case in point: SqlCe namespace doesn't support stored procedures, but it appears in the list of available options in the CommandType Intellisense.

Fix the project references pick list. This list hasn't been fixed since the first launch despite being mentioned as an issue many times due to the, shall we say, “challenged” design (the UI looks like a throwback to VB 2.0) and the fact that many component names are so long, you can’t tell one from another. This is UI 101 and the list should have been fixed long ago by adding a filter setting to help locate references as you do with the Toolbox customization dialog box (which is slow, but nicely done).

Don't Tell Us What We Need

This VS wish list isn't an exhaustive list, and while some of requested changes are tougher to implement, none of them are new. Developers have been asking for these features for over 15 years. I think it’s about time Microsoft refocuses on what developers ask for instead of on what Microsoft thinks they need.

William Vaughn ([email protected]) is an industry-recognized author, mentor, and subject-matter expert on Visual Studio, SQL Server, Reporting Services, and data access interfaces. He is also the author of the critically acclaimed “Hitchhiker’s Guide” series.