<Rant>

... Needs a lot of improvement.

Sometimes you click on the WebResource.axd names in Script Explorer and they refuse to open.

Othertimes it will not let you open one of them but then if you open one of the others then go back to the one you were trying to open it'll let you do it!

If you use IE "break at next statement" and break into a web resource it will come up with a File Open dialogue to open files of type WebResource.axd even though you can see it in Script Explorer.

When you click cancel because you have no file of that name it tells you source code is not available for the current statement instead of breaking into the web resource.

Are these issues likely to be fixed anytime soon?

</Rant>

<rant continues>

Ooh and I forgot to mention...

Often you'll put a break point in one Web Resource and suddenly you'll get transported into a totally different web resource and the break point ends up there!

Debuging script that runs as the page loads is very hit and miss as all break points are lost on page refresh. Putting a "debugger;" statement in initialise events sometimes works but only after dismissing a couple of "file open" dialogues and then manually using the "set next statement" on the right bit of code!

Obviously there is also the issue that you then have to delete these statements afterwards as well rather than just clearing break points.

Whilst the issue is clearly not the fault of the Atlas team it does make understanding the sample code much more time consuming and frustrating than it really ought to be.

</rant ends>

This is great feedback for the Visual Studio team - please pass it along to them!

As it relates to the Toolkit, you might have a look at the ScriptPath property as it lets you point a behavior's .JS file to somewhere more convenient. It's discussed in more detail here: http://atlas.asp.net/atlastoolkit/Walkthrough/OtherNeatStuff.aspx

Yes Martin - we hear you.  These are all well known issues and there are plans in the works to significantly improve the tools experience for script.

The issue with the Script Explorer is especially frustrating.  Usually if you can get it to open another file (e.g. the aspx page), then click the webresource, it'll work.

The issue of it losing breapoints when it reloads is a pain too.  I think the fact that all the files are named WebResource.axd is what confuses it.

There is also the issue of not being able to set a breakpoint on the first line of a function (you get the whole function).

As David mentions, using ScriptPath to debug your components helps alleviate all of this pain.  It also allows you to modify the script without having to rebuild the project.  I rarely debug against the AXD's anymore since it's so much easier to copy the JS file and use ScriptPath, then copy it back when I'm done.

Hi,

Can anyone help me to get the ScriptPath method working properly please?

I'd been having trying to get the debugger to break in to script in the embedded js file of my extender without success...so I decided to try an external js with the ScriptPath method.

I copied the js file to my web projects javascript folder and set the ScriptPath path appropriately. After doing this, hey presto, the debugger broke in at an error in the javascript.  Great, except when I fixed the bug, flushed the IE cache and tried again, the debugger showed the unchanged code.  A quick trace in  Fiddler confirms that the 'ScriptPath' file is being downloaded...but...so is the embedded js version immediately after it.  And it's the embedded js version that's being displayed in the debugger. 

I'm sure someone has this working well, so if you could drop a hint here that would be appreciated.  For the toolkit guys this would make a great tutorial topic "Step-by-step debugging ajax toolkit extenders" :)

 
Thks Brian

 

ok, answered my own question.  This is what now works for me:

Do move a copy of the js file from your Extender project to your web project's javascript folder

Do reference this js file using ScriptPath e.g.

 Do remove the text from the embedded js file that is still part of your extender project i.e. you are left with a blank js file.  This ensures that [assembly: System.Web.UI.WebResource(... and [ClientScriptResource(" references in the *Extender.cs files are not broken, while ensuring that the content of the embedded js file does not interfere with the copy you have moved to your web project.  (Note it would be better if the embedded version wasn't downloaded to the client when ScriptPath was in use - but I don't know how to make this happen...anybody?)

Don't reference the js file from the <Scripts> section of the <ScriptManager>

Once these steps are followed break points inside the ~/javascript/MyBehaviour.js file are honoured.

Hope this helps someone

Brian.

FWIW I've described how you can set up the ScriptManager ScriptPath and to serve the ASP.NET AJAX runtime JavaScript files (MicrosoftAjax.js etc) here: http://damianblog.com/2006/11/27/scriptmanager-scriptpath/

You need to rename the files and create a folder structure corresponding to the assembly attributes

This is an old forum post, but I found it with a search and also found what appears not only to be a better answer,but an explanation of why ScriptPath does not work well.

 http://www.jeffzon.net/Blog/post/The-awkward-design-of-the-ScriptPath-property.aspx

Deleted as duplicate

Thanks wrayx1 for the find!  I could never get the ScriptPath property to work for an extender.  Added the two methods in the jeffzon.net post and worked like a charm!