Visual Studio’s and .NET’s Most Overlooked Want Items

by Jon Davis 24. October 2009 17:19

There are some features gone missing in Visual Studio and .NET whose absence frankly tick me off at times and make me go looking around for alternative IDEs and toolsets or plan on building my own tooling. I’ve done an initial evaluation of VS 2010 Beta 2 for each of these and confirmed that the issues remain. I am going to be appending this with occasional tweaks as time goes on, so feel free to post comments and I’ll add them to my “prayer list”. :)

Keep in mind, this is not a “most wanted” list, but a “most overlooked” list. That is, I think the demand is a lot greater than people seem to appreciate, perhaps because they’ve gone on all these years living with the way things are and being numb.

  1. Javascript brace matching (FB 340268) – Anyone who spends more than a few occasional hours writing Javascript within Visual Studio has no doubt been frustrated by the fact that, despite IntelliSense’s best (yet usually broken) effort to auto-indent on line breaks—a feature, by the way, I’m constantly fighting with when writing JSON and the bodies of closures—it completely fails when it comes to transitioning from C# and we’ve been spoiled with simple brace matching. The fact is, there is absolutely no brace matching in the Javascript editor.
    By “brace matching” I’m referring to the feature in C#’s editor where typing a “}” will highlight both the “{” and the “}” momentarily to help you keep track of your context so as to help you ensure all of your braces have been properly closed. Unlike typical C# code, Javascript code with all its deep-nested closures can get pretty hairy when it comes to nested brace blocks. Put the two problems together—a broken auto-indent feature and no brace matching, and the best you can do sometimes is fire up the WHOLE FREAKING APPLICATION being developed, navigate to the page or context you’re working on, and see if the browser’s Javascript parser pukes on entry.
    Seriously, Microsoft, where’s the Javascript love? Your half-hearted IntelliSense support for jQuery was nice (too bad there’s STILL no auto-completion in VS 2010 for summary documentation, nor IntelliSense while writing the XML documentation or references nor even color coding / syntax highlighting of XML documentation) but it’s not even meeting us at halfway to our needs for an IDE that identifies Javascript as one of the most critical programming languages for all web development.
    We want you, Microsoft, to treat Javascript as a first-class language, not as an afterthought, because Javascript is the web’s programming language as much as HTML is. If you have to abandon Active Scripting as your IntelliSense provider and rewrite from scratch using JScript.NET or or Jint or somesuch in order to give Javascript IntelliSense greater functionality, so be it, do what it takes, but this is clearly quite broken as it is.
    However, brace matching is hardly treating Javascript as a first class language. It’s a simple feature, and we need it.
    I haven’t yet checked to see if Aptana Studio—for which I do personally have a professional license I don’t use—does any better in this department, but I’m getting close to desperate and should follow up on that. Unfortunately, then the problem becomes integration with a .NET-oriented codebase. Time to switch away from .NET just for that? No, but the question does come up in my mind. Seriously.
  2. Configureless Entities – I’ll let my Gemli.Data subproject do the talking on this one. I’ve already done all my whining and complaining by way of starting to take some action so I’d rather not repeat myself yet again. I’ve seen the blog articles highlighting the new POCO support for LINQ-to-Entities 4.0 and it looks as verbose and awkward as Fluent NHibernate.
  3. Configureless Routing – I haven’t said much about this, but another sub-project I’ve added to Gemli’s road map is fixing the ASP.NET MVC routing engine by replacing it altogether with one that actually works. I understand where ASP.NET MVC’s URL Routing engine came from. It came from copying Ruby on Rails. And everyone loves Ruby on Rails, so it must be good, right? Ruby on Rails is one of the big sources for pushing the whole “Convention Over Configuration”, so if we just copy everything that makes RoR tick we’ll have our CoC right? Am I the only one who is puzzled by the nonsense of the realities of the routing engine NOT conforming to CoC? In order to have a URL get routed to a controller’s action and parameters, you HAVE TO open up global.asax.cs and drum up a mapping—yes, a MAPPING!—of that URL to your controller’s method. Visual Studio starts you off with a default one with a parameter mapping of “id” to get you started. I honestly don’t think I’ve ever used that mapping. There is regex-based wildcarding and pattern-matching support, which is I guess where Microsoft gets off saying, “see? it’s config-free!”, but you still have to declare your mappings.
    It gets worse; not only do you have to add your route mappings manually, for me, when I declare them, half the time they simply don’t work. Just yesterday I came across a declared route where MyMethod(string myParam) was explicitly routed as such, yet when it executed it ended up going to MyOtherMethod() by way of the “wonderful” wildcarding feature. I don’t recall how I fixed this, but there’s another broken piece in this routing mess: the order in which you declare your mappings matters a great deal, so you *must* move the wildcarded declarations down to the bottom of your declarations.
    We shouldn’t even be talking about manual mappings. MVC routing should automatically map to controllers, their actions, and their parameters, using reflection, in the same way as old-school web paradigms classically mapped the file system and file names directly to slash-delimited URL naming structure.
    The Gemli sub-project will, on the application’s initialization, scan for all classes that inherit controllers, assume that all their public methods are action names, and regex-pattern match all primitive types to parsable strings. Any parameter on a method that has a complex type or struct will be disqualified as an MVC action at least as far as this auto-mapping is concerned. Route customizations via C# attributes as well as other means will also be added. Honestly, this sort of routing engine is not very hard to write. I’ll get around to working on it within the next week or two or three, and expect to have it out there in working order in a week or two after I get started. (Keep in mind I only do this stuff on weekends and occasional evenings.)
  4. Deploy-as-Windows-App Web Deployment – Long, long ago, in a galaxy far, far away, there was a web server created called Cassini that allowed you to execute ASP.NET without running IIS. A few people adopted and even extended Cassini, but it was always Cassini. Cassini was then bundled in with Visual Studio itself for Visual Studio localhost debugging, but deployment of web applications continued to target IIS, and thus ends the story of Cassini.
    Remember ClickOnce? That technology that Firefox users hated until this week because Microsoft snuck its ClickOnce support add-in onto Firefox without users’ permission, until this week when Mozilla banned it from the browser? Yeah, .. that ClickOnce technology was actually a brilliant idea, but it didn’t work too well because users had too little control. But what about the inverse? ClickOnce allowed for installing desktop applications as Windows Forms and WPF applications straight from the web. But what about a technology that auto-packages a locally-running (for localhost-only access) web app that can be shrink-wrapped distributed, executed as an EXE, and accessible from the Start menu?
    It’s really quite silly that we can’t create web applications and deploy them as standalone EXEs that run in a web browser. I mean, we can. But we have to track down that old Cassini codebase or find one of the third party distributions of it such as UltiDev. Then you still have a bunch of moving parts that you have to manually figure out how to package and distribute your solution in a self-starting thing. IIS 7.5 supports standalone instances but that requires Windows 7 and feature activation .. and, well, IIS.
    Requiring IIS or even auto-rigging a standalone web server to run a simple web app seems like a configuration burden to me. The new WebPI paradigm is nice but it’s really more for web dev experts/admins and developers and for Internet web app discovery, and not useful for software vendors writing software for people who just want to use a simple application at home with or without Internet access and without any knowledge of web dev. Using ASP.NET as a Windows desktop app view engine would be huge, I think, because it would give software vendors a transition path from a preexisting Internet web site already built to a Windows desktop application. Not to mention a transition path for individual web developers who would like to know more about desktop solutions. 
    I don’t know, maybe the feature isn’t hotly requested because there isn’t much demand, but I think there’s little demand because there’s been too little innovation in this area on Microsoft’s side; the practice has been used for over a decade but it’s almost always people outside of Redmond doing it. Do I have an immediate need for this? Admittedly, no, I don’t; however, the more I think about it the more my mind wanders into creative ideas of what ASP.NET MVC could introduce to the desktop publishing crowd (the original desktop weblog engine, Userland Radio, from which blogging was invented, used a self-running web hosting engine to run), the PowerShell crowd (yeah hey look at this), social networking (did anyone else notice that Opera 10’s Unite is now proxying media and file sharing from the Opera Windows app itself using Internet-accessible, sharable URLs?), the reporting and finance crowds (remember Microsoft Money? it was built on DHTML), and more.

This is a small list. There was at least one other thing I wanted to mention in a blog like this but I forgot what it was. As I said, I’m going to grow my list over time as I continue to recall the things I always wanted but never bothered to mention.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


Add comment

(Will show your Gravatar icon)  

  Country flag

  • Comment
  • Preview


Powered by BlogEngine.NET
Theme by Mads Kristensen

About the author

Jon Davis (aka "stimpy77") has been a programmer, developer, and consultant for web and Windows software solutions professionally since 1997, with experience ranging from OS and hardware support to DHTML programming to IIS/ASP web apps to Java network programming to Visual Basic applications to C# desktop apps.
Software in all forms is also his sole hobby, whether playing PC games or tinkering with programming them. "I was playing Defender on the Commodore 64," he reminisces, "when I decided at the age of 12 or so that I want to be a computer programmer when I grow up."

Jon was previously employed as a senior .NET developer at a very well-known Internet services company whom you're more likely than not to have directly done business with. However, this blog and all of have no affiliation with, and are not representative of, his former employer in any way.

Contact Me 

Tag cloud


<<  May 2021  >>

View posts in large calendar