Here’s another interesting one: we had a .aspx page with some controls on it, and one of those controls were a CheckBox; upon a postback, we were trying to set the CheckBox as readonly. What we obtained is that ASP.NET incorrectly raised a CheckChange event even though none clicked on the CheckBox and so that event was not expected to fire; it seems as if the viewstate handler incorrectly detects a change to the checked value. First of all, Internet Explorer does not include the value of disabled controls in a postback to the server; secondly, an unchecked checkbox is not included in the post back either. So the way ASP.NET detects if a CheckBox has been unchecked, is assume that if checkbox is missing in the postback then it is unchecked, otherwise checked. It also turned out that the customer was overriding the RenderChildren method for his purposes, and in that method he disabled some of the controls sent to IE after the controls have any chance to store their new state in view state. Then keeping the browser’s behavior in mind, ASP.NET believes the CheckBox was unchecked, and fired the onCheckedChange event. In summary, upon a post back here, roughly…

Yesterday I got a call from a customer who needed some help configuring CAS settings for his application, and after finding the right one for his needs, he asked me how to easily configure all of their few thousands clients with the new settings. Well… a quick research brought up the following article: “HOW TO: Build and Deploy a .NET Security Policy Deployment Package“; but the customer wanted to deploy only the new code group we created for the application, and not his entire “Machine” policy… the CAS administration console allows you to create a .msi deployment package for the entire Enterprise, Machine or User, but unfortunately not for a single Code Group. The easiest way we found was to run the following command on the clients (through some automation mechanism the customer will identify depending on his needs):caspol -machine -addgroup All_Code -site localhost FullTrust -name “code group name“ The above command will create a new code group at machine level, as child of the group “All_Code”, will use the “Site” membership condition and will set it to “localhost” granting “FullTrust”, and the new code group will be assigned whatever name you’ll set as the “–name” argument (this must be enclosed…

Here is another problem I had a couple of days ago: the customer had a critical problem with on one of his .NET applications: he has migrated it to the .NET Framework 2.0, but it doesn’t work anymore under Windows 2000. They have isolated the problem and here is the source code to reproduce the problem: using System; using System.Text; using System.Net; namespace ConsoleApplication { class Program { static void Main(string[] args) { try { string url = "https://myprotectedsite.com"; WebClient client = new WebClient(); byte[] result = client.DownloadData(url); Console.WriteLine("result len=" + result.Length); } catch (Exception ex) { Console.WriteLine("EXCEPTION: " + ex); } Console.Write("Type enter to exit"); Console.ReadLine(); } } } The code above works properly on Windows XP and Windows 2003, and it displays “result len=582” (or wathever the lenght of the retrieved http stream is). It works also on Windows 2000 if you compile it with Visual Studio 2003 (i.e. .NET Framework 1.1); however if you compile it with Visual Studio 2005, it doesn’t work under Windows 2000. This is the exception we got: System.Net.WebException: The underlying connection was closed: Could not establish secure channel for SSL/TLSat System.Net.WebClient.DownloadDataInternal(Uri address, WebRequest request)at System.Net.WebClient.DownloadData(Uri address)at System.Net.WebClient.DownloadData(String address)at ConsoleApplication.Program.Main(String[] args) I first thought…

Last week I got an interesting question from a customer, apparently easy but something I really had never thought before… They have some ASP.NET 1.1 applications running in their environment, while the new apps they are currently developing, are based on ASP.NET 2.0: from one of those new pages they need to post some form values to an ASP.NET 1.1 page (both running on the same Win2003 server but in different application pools, to avoid the limitation of having just one CLR version per process); they use cross-page postback through the PostBackPage property for the submit button to target the 1.1 page, but this throws an InvalidCastException on LoadPageViewState() (which I guess is expected since 1.1 and 2.0 Viewstates are encoded differently). Question: is this scenario supported at all? How could this work? Well… it turns out that the ASP.NET 1.1 and 2.0 viewstate are encoded differently and are not compatible; moreover even if you set EnableViewState=”false” at page level this does not completely turns viewstate off, so every time you’ll execute the page you’ll get the InvalidCastException as before. Based on customer’s requirements, we identified the following possible solutions: POST from a classic ASP or HTML page: of course, since…