** English

I have always had my beef with the client controls Atlas introduced. I am using JavaScript since approximately ten years now, so I know my way around DOM fairly well. So why add another layer in between? Of course there are scenarios where that makes sense, and there are developers who really appreciate a rather consistent API.
When upgrading to ASP.NET AJAX, client controls are gone at first. You need to install the CTP first. Then, some details change. First of all, the namespace moved from Sys.UI to Sys.Preview.UI. However in order to be able to access Sys.Preview.UI, an additional library must be loaded via the ScriptManager:

<asp:ScriptManager ID="ScriptManager1" runat="server">
  <Scripts>
    <asp:ScriptReference
      Name="Microsoft.Web.Resources.ScriptLibrary.PreviewScript.js"
      Assembly="Microsoft.Web.Preview" />
  </Scripts>
</asp:ScriptManager>

Apart from that, not very much changes. One notable exception: Sys.UI.Select is gone; it is now called Sys.Preview.UI.Selector. I wonder why, but it works

(Part of the Atlas to ASP.NET AJAX Migration series.)

Two weeks ago, the SANS Institute has released its annual Top 20 Internet Security Attack Targets list. Of course you can debate how such a Top list came together and what the real value behind that is, but there are two specific points in this year's list that I found quite interesting.
First of all, there is a new entry: Users (H2). This shows that phishing, social engineering and related attacks are getting more and more prevalent. User education is therefore more important than ever.
Second, PHP is specifically mentioned a couple of times (one wonders why). In entry C2 of the SANS Top 20 (Web Applications), the institute gives some very specific advice:

From the PHP system administration and hosting perspective:

• Always test and deploy patches and new versions of PHP as they are released
• Frequent web scanning is recommended in environments where a large number of PHP applications are in use
• Consider using the following PHP configuration:
  • register_globals (should be off, will break insecure apps)
  • allow_url_fopen (should be off, will break apps that rely on this feature, but protect against a very active exploit vector)
  • magic_quotes_gpc (should be off, will break older insecure apps)
  • open_basedir (should be enabled and correctly configured)
  • Consider using least privilege execution features like PHPsuexec or suPHP
  • Consider using Suhosin to control the execution environment of PHP scripts
• Use Intrusion Prevention/Detection Systems to block/alert on malicious HTTP requests. Consider using Apache's mod_security to block known PHP attacks
• As a last resort, consider banning applications which have a track record of active exploitation, and slow response times to fix known security issues.

From the developer perspective:

• If you use PHP, migrate your application to PHP 5.2 as a matter of urgency.
• To avoid the coding issues above:
  • Develop with the latest PHP release and a hardened configuration (see above)
  • Validate all input appropriately
  • Encode all output using htmlentities() or a similar mechanism to avoid XSS attacks
  • Migrate your data layer to PDO - do not use the old style mysql_*() functions as they are known faulty
  • Do not use user-supplied input with file functions to avoid remote file inclusion attacks

You could argue whether the PDO migration is superior to using, say, prepared statements (and why no other databases are mentioned). You could also argue why there is such an emphasis on PHP and that all advice is somehow well-known. But fact of the matter is, there are still so many PHP installations and PHP developers that do not follow these guidelines, as for instance Damien's survey shows. In my opinion, there is only one possible solution: Continue to talk with developers, continue to talk with hosting providers.

I just downloaded Office 2007 from MSDN, burnt it to a CD and then ran the installer. Then I burnt it again. Then I tried to mount the ISO and run the installer from there. The result was always the same: I got an error message stating that some files required for the installation were missing or corrupt.
A quick glance through the newsgroups told me that I was not alone. However I finally found a solution: I used 7-zip to extract the ISO's contents into a local folder on my system and ran the setup from there. I have no idea what the difference makes, but now it works. Other users reported that they were successful with the same approach but using WinRAR.

The most fundamental change when working with (local) web services with ASP.NET AJAX in contrast to Atlas is that the WebService attribute is not supported in this scenario. So when ASP.NET AJAX is trying to call the JavaScript proxy (by loading File.asmx/js), an exception occurrs.
In order to avoid this, the new ScriptService attribute is required. It must be used on the web service classand is defined within Microsoft.Web.Script.Services System.Web.Script.Services (Update: changed in RC1), so this will work:

<%@ WebService Language="C#" Class="Migration" %>
using System;
using System.Web;
using System.Web.Services;
using System.Web.Script.Services;

[ScriptService]
public class Migration : System.Web.Services.WebService
{

  [WebMethod]
  public boolean doesItWork() {
    return true;
  }
}


(Part of the Atlas to ASP.NET AJAX Migration series.)