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…

This week I’ve been working on a problem which at the beginning seemed to be just a matter of configuration but that then took some more time that I expected to resolve… so, here it is. In my ASP.NET 2.0 application I edit my web.config to set slidingExpiration=”true” and cookieless=”true” in Forms authentication. Basically what happens is that after half of the timeout set in <forms> element is elapsed, the user is redirected to the login page; e.g. I set <forms timeout=”3″ cookieless=”UseUri” enableCrossAppRedirects=”true” /> (timeout 3 minutes), if I postback the page after 1 minute and 35 seconds, I’m redirected to the login page (but the Forms authentication ticked should still be valid…). This can’t be a cookie problem because we are not using cookies… First, a quick review of sliding expiration: “When the SlidingExpiration is set to true, the time interval during which the authentication cookie is valid is reset to the expiration Timeout property value. This happens if the user browses after half of the timeout has expired. For example, if you set an expiration of 20 minutes by using sliding expiration, a user can visit the site at 2:00 PM and receive a cookie that is set to expire…

If you have an IIS 6 with multiple application pools running, and you need to know which w3wp.exe process is actually hosting your application (suppose you have to capture a dump and don’t want to use the “-iis” switch with adplus, which will produce one dump file for every w3wp.exe, dllhost.exe and for inetinfo.exe), then follow these steps to find out: Using the IIS Manager, note down the Name of the App pool for your application In the command prompt, go to <WindowsFolder>System32 Type the following command: iisapp.vbs /a <AppPoolName> (Use double quotes around the name if it has a space) The result will contain the Process ID for your application pool The greatest mistake you can make is to be continually fearing you will make one. – Elbert Hubbard 

  Here is an interesting problem I worked on a couple of weeks ago for a customer who raised a call with Technical Support: they had an ASP.NET 2.0 application written with Visual Studio 2005, and while working on it they found that when changing a code file contained in App_Code folder and then building the site from the Visual Studio menu command, this took up to 7 minutes to complete… and if they then run a page pressing SHIFT+F5 it took about 25 seconds to compile and display the page. If they just modified the HTML layout of the pages everything worked fine; moreover, it’s interesting to note that if they simply modified and saves their files without building the solution in Visual Studio, but just browsed the page (thus relying on ASP.NET to compile on the fly their code) again everything worked as expected. This seems quite clearly a problem with Visual Studio. It turned out that this project was originally build with Visual Studio 2003 and ASP.NET 1.1, and they decided to upgrade it to ASP.NET 2.0; they used the upgrade wizard provided by Visual Studio 2005, which will turn on batch compilation (<compilation batch=”true” /> in web.config) when it…