ASP.Net Compilation Tool - do you want to allow updates without redeploying?

Originally posted on my old MSDN blog

We found an interesting issue today regarding our use of pre-compiled ASP.Net websites that I thought I would share, as we learnt something that we didn’t know before.

In our particular setup (for reasons too complicated to go into here), we have an ASP.Net website that:

1. We want to pre-compile before deploying to the live servers for the usual reasons of performance (no delay on first hit) and security (source code not hosted on the servers)
2. Before starting the web application, we automatically generate its web.config file
3. By default we want to disable view state in all the pages by adding a <pages enableViewState=”false” /> node in the generated web.config

Our issue was that even though the generated web.config file had the correct setting in it, the view state wasn’t being disabled. This had us confused for quite a while.

It turns out that the default setting when a website is compiled by the ASP.Net compiler doesn’t allow subsequent updates to the site.

In our particular case, this meant the compiled pages were using the (default) value in our non-existent web.config at compile time, not the one actually on the server at runtime.

Once we realised that, the solution was easy: simply add a –u parameter to the compiler flags which meant:

-u specifies that the Aspnet_compiler.exe should create a precompiled application that allows subsequent updates of contents such as .aspx pages.

If this option is omitted, the resulting application contains only compiled files and cannot be updated on the deployment server. You can update the application only by changing the source markup files and recompiling.

(Stolen from http://msdn.microsoft.com/en-us/library/ms229863(VS.80).aspx from where you can see all the available compiler parameters)

I guess a more common scenario is that you want to hot fix your web.config file – perhaps your database connection strings need changing immediately – but unless you’ve compiled with the –u flag, you’ll have to do a full build and redeployment.

Using a parameter in a SELECT TOP statement in SQL

Originally posted on my old MSDN blog

As usual, this may well be common knowledge but I found this useful.

In a stored procedure we were passing in a parameter (say @maxRows) which we wanted to use to dynamically limit the number of rows returned by the query.

For ages we couldn't find a way to do this without building up the SQL in a string using the parameter and then executing it e.g. something horrible like 'SELECT TOP ' + CAST(@MaxRows AS varchar(10)) + '...'

Now it turns out you are supposed to put the value used by the TOP in brackets anyway - see http://msdn2.microsoft.com/en-us/library/ms189463.aspx - so putting the parameter in brackets e.g. SELECT TOP (@MaxRows) ... is not only correct but gets around the horrible cast.

debugger command in JavaScript

Originally posted on my old MSDN blog

I don't do much client-side JavaScript programming, and I've always had intermittent issues when trying to attach a Visual Studio debugger to a instance of IE when I'm trying to figure out what's going on.

However in August 2007's MSDN Magazine (doesn't seem to be available online yet - page 52 in magazine) it talks briefly about the debugger JavaScript command, which forces the browser to bring up the elusive "debugger dialog". Very useful!

I'm not sure how well this is supported across different browsers, but for my non-expert use knowing about the debugger command certainly will make my life easier when I step into the crazy world of JavaScript.

Some more details at http://support.microsoft.com/kb/816173 

SQL Parameters and Types

Originally posted on my old MSDN blog

I found the following page interesting when having issues setting a value in a SqlParameter constructor.

From http://msdn2.microsoft.com/en-us/library/0881fz2y.aspx:

When you specify an Object in the value parameter, the SqlDbType is inferred from the Microsoft .NET Framework type of the Object.

Use caution when you use this overload of the SqlParameter constructor to specify integer parameter values. Because this overload takes a value of type Object, you must convert the integral value to an Object type when the value is zero, as the following C# example demonstrates

Parameter = new SqlParameter("@pname", Convert.ToInt32(0));

I guess it makes sense once it's explained, but it's not immediately clear when you just use 0 rather than Convert.ToInt32(0) why it doesn't work as expected

Performance Counters Fun

Originally posted on my old MSDN blog

Recently had some issues setting up some custom perf counters to install and run from an ASP.Net page that I thought I'd share.

We began by using the information in http://support.microsoft.com/kb/555129 which states:

"It turns out that the permission set required to update performance counters is much smaller than running as an Administrator or Power User.  In the registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib, set the Access Control List so that the necessary user has Full Control. In our original example, the ASPNET user would be granted Full Control, but access can be granted to anyone who needs to update a performance counter."

However I mistakenly assumed that as that setting those permissions would also enable the counters to be created, which is wrong. From the comments in http://objectsharp.com/cs/blogs/bruce/archive/2003/12/05/222.aspx we found out it's more complicated than that:

"For 2003 I did the following changes:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009 - Added permissions for Network Service
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services - Added permissions for Network Service
C:\WINNT\system32\perf*009.dat - Added full permissions for Network Service on all matching files.
After that it worked like a charm."

We didn't try the above solution, as after a little more thinking we gave up trying to install the counters on the fly and wrote some code that runs as part of the site installation (and hence runs as an Administrator which means it will definitely have permission to create the counters).

It's a lot cleaner doing it that way, and changes less permissions on the server which is always a good thing from a security point of view.

If you're interested. the code uses the System.Diagnostics.CounterCreationData class to create the counters on the web server if they're not already installed - see the documentation if required as it's pretty easy to use.