Web Control Validation in ASP.NET

So there's an issue in ASP.NET that prevents validation in some browsers. After snooping around it apears that the BaseValidator class in ASP.NET 2.0 Beta 2 has resolved the issue.

The cooler part is how the scripts are downloaded to the client. There is a new handler defined in the machine Web.config (which is confusing enough since originally it was just machine.config) for the file WebResource.axd(like Trace.axd) that is handled by the AssemblyResourceLoader class. Apparently it is passed an encrypted string (via Page.EncryptString which is an internal method) containing the assembly and resource name, and it hands back the requested resource to the response stream.



First Glance at Codename "Monad"

Since it wasn't going to ship with "Longhorn" I assumed it would be a while before I got my hands on it but then I saw a link to the beta.

It seems that Codename "Monad" is now the Miscrosoft Shell. I downloaded beta 1 last night and my first impression wasn't that great. After getting bored I read the documentation and got extremely excited. There are a massive list of features that a single blog post just couldn't sum up, but I'll try.

So the whole thing works off of cmdlets (pronounced commandlets according to the docs). cmdlets are the built in functions of a shell. Each cmdlet consists of a verb-noun pair. So the cmdlet get-process gets a list of processes. The cool part of all this is that each of these cmdlets are actually .NET code where .NET Attributes specify the verb and noun.

The shell supports branching statements via if and switch and looping constructs with foreach and while. It also supports the ability to trap specific errors. It's not exactly try-catch but it will let you trap a specific .NET exception type.

The shell also support direct access to the .NET Framework. You can call any static method via [TypeName]::MethodName(parameters). There is also a cmdlet called new-object that will call the constructor for a given type.

Variables can be declared at various scopes and they can be typed. Combine that with new-object and you can start using scripts instead of really simple console apps. Variables can also be set up as arrays or hashtables which reminds me a little of perl. The variables also expose any fields, properties, or methods of the objects.

Although you can't include your own assemblies in msh, you can use the make-shell utility to create your own shell based on the assemblies and cmdlets you require. When I first saw that a flood of "Software Factory" buzzwords went flying through my head. I also remember hearing something about the Exchange Server team using this product to develop their automation utilities.

msh has all that would be expected from any Unix-style shell, but with direct access to the .NET Framework and a massive extensibility system. I keep thinking of all the random stuff that can be done with this and it hurts my head. Just imagine if your NUnit tests were msh scripts instead. What if your custom application shipped with a custom shell for your customers to write their own automation scripts?



I guess I had to start some time

So I've started blogging. I don't really know what I'm going to blog about but I assume there will be a few posts about .NET and other geeky software developer stuff.

This page is powered by Blogger. Isn't yours?