Please Note: You must enable Script Debugging in Internet Explorer in order to follow what you are about to see here. Please do this!

Also.....Beta-1 warning here - things will change.

I find it very interesting to watch how our development environments have changed over the past few years; I remember a long, long time ago writing an entry about doing debugging of javascript in Visual Studio 2003. In any case, I really think I would like to walk everyone here through doing this in the new Visual Studio 9.

One of the coolest parts of Visual Studio 9 is the intellisense feature that you get with JavaScript. Therefore, let's do some intellisense and script debugging of ASP.NET AJAX client code through the new Visual Studio 9. To start, I create a new web solution in VS 9 and add a reference to System.Web.Extensions (for ASP.NET AJAX). I then want to add my ScriptManager control to the page, followed by a HTML button that I will execute some custom ASP.NET AJAX client script on a HTML textbox. The end result looks like this:

Next, I hook up an event handler in JavaScript with the button by double clicking it and getting presented with a method body:





In the spirit of ASP.NET AJAX being "asynchronous" I will then code into it a WebRequest class that will make an asynchronous call to any URL that is placed within the textbox. As you can see below, I have full intellisense making the use of the Sys.Net.WebRequest class a breeze:



I will then complete my use of the WebRequest class. I run into a bug, however - some null reference exception in my nicely formatted, intellisensified code. The code looks alright from the outside, it looks like this:




...but yet in the browser I get an error whenever I try to click the button, regardless of what I have in the textbox. So, let's set a debug break point on the text I'm about to pass into the set_url method and see what happens:




It says requestURI is null. So, I must have screwed up somewhere in my code?!? So, I look back on my code and realize I'm using the 'nodeValue' property instead of the 'value' property. A quick change of the code and I now get the following:




Slick, huh? Oh, and please note that even though I'm using "cnn.com" here, you won't be able to unless you are actually hosted on cnn.com. To prevent malicious scripting, you can only cause an asynchronous request to your own domain through ASP.NET AJAX.

I'm placing this here as a note to read this again someday (and hopefully to have others read it). What a great article - http://msdn.microsoft.com/msdnmag/issues/05/01/ASPNETPerformance/.

Very brief overview:

1. Reduce the time and number of round trips to the database by returning multiple resultsets.
2. Learn to optimize the paging feature of ASP.NET's GridView control.
3. Leveraging connection pooling (http://www.ondotnet.com/pub/a/dotnet/2004/02/09/connpool.html).
4. Understand and use the ASP.NET caching API (http://aspnet.4guysfromrolla.com/articles/022802-1.aspx).
5. Think about caching data frequently used during the lifetime of a single request.
6. Background processing. Here I'm dissapointed he didn't mention asynchronous pages in ASP.NET - but I know what he's getting at (http://msdn.microsoft.com/msdnmag/issues/05/10/WickedCode/).
7. Page-level output caching (http://aspnet.4guysfromrolla.com/articles/022802-1.aspx).
8. Run IIS 6.0 (7.0?). He really likes (and so do I) the concept of kernel-mode page output caching.
9. Use GZIP compression. Duh (http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/25d2170b-09c0-45fd-8da4-898cf9a7d568.mspx?mfr=true).
10. ViewState optimizations. Honestly - in my tasks, I turn off ViewState as much as possible.

OPC - the Open Packaging Conventions - is a recently approved standard for packaging data into a single, compact file. Many people, myself included, have had to create file structures in the past to maintain data in a single file; this creates a packaging standard for creating file structures in a discoverable fashion.

The coolest part about the whole thing is there is an API surrounding it in the .NET framework 3.0 - that is enough of a reason, alone, to be curious about it. It leverages ZIP as the compression format, uses a relational hierarchy for the contained parts and, like I said earlier, supports the concept of discoverability.

Check out this MSDN entry for more if you're curious about what this might provide for you: http://msdn.microsoft.com/msdnmag/issues/07/08/OPC/default.aspx.

MSDN Notes: Implementing the CLR Asynchronous Programming Model (Jeffrey Richter)

Source: http://msdn.microsoft.com/msdnmag/issues/07/03/ConcurrentAffairs/

1.       Introduction

a.       For applications that require interaction with IO, the answer is often to write into the solution more threads – this still incurs an overhead, however, in terms of the operating system resources needed to spawn and manage threads.

b.      The better solution, according to this article, is to use the CLR’s Asynchronous Programming Model (APM) in lieu of the a more heavily threaded application.

c.       There are four main reasons, according to this article, why you would write a class that implements the APM.

                                                               i.      You’re building a class that directly interacts with hardware,

                                                             ii.      You might be building an abstraction layer atop a class or code base that already talks to hardware,

                                                            iii.      You may have long-running methods in your class,

                                                           iv.      You might be wrapping non-asynchronous Win32 functions.

2.       The heart of the APM: IAsyncResult

a.       Any class implementing APM has a Begin/End method (ex: BeginRead/EndRead) pair of methods. The Begin version must create and return an Iasyncresult object that is the center of APM model.

                                                               i.      The object can be queried for the status of the asynchronous operation and is used to determine the result when the operation is completed.

b.      IAsyncResult has a property – a wait handle – that is actually ineffecient to use and so ought to be avoided if at all possible (many asynchronous operations will have a callback anyway, signalling the end to the operation).

 

 

 

I'm not sure if this has been done before, but it might prove to be another way cross-site scripting is dangerous.

Right now I'm trying to create a global index of all corporate blogs on my new site www.blogsbycompany.com. I'm waaay off the target now, but it's a pet project I'm playing with at the moment (don't bother going to it - yet). Regardless, I'm seeing that people put HTML into their RSS feeds; I'm noticing it all over the place (and it does make sense). My site aggregates company blogs (I have about 8 thousand blogs right now - but, I'm not advertising the site because it's way off of where I want it), but I'm noticing that sometimes I get encoded JavaScript in my blog descriptions (I'm making sure that people are properly encoding the script or else I encode it for them before displaying it in the results page on my search site).

What this tells me is that if someone out there is poorly doing a web bot or a RSS aggregator site, they could potentially open their viewers up to someone running script in the browser or on the cilent through RSS feeds. Most people simply expect the RSS content to be nicely formatted, but if they foolishly try to decode script, they could really cause some damage to their readers.

Most people who first start toying around with ASP.NET AJAX experience the coolness of using the UpdatePanel in their projects to cleanly update portions of their page. The end result is cool, the ease by which you can get at the result is cool and, well, everything about the experience is pretty cool.

However, the ease and coolness factor come at a price - effeciency and finely grained control. For, I would think, about 70% of your development needs this is okay – given that most of what you’ll be using AJAX for is simple region refreshes, etc. However, there are those situations where you might need a bit more from your AJAX framework, and if that’s the case, you should have a look at the WebRequest (Sys.Net.WebRequest) class.

Sys.Net.WebRequest is a client-side class (therefore written in ECMA script) that is the foundation for all asynchronous web requests that occur in ASP.NET AJAX (the UpdatePanel uses it, for example). The nice part is that it, itself, is a nicely consumable class that is easy to understand and quick to use.

Here’s is a quick run down on how to use the class.

First, you instantiate the class in your script code:

var wRequest =  new Sys.Net.WebRequest();

Then you set the URL which will be involved in the asynchronous web request.

wRequest.set_url(getPage);

Next, you set the very (GET or POST):

wRequest.set_httpVerb("GET");

Then you set the “user context”. This is a value of any kind that differentiates the response from one asynchronous request from another. The WebRequest class will attempt to complete the request asynchyronously and call a registered callback when it’s done – this contextual information will let you know to which request the callback is registered.

wRequest.set_userContext("user's context");

You then assign the compelted event handler:

wRequest.add_completed(OnWebRequestCompleted);

And fire off the request:

wRequest.invoke(); 

The first argument of your callback method “OnWebRequestCompleted” is a XmlHttpExecutor object that you can use to retrieve information about your request.

More information about WebRequest

More information about XmlHttpExecutor.

 

1. This is a solution to be noticed by developers of add-ins or languages leveraging Visual Studio,
2. It has two variants: the "integrated" and "isolated" modes. If you build tools or languages that run within Visual Studio standard editions, then "Integrated" mode is your mode. If you wish to create a solution that leverages the core features of Visual Studio but isn't branded as Visual Studio, then "isolated" is your mode.
3. In Isolated mode, end-users of our product are not required to have Visual Studio on their machines, with Integrated mode they are.

Therefore it's a framework for building applications that integrate into Visual Studio or use the core feel of Visual Studio as a foundation for an entirely new and unrelated product. Definitely something worth checking out if you have an interest or commitment in developer tools. Have a look here..

There seems to be a lot of confusion out there with regards to getting the ENTER key to submit a form. I'm here to tell you that the best solution I have found (and the one I use) is to drop whatever TextBox controls I'm using and the final Submit button into a panel control, and then set the DefaultButton property of the panel to the button to be clicked when ENTER is pressed. For example:

<asp:Panel ID="Panel1" runat="server" DefaultButton="Button_Search" Height="50px"
        Width="329px">

When focus is in a TextBox control inside the Panel and the ENTER key is struck, Button_Search will be "clicked" or invoked by the browser to post back the form data. The result is the feel of google's search engine where you simply type in the text box and hit ENTER to start the search.

A default button can also be supplied for the Form object itself, and this is set as a property on the form object too.

One thing to note is that the default behavior when a form is submitted through an ASP.NET button control is that the __EVENTTARGET or "source" of the form post is set to nothing. For example, by clicking a submit button manually, the Form variables posted look like this:

__LASTFOCUS=&__EVENTTARGET=&__EVENTARGUMENT=

However, by having the ENTER key cause the form post, the "cause" of the form post is manually set to actually be the button:

__LASTFOCUS=&__EVENTTARGET=Button_Search&__EVENTARGUMENT=undefined

This causes ASP.NET to have a fit if you do not have the following option set on the page (which can also be set through the web.config file):

<%@ Page EnableEventValidation="false"

The error you will see will be something like this:

Invalid postback or callback argument.  Event validation is enabled using <pages enableEventValidation="true"/> in configuration or <%@ Page EnableEventValidation="true" %> in a page.  For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them.  If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.

Care should be had when setting the EnableEventValidation to false as it is set to True for security reasons.