After installing the iPhone 1.01 software update, iPhone users may notice that what used to be an asynchronous request from the browser is now a syncrhonous request. They may notice other symptoms of an underlying problems as well. The update changes the way regular expressions are processed by the Safari browser and adversely affects a regular expression used by the Microsoft AJAX Library for JSON serialization. An updated regular expression preserves the functionality and works with the new Safari behavior. The regular expression is in a script file served from the System.Web.Extensions.dll on the server by default. Here are the set of steps you can take to have the scripts served from the file system instead with an updated version compatible with the iPhone change.
Download the Microsoft AJAX Library scripts from http://asp.net/ajax/downloads/library/default.aspx . Open the zip file and copy the contents of the System.Web.Extensions folder into a directory of your application, let's call it Scripts for now.
Change the ScriptReference instances of your AJAX pages to to include a ScriptPath attribute that refers to the directory where you have copied the scripts.
<asp:ScriptManager ScriptPath="~/Scripts] " />
Update the debug and release scripts. In MicrosoftAjax.debug.js, find this:
Sys.Serialization.JavaScriptSerializer._stringRegEx = new RegExp('["\b\f\n\r\t\\\\\x00-\x1F]', 'i');
and replace it with this:
Sys.Serialization.JavaScriptSerializer._stringRegEx = new RegExp('["\\b\\f\\n\\r\\t\\\\\\x00-\\x1F]', 'i');
In the release version of the script, you are updating the same RegExp, but it is a little trickier because the whitespace has been stripped from the file, so be particularly careful to leave the surrounding code untouched:
...ScriptSerializer");Sys.Serialization.JavaScriptSerializer._stringRegEx=new RegExp('["\\b\\f\\n\\r\\t\\\\\\x00-\\x1f]',"i");Sys.Serialization...
Known Issue:
The .zip file does not include localized copies of the scripts. If you enable Script Localization on the ScriptManager, it will generate requests for localized versions of the scripts and will now be looking for them on disk. The workaround is to rename the script files to MicrosoftAjax.en.js and MicrosoftAjax.debug.en.js and add ResourceUICultures="en" to the ScriptReference. You do not need to modify the path or name.
Jim Minatel from Wrox has arranged for an excerpt from the book to be made available online. It's a section titled Enabling Intenret Explorer for Debuggng ASP.NET authored by Dan Wahlin. You can check it out at:
http://www.wrox.com/WileyCDA/Section/id-305946.html
Update: Changes were made for the final release of Visual Studio 2008 so that the providerOptions requires are included for new web applications.
There are a couple of issues and complexities with using partial trust in 'Orcas' beta 2.
Below is an article from the team that explains the issues for developers and provides workarounds. The issues and workarounds described apply only to .NET Framework 3.5 Beta 2, and will be addressed in the final version of the product. The first explains what a developer must do to create partial trust applications in 'Orcas'. And the second explains what needs to be done on the server in order to host an ASP.NET application in partial trust that leverages LINQ.
ASP.NET Web applications or sites built with Visual Studio 2008 Beta 2 and .NET Framework 3.5 Beta 2 cannot be run in medium or partial trust
When you use Visual Studio 2008 Beta 2 to build a new ASP.NET Web application or website with .NET Framework 3.5, or migrate an existing ASP.NET application or website to .NET Framework 3.5, the resulting application will not run in medium trust or any other partial trust configuration. This issue affects all versions of Visual Studio 2008 Beta 2. A workaround is available below.
Description
To enable support for new compiler features in .NET Framework 3.5, Visual Studio 2008 Beta 2 inserts a new <system.codedom> section into the web.config file of every ASP.NET Web application. The configuration entry looks as follows:
<system.codedom>
<compilers>
<compiler language="c#;cs;csharp" extension=".cs"
compilerOptions="/warnaserror-" warningLevel="4"
type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<providerOption name="CompilerVersion" value="v3.5"/>
</compiler>
<compiler language="vb;vbs;visualbasic;vbscript" extension=".vb"
compilerOptions="/optioninfer+"
type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<providerOption name="CompilerVersion" value="v3.5"/>
</compiler>
</compilers>
</system.codedom>
This configuration entry contains a setting called compilerOptions that is not allowed under any partial trust configuration. When you run the application in medium trust or another partial trust setting, ASP.NET will raise an error noting that “the current trust level does not allow the use of the ‘compilerOptions’ attribute”. NOTE: Depending on the security settings of your server, this error message may or may not be visible to you.
Workaround
To avoid this problem, you can remove the compilerOptions setting, as well as the warningLevel setting, from this configuration section in your application’s web.config file after you have created or migrated your application. After making the change, your <system.codedom> section should appear as follows:
<system.codedom>
<compilers>
<compiler language="c#;cs;csharp" extension=".cs"
type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<providerOption name="CompilerVersion" value="v3.5"/>
</compiler>
<compiler language="vb;vbs;visualbasic;vbscript" extension=".vb"
type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<providerOption name="CompilerVersion" value="v3.5"/>
</compiler>
</compilers>
</system.codedom>
The workaround above also has the following impact on your ASP.NET Web applications:
1. For websites built with Visual Basic, the workaround prevents using the new LINQ capabilities of .NET Framework 3.5 on an ASP.NET page. To fix this, users can add the following line to the beginning of their Visual Basic codebehind file, and any other Visual Basic code files that use LINQ:
Option Infer On
Inline Visual Basic inside the .aspx or .ascx page (within a <script runat=”server”> tag) will not be able to use LINQ with this workaround. Users should move this code to a codebehind file. Other ASP.NET page features that use LINQ, such as the LinqDataSource control, will continue to work normally.
2. For websites built with C#, compiler warnings will no longer show up in the Visual Studio errors pane on compilation.
LINQ features in .NET Framework 3.5 Beta 2 cannot be used by default in medium or partial trust configurations
By default, the LINQ features in .NET Framework 3.5 Beta 2 cannot be used in medium trust or partial trust configurations. Enabling LINQ in these configurations requires a machine-level change to .NET Framework configuration.
Description
In medium trust or partial trust configurations, the code permissions granted to an ASP.NET website are determined by a Code Access Security (CAS) policy file on the Web server. When .NET Framework 3.5 is installed on a Web server, websites continue to use the same CAS policy file as .NET Framework 2.0.
The LINQ feature set in .NET Framework 3.5 requires the CAS policy file to grant a new permission, called RestrictedMemberAccess, which is not granted by default on ASP.NET 2.0. To enable LINQ to work in medium or partial trust, you need to modify the CAS policy file to grant this additional policy.
NOTE: Making this change will also grant this policy to ASP.NET 2.0 websites running on the same server. We have determined this to be an acceptable change for hosted sites that run under medium trust. This change will have no impact on existing ASP.NET 2.0 websites that can run under medium or partial trust.
Workaround
To enable LINQ for medium trust, please follow the steps below on the server:
1. Open a command prompt, and go to the directory that contains your ASP.NET 2.0 trust policy files. This can be found under the Windows directory, at
%windir%\Microsoft.NET\Framework\v2.0.50727\config
2. Determine which CAS policy file to modify. If you are using medium trust, this file will be web_mediumtrust.config.
3. Make a backup of the existing file.
4. Examine the <SecurityClasses> section of your CAS policy file. If the section does not contain an entry named ReflectionPermission, add a new entry as follows:
<SecurityClass Name="ReflectionPermission" Description="System.Security.Permissions.ReflectionPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
If you are using the default medium trust settings, you will need to add this entry. Depending upon your trust setting, your CAS policy file may already contain this entry.
5. Examine the <NamedPermissionSets> section of your CAS policy file. If the section does not contain an entry named ReflectionPermission, add a new entry as follows:
<IPermission
class="ReflectionPermission"
version="1"
Flags="RestrictedMemberAccess"
/>
If you are using the default medium trust settings, you will need to add this entry.
If you are using another trust configuration, and the section already contains an entry named ReflectionPermission, you can modify the Flags setting to add RestrictedMemberAccess permission. Flags should be separated by a comma. For example, if you are using the default high trust settings, you can modify this section as follows:
<IPermission
class="ReflectionPermission"
version="1"
Flags="ReflectionEmit, RestrictedMemberAccess"
/>
6. Save the file, and restart the Web server.
Well, I've been asked three times now why I haven't blogged about my book, so here it is. I worked with Dan Wahlin and Wrox to create a book about ASP.NET AJAX. The book covers the UpdatePanel, ScriptManager and other server controls, discusses how the Microsoft AJAX Library works and how you can more easily invoke web services, provide client-side event handlers, debug and deploy your AJAX application and write custom AJAX controls. Check it out at Amazon here.
The release on Windows Update that contains updates to enable the validator controls to work with the UpdatePanel has been delayed. However, you can download a HotFix that contains the changes.
http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=6106
I recently filmed an episode of the .NET Show with Brad Abrams (http://blogs.msdn.com/brada/) and Bertrand Le Roy (http://weblogs.asp.net/bleroy/). Brad asked for suggestions of words to work into the interview before we did it (http://blogs.msdn.com/brada/archive/2007/02/16/filming-ajax-on-the-net-show.aspx). I believe I won that challenge, but I can't be a participant and the judge as well.
Thanks to Robert Hess and the rest of those that have been working on the .NET Show. Here is a link to the episode http://msdn.microsoft.com/theshow/episode.aspx?xml=theshow/en/episode062/manifest.xml .
I got the chance to do a Podcast with Wally McClure. You can get to it
here.
ASP.NET AJAX provides new APIs for registering script with the ScriptManager. Using these APIs allows controls to work well with partial rendering. Without them, controls placed inside an UpdatePanel won't work as expected. In previous CTP releases of ASP.NET AJAX, we had a set of validator controls that derived from the v2.0 controls and used the new APIs. This made them work well with ASP.NET AJAX. WindowsUpdate will soon include a version of System.Web that can take advantage of the new APIs. So the new controls which would have been redundant have been removed. However, the update isn't available yet and ASP.NET AJAX has been released. So, in the short-term, the source code for a set of custom validator controls that work with partial rendering is available here.
The .zip file includes a solution and .csproj file as well as the compiled DLL. Just put the DLL in the /bin directory of your application and include the following <tagMapping section in the pages section of the web.config.
<tagMapping>
<add tagType="System.Web.UI.WebControls.CompareValidator" mappedTagType="Sample.Web.UI.Compatibility.CompareValidator, Validators, Version=1.0.0.0"/>
<add tagType="System.Web.UI.WebControls.CustomValidator" mappedTagType="Sample.Web.UI.Compatibility.CustomValidator, Validators, Version=1.0.0.0"/>
<add tagType="System.Web.UI.WebControls.RangeValidator" mappedTagType="Sample.Web.UI.Compatibility.RangeValidator, Validators, Version=1.0.0.0"/>
<add tagType="System.Web.UI.WebControls.RegularExpressionValidator" mappedTagType="Sample.Web.UI.Compatibility.RegularExpressionValidator, Validators, Version=1.0.0.0"/>
<add tagType="System.Web.UI.WebControls.RequiredFieldValidator" mappedTagType="Sample.Web.UI.Compatibility.RequiredFieldValidator, Validators, Version=1.0.0.0"/>
<add tagType="System.Web.UI.WebControls.ValidationSummary" mappedTagType="Sample.Web.UI.Compatibility.ValidationSummary, Validators, Version=1.0.0.0"/>
</tagMapping>
The ASP.NET AJAX Release Candidate is available here. A major change between beta2 and the RC is the switch from the Microsoft.Web.* namespace to the System.Web.* namespace. It's a straightforward update to exisiting code and should simplify things going forward into the next release of the .NET Framework. No other major changes are expected between now and the final release.
At this point, we are only taking high priority fixes and will release before too much longer. If you encounter problems, please let us know. And thanks to those who have provided feedback so far. It has helped us prioritize our work and while we haven't been able to include everything we would like for this release, I do think we have a solid release coming and am looking forward to adding more features in our next release.
At my TechEd whiteboard discussion, we talked about a couple of useful things for AJAX development. One is the WebDevHelper that a software architect, Nikhil Kothari, from the team provides. It is an add-in for Internet Explorer that will monitor the inbound and outbound traffic from the browser and log it for you. This can help greatly in seeing what is happening during asynchronous requests. His latest update and post about it are available here: http://www.nikhilk.net/WebDevHelperHTTPTracingUpdates.aspx
We also talked about the problem in AJAX development of the back button. The user can go along interacting with the application while state changes are happening asynchronously. The browser's understanding of the page navigation does not natively correspond to all of those asyncrhonous updates so when the user clicks the browser's Back button, they roll back in the history negating much more than what they anticipated of what they had done. And, they can't recover. Clicking forward again does not restore all of the asynchronous changes that occured after the page was navigated too. Nikhil has a prototype available for makring points in the browser's navigation history. Read more about it here: http://www.nikhilk.net/BackButtonSupport.aspx.
Here is one of the samples I was asked for at TechEd last week. How to access session state data from the browser. There are two C# methods in the page. One overrides the the OnLoad method and stores a value in session state for demonstration purposes. The other is a static method decorated with the WebMethod attribute that can be called from JavaScript. It retrieves the value for the given key from session state. Currently, only static methods are callable use the PageMethods object in the browser.
In the JavaScript code, there is a pageLoad method which will be called automatically by the ASP.NET AJAX script library. The PageMethods object is used to invoke the method on the server. It provides callbacks for success and error. The success callback just displays the value retrieved from session state on the server.
<%
@ Import Namespace="System.Web.Services" %>
<script runat="server" language="C#">
protected override void OnLoad(EventArgs e) {
HttpContext.Current.Session["foo"] = "bar";
}
[WebMethod]
public static string Session(string key) {
return (string)HttpContext.Current.Session[key];
}
</script>
<script type="text/javascript">
function pageLoad(sender, arg) {
PageMethods.Session("foo", OnCallComplete, OnCallError);
}
function OnCallComplete(result, userContext, methodName) {
alert(result);
}
function OnCallError(error, userContext, methodName) {
if(error !== null) {
alert(error.get_message());
}
}
</script>
<form runat="server">
<asp:scriptmanager runat="server" id="scriptmanager" />
</form>
As promised, the slides and code from my TechEd presentation are available here. I got some great feedback from people that have been using the ASP.NET AJAX beta as well as from those who have started looking at the Integrated Pipeline features of IIS7. I also have a few follow-up items to post:
1) details about a workaround for a problem with browser capabilities with some search engines.
2) some pointers to tools and samples
3) example code for a page method that accesses session data
Coming soon.
Well, just a few short weeks and some very late nights after the first beta was released, we have released beta 2 of ASP.NET AJAX. There are three different pieces you can download:
1) ASP.NET AJAX Extensions beta 2 is available here. This is the core part of the ASP.NET AJAX offering and required for the other parts to work. It includes the Microsoft AJAX Library which is the JavaScript libraries that can be used in the browser for more easily writing maintainable object-oriented JavaScript code that interacts with the DOM. The Microsoft AJAX Library can be downloaded separately as a zip file here.
2) The ASP.NET AJAX 2.0 Futures November CTP is available here. This naming is a little different than what we have used before. This is a set of functionality that builds on top of the core ASP.NET AJAX Extensions release. Some of the code has been around awhile and continues to evolve, while some of what we will include in the Futures CTP may shift more dramatically based on feedback and further scenario work.
3) The AJAX Control Toolkit is available here. It builds on top of the ASP.NET AJAX Extensions but does not requires the Futures CTP. This rich set of controls, behaviors and extenders are released with the source code. Developers-at-large contribute to the code and are the major driving force behind the release. A special thanks to the team for reacting to some late breaking changes.
Speaking of late breaking changes, there are a couple of things about beta 2 that you should know. Sorry that this post looks like a list of lists.
1) Scripts resource requests are now routed to a new handler. You need the following line in the <handlers> section of your web.config for things to work with beta 2.
<add verb="GET" path="ScriptResource.axd" type="Microsoft.Web.Handlers.ScriptResourceHandler" validate="false"/>
2) Script pages you include using the ScriptManager need a new line at the bottom to alert the client-side runtime that the script has loaded. This is to provide functionality in browsers that don't have the same eventing semantics.
As always, I welcome your feedback as you start using the release. We are feature complete now and the release date is driven entirely by dealing withing any lingering issues we have missed. Major feature work and further work on Futures CTP items will be slated for our next release
While I have been preparing for my TechEd Europe presentation next week, I have been asked several times for the blog address where I will post my slides. Starting a blog has been on my list of things to do for some time, so I guess this is the forcing function. I am a Development Manager on the UI Framework and Services team, responsible for ASP.NET and ASP.NET AJAX among other things. My intent here is to share info about the technologies I work on, and respond to common inquiries about developing applications. Developer feedback is key for guiding our product decisions, so don't hesitate to send me your thoughts.
A quick note of background about me: I joined the IIS web server team at Microsoft in 1997 working on what is now generally referred to as "classic" ASP. I worked on the IIS5 release, shipped the Mobile Controls for v1.0 of the .NET Framework, and then helped deliver .NET Framework versions 1.1 and 2.0. Now we are working on the ASP.NET AJAX Extensions as well as the next release of the .NET Framework code-named "Orcas."
