…well maybe not for webcontrol users.

One of the most spoken-of features of Visual Studio 2008/Orcas is the new JavaScript Intellisense that helps the client-side developer. I’m very excited about this new feature, and put a lot of effort in documenting my JavaScript with code summaries so that I will get the full benefit when VS2008 ships.

I have been struggling to get this to work with some custom controls that emit JavaScript into the page. The JavaScript is fully documented and each file header references other assembly-embedded JavaScript files, just like the documentation tells me to do it. The problem was that I was getting no Intellisense at all for these scripts, unless I manually inserted them into the page. I also made sure that these commented JavaScript files (I also have compressed/stripped scripts embedded) of these scripts was actually registered during DesignMode.

I was reading a blog-post the other day stating that Intellisense is provided for scripts that are included in the page either as a ScriptReference with the ScriptManager, or as a normal HTML script tag in the page. My controls did just that during the PreRender events.  I emailed one of the bloggers about this, and guess what… this is not supported. If you drag a webcontrol onto the page that emits JavaScripts to the page, you are NOT getting Intellisense for those JavaScripts. So much for building a fully documented JavaScript API.

The reason is performance and security. For once they don’t want to execute user code on the client by rendering the control. But hey wait… isn’t that what is already happening in design time? The controls are rendered with specific design time layout, thus executing user code. OK VS is not doing it in the code editor but in the designer, but what's the difference from a security standpoint? Or could we at least get to allow certain assemblies we trust to do this? With regards to performance, I would think that either you want Jscript Intellisense or not, and if you want performance, you would just go and disable the Jscript Intellisense. They also seem to have nailed this one pretty well with JScript Intellisense being generated in the background while you're coding.

So the proposed workaround is to manually add a ScriptReference to each script using a ScriptManager. There are just two problems to that:

• You rarely know the full name of the embedded script, and using Reflector to find is often a violation to the EULA’s, and furthermore the name or scripts might change with each release/service pack. -not to mention that it's not very user friendly.
• Secondly, who says I even have a ScriptManager or want one on the page? Partial Postbacks have longer page life cycles and transmit a lot more data than callbacks, so I might just want to stick with the good old lightweight callback model, or I might not even need any AJAX functionality at all.

The funny thing is that the reply I got from Microsoft started out with saying that they get this question a lot, so there obviously is a demand for it.

I would have to wait 3+ more years for the next Visual Studio release, to harvest the benefit of all my code summaries... '-(

I actually found this other bug trying to get this thing above to work, and at least that is getting some attention. So before you start playing with JString Intellisense in beta2, don't put your classes inside namespaces.