William (Bill) Vaughn's Musings

My Visual Studio .NET Wish List:

The following bullets outline the features I would like to seem implemented in Visual Basic.

·         Better support for existing architectures, programming methodologies, data structures and applications. This means that more emphasis needs to be placed on fixing “won’t fix”, or “by-design” bugs and fixing the documentation for existing functionality before introducing new technology. I expect that many of the newly proposed features will be used by 0% of the developers when first launched. In contrast, improvements to the UI and the existing Visual Studio product will have immediate positive impact on everyone. Yes, after awhile, new features will gain ground as the doc catches up and third-party architects, analysts, authors and trainers figure out and show where these new features make sense.

Editor and UI

·         The Visual Basic editor needs a better way to deal with large code blocks. That is, the editor needs to be able to zoom (like Word or IE). Control wheel is the best way to deal with this.

·         The editor should have a built-in spell-check for all string literals. This way we can ensure that the words we put in front of the user are spelled correctly. This check might go so far as to correct grammar and (eventually) do so in the target language. The work is already done (in Microsoft Office)—it simply needs to be leveraged in Visual Studio.

·         The editor should make anything popped up translucent or moveable. That is, intellisense should not hide the code you’re trying to debug or write.

·         The debug window still needs a way to be cleared automatically on each run (or not) or at least timestamp headers should be added so we can tell which messages go with which execution.

·         When I click F1 after selecting an object, the UI should take me to the right help topic—at this point it works about 50% of the time. All too often it jumps out to a generic topic, a topic in an entirely irrelevant context or Cleveland.

·         When I drag code from one place to another, it would be nice if extra linefeeds were not added.

·         It would be great if I could copy in source code from a different language and have Visual Studio convert it to Visual Basic. Since most of the examples I find in Google are in C# when I’m working in Visual Basic .NET, (and vice versa), I would be great to be able to past to a “transmogrify” window what would convert the code to the host language. It would be even better if the UI could figure out what references need to be added and give me the option of adding Imports/Include statements.

·         Automatically add imports for unreferenced objects and suggest Add Reference DLL for objects.

General Features

·         Printing is vitally important. Where is the promised support? This needs to be in My and made to work. This includes enumerating printers, setting print properties, launching and canceling jobs.

·         Make it easier to implement secure applications. Visual Studio does not support developer personas. That is, developers often need medium-level rights to do their work—admin rights at some time and far more limited rights at other times. However, to test an application targeted at a specific user with limited rights, the developer must create a separate configuration (sometimes on a separate system) to test the application. I think Visual Studio needs the ability to let the developer execute the application “as” another user with specific rights.

·         Documentation still needs a lot of work. Working with many of the new classes like the ReportViewer control is painful. Too many of these help topics seem to be prototypes—just the basic property and what values it accepts. One of most common complaints is lack of useful documentation.

·         All resource finders including the Add Reference, Server Explorer (Tables, Stored Procedures) etc. need to have intelligent, filters to show only those items whose name meets the criteria. It might be a filter on name, date created, owner or other aspects.

Data Issues

·         Visual Studio and Visual Basic still does not support rights management for databases. It assumes that this is done by DBMS-specific applications (in SQL Server Management Studio for SQL Server and the equivalent tools in Oracle or JET). Managing rights is essential for data security. Relegating it to the vendor seems expedient, but there is no reason that the tools written for SQL Server could not be ported to Visual Studio. As I see it, vendors (including other Microsoft teams like SQL Server) need to be encouraged to add essential functionality into Visual Studio.

·         Visual Studio and Visual Basic does not support intellisense on T‑SQL. This language is more widely used in some companies than Visual Basic or C#. Since SQL Server Express and SQL Server Everywhere are gaining ground, it’s even more important to permit developers to create correctly coded T‑SQL queries—whether they are used in a stored procedure or imbedded in a prototype application. In addition, the T‑SQL editor in Visual Studio is not nearly as robust as that used in SQL Server Management Studio, but that product has dropped T‑SQL debugging. This means the T‑SQL must be developed in SQL Server Management Studio, but tested in Visual Studio.

·         For the same reasons, the query builder needs to be improved to incorporate T‑SQL intellisense as well as the ability to create more complex queries. As it is, the Query Builder fails to deal with multiple resultsets or more sophisticated queries. This tool also needs to be expanded to permit developers to build LINQ and other new-technology data access queries.

·         In the data area, ADO.NET must (simply must) have the ability to control how the query is executed. There is an entire class of legal T‑SQL operations that cannot be executed via sp_executesql. We need a pass-through property on the Connection or the Command that permits ADO.NET to simply execute the CommandText.

·         ADO.NET also needs to be patched to further prevent connection leaks. This can be as simple as adding CommandBehavior to the rest of the Command execute methods. We also need the ability to set the time a connection is held in the pool—while it looks like there is a ConnectionString key/value pair for this, it does not work as desired.

·         CLR executables for SQL Server need to have a more flexible built/deploy/debug model. Developers need to be able to test with or without first building or deploying. The reasons for this have to do with issues involving dependencies that don’t need to be torn down in all situations. We also need the ability to set/reset the “it’s okay to alter this assembly” switch in SQL Server to leverage this feature.

·         The Visual Studio create Data Source dialog should eliminate the “checkbox” on the Tables list (that adds all visible data tables to the TableAdapter). Don’t let developers choose “all tables”. This is just wrong.

·         The mechanism to alter a design-generated TableAdapter when the database schema changes needs to be simple and obvious.

·         As it is, the way Visual Studio propagates SQL Server Express .MDB files has gotten out of hand. There are scenarios that can create 6 or more copies (in various states) of a database simply by creating a database in a project, choosing the (wrong) option, creating a deployment config, deploying and using User Instance=True. This seems wrong and needs to be reexamined

·         One of the best ideas we suggested is template-based data generation. This approach would let us modify the base template used for code generation. This way we can build our own plumbing into the TableAdapter and other generated classes to implement business rules and constraints.

·         Stored procedures form today’s implementation of N-tiered designs. Visual Studio needs to make design, development, protection, execution and debugging stored procedures a priority. This approach should be a must-have for any new technology as well as a fundamental goal of any new Visual Studio version. That is, the new version should find ways to improve this common development paradigm. The 2005 version of Visual Studio handles stored procedures better than ever, but still discards critical syntax error information in the editor. It also does not permit developers to set runtime rights or manage object rights. Visual Studio also does not provide a clean mechanism to manage stored procedure versioning.

·         Developers write millions of lines of code to implement business constraints and logic. We still don’t have a standard way to implement business rules in the UI, middle-tier or on the database. The mechanisms to do this were added to SQL Server in the 2000 timeframe. The data teams promised to link to these properties (Extended Properties) but it never came to pass. We need a standard way to write a class that implements business rule constraints on a column-by-column and rowset basis. That is, tests that validate each column as well as those that validate the entire row before it’s passed to the server in an UPDATE or INSERT. These same constraints should be managed on the client and server with the same structures. I think if the generated code included a standard (user-definable) interface, we could reduce the code to deal with this issue.

I Want Your Feedback

If you have comments on these suggestions or have others you want to propose, post them here. Sure, the site asks you to validate your email address—I have to do that to prevent the spammers from sending everyone ads for other “enhancement” products. Be sure to describe your development shop in the response so we can better understand the issues you’re facing. Remember, I’m trying to act as your voice up on the other hill overlooking Redmond. Let me know what you’re wishing for—besides a higher Microsoft stock price.