ASP.NET

Issues with data binding, Typed Datasets, DataRows and Null Values

Matt Simner .NET Framework, ASP.NET, C# , ,

Had some fun this morning as we’re trying to get a simple framework set up for a web app, that others can understand, using out-of-the-box functionality if possible.  I tried to avoid the normal tendency to put the ‘architecture hat‘ on and overcook it.  If you can’t be bothered to read all of this then just scroll to the bottom for the ‘take home’ on binding against typed datasets with null values.


We started off the prototype with a typed Dataset (including a couple of DB tables, and key relationships between each), a table adapter for each table, and a DetailsView at the front end, bound to an objectdatasource, which in turn talks to a business object that calls the TableAdapter.  That’s a lot for one sentence so from top to bottom…


DetailsView –> ObjectDataSource –> BusinessService –> TableAdapter –> Database


This all sounds pretty straightforward, and it is – unless (as in this case) you decide to have your business object pass back a single (strongly typed) DataRow for your front end to bind against.  This seemed reasonable at the time because I only ever want to show one row here.


You’ll basically get a StrongTypingException for every null field you try and bind, because by default a null field value will raise an exception when accessed through its generated property. 


We got distracted for a while exploring this as the natural tendency is to think ‘ah – I’ll make sure it doesn’t raise the exception’ – treating the symptom rather than the cause.


It turns out that any non-string field in a typed dataset table can’t have a default of null (or anything other than ‘raise exception’).  If you stuff in a _null value directly in the XSD your fields will disappear from the public properties (rather curiously) when you compile – so that’s not an ‘enterprise’ option.


I tried changing the return type in my business method to a generic DataRow to try and force the data binding to NOT use the strongly typed properties (getting warmer but still no dice.  I knew I was missing something really simple…


I then stumbled across a post (bottom of the page) that illustrated databinding will use different methods to bind based on what interfaces it finds.  The binding mechanism basically has no choice but to use the strongly typed public properties on a strongly typed or generic DataRow, as there’s no way for it to successfully enumerate the values.  If you bind against almost anything else you’ll most likely have no issues (it appears the databinding doesn’t rely solely on ITypedList).  We’re now binding against a typed DataTable (rather than generic DataView) and all’s fine.  If you want (rather) more info on ITypedList then look here.


So…


Don’t databind against a typed (or untyped) DataRow!

Invalid Postback or Callback Argument – ASP.NET. One cause

Matt Simner ASP.NET ,

Just been getting this error.  It’s quite common, especially if you’re using Ajax.  I got the error for an altogether more ‘schoolboy error’ reason.


I had a textbox control e.g. called ‘customerName’, and two radio buttons controlling whether to show the customer name.  These had a ‘GroupName’ of customerName, and this caused the error.  You need the GroupName to associate the radio buttons together, but the postback mechanism obviously sees that as the control identifier.  Silly boy. 


The naming was pretty bad in any case and actually prompted me to take more of a long hard look at the UI to tidy it up so no such conflict would arise.

ASP.NET – The name xxx does not exist in the current context

Matt Simner ASP.NET, Visual Studio

I recently converted a Web Site to a Web Application project, and as it had been a while I tripped up on a few things. 

First of all I made the mistake of creating a new Web Application and pasting all the web files in there (I was intending to split some of the site into another Class Library), and I wanted to port to another file structure.  I mistakenly thought it would be easier to do this ‘before’ changing to the WAP.

I then of course got a gazillion compiler errors (well – 1436 to be exact) on the new project.  The vast majority of which were ‘The name xxx does not exist in the current context’.  Yes it does! (I protested).  Well.  That showed mistake number 2.

If you want to convert then use the ‘Convert to Web Application’ option on the Web Site properties (or on the individual pages if necessary).  This does a number of things:

  1. Sorts out your project structure
  2. Changes ‘CodeFile’ to ‘CodeBehind’ and other directives
  3. Adds a designer file for pages and controls
  4. Other stuff that you shouldn’t bother yourself with etc…

The compiler errors were due to the fact that the WAP model expects pages to be structured in a certain way, and although the ‘code’ looks fine (and Resharper was green all the way) it won’t compile ‘cos the designer files are missing and hence so are the definitions the compiler’s looking for.

See Steven Smith’s post on some other tips for converting projects.

Developer Highway Code – Building secure software with .NET

Matt Simner .NET Framework, ASP.NET, Security , ,

Had some security training yesterday (don’t normally get training as a contractor so I was very happy to go along). 


The trainer mentioned the Developer Highway Code from Microsoft (seemingly originating from the UK based on the style of the publication).  Not only does it look cool, and have some rather amusing geek stuff (just see the ‘Reduce Coffee Now’ sign on the cover), it also has some really practical advice for people wanting to build secure applications.


Download it from Microsoft

When is XHTML not XHTML?

Matt Simner ASP.NET, Web, XML , ,

Well you may think it’s just a matter of rendering some well-formed markup and setting your doctype…


<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>


right?  Wrong!


Different browsers render in different ways.  What’s common however is that unless your response’s content type is “application/xhtml+xml” then you may not pass go and pick up $200.  You can force the browser to recognise the content type in two ways (in addition to the DOCTYPE declaration above):



  1. Name your file with an .xhtml extension (not really a solution as IE says ‘what?’)
  2. Set Response.ContentType = “application/xhtml+xml” (See here for more info)

The DOCTYPE is really an additional information item and not something modern browsers do much with on its own.  So how different are the browsers’  XHTML implementations?


Internet Explorer for instance takes the ‘all comers’ approach and will do the best it can given the markup, whilst degrading gracefully if it encounters errors.  great! I hear you say – saves me from actually testing this thing!


Firefox on the other hand will use a completely different parser once it knows you want to serve well-formed markup.  The good thing about this is that you immediately see any errors and the page won’t render if there’s invalid markup.  IE meanwhile continues to let you believe you’re an XHTML master (note: it doesn’t recognise the xhtml extension).



Firefox has some good resources about supported features.  A common one that catches people out is Javascript’s document.write.  This isn’t allowed in XHTML as the string input can’t be guaranteed to be valid XML. 


Safari’s not quite as advanced yet as Firefox’s support, but it too will properly validate your markup and report errors.


If you really want to stick your neck out then place a link on your site to validate against the W3C’s standards.  You’re likely to get plenty of errors – like this page!


Other things to watch out for are Content Management systems that allow you to enter non-compliant html in text editors, and simply not having JavaScript blocks in CDATA sections).


 

Getting the most out of ASP.NET Web Deployment Projects

Matt Simner ASP.NET, Setup and Deployment, Tools, Visual Studio , , , ,

In my ongoing love (but mostly) hate relationship with ASP.NET Web ‘Site’s’ I’ve been using Web Deployment projects to make things more bearable. 


I currently swap in connection strings from 3 files – one for each build configuration (debug, test, release – connectionstrings.debug.config etc ).  This works fine as per the doco on WDP.  I use CruiseControl.NET and NAnt to automate builds, and a few nagging ‘automated’ pieces were missing from the puzzle. 



  1. Encryption of connectionStrings (or other web.config sections that you want to protect) – without affecting the ‘source’ file.  I’ve assumed here that ‘internal’ people are trusted. 
  2. Changing of other config stuff (like debug=false) in the test and release builds.  (My attempts to get this to work had previously failed as you don’t seem to be able to specify system.web as a replaceable section.
  3. Encrypting Forms authentication passwords, using MD5 hash.  This isn’t difficult, I just didn’t have a tool to generate the hash value.

Encryption of config sections


OK – after re-reading Scott Gu’s post on Web Deployment Projects, and K. Scott Allen’s post on how to simply encrypt sections of config files, I realised that I could just add a post-build event (manually) in the wdproj file (right-click in solution explorer –> open project file). 


The build events are already in but commented at the bottom of the file.  I ended up with

<Target Name=”AfterBuild”>
<Exec WorkingDirectory=”$(OutputPath)” 
      Command=”C:\windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -pef connectionStrings .” />
<!– Also remove our ‘source’ config files using the del command rather than the delete task as you 
have to jump through hoops to specify wildcards –>
<Exec WorkingDirectory=”$(OutputPath)” Command=”del compilation*.config” />
<Exec WorkingDirectory=”$(OutputPath)” Command=”del connectionstrings*.config” />
</Target>

If I put this anywhere other than ‘AfterBuild’ it didn’t seem to do anything.  I certainly learnt a bit more about aspnet_regiis, as I’d only used it previously to ‘install’ ASP.NET.  I also had to specify the path to aspnet_regiis, but you could obviously use a property for this (I’m new to MSBuild – only dipping in when I have to, so the framework path may already be a standard property?).


Replacement of system.web sections


The key thing here (which I don’t believe was documented very well anywhere) is how to replace system.web elements.  Other typical replacements – e.g. appSettings or connectionStrings are children of the root config element.  You’d therefore assume that you need to replace the whole of system.web (which is a little inconvenient – but still worth it).  This doesn’t work and you’ll get a ‘nice’ WDP00002 error saying it can’t find the system.web element (a bit like saying ‘can’t find printer’ when it’s right next to the computer!). 


You just have to go one level down as follows (in the Deployment –> Web.config file section replacements property page):


system.web/compilation=compilation.release.config


compilation.release.config may be as simple as…

<compilation debug=”false”></compilation>

You might have a warning saying ‘compilation’ isn’t a valid element, but this is just the intellisense barking as it validates against the config schema.


Encrypting Forms Authentication Passwords


This is pretty simple and there’s lots of docs to support this, but I wanted a simple tool to generate the hash for a given string, and a quick google yielded a nice little command-line tool…


This way you can plug it into your build if you need to, but also replace for different environments using the techniques above.


ASP.NET Web Site Project (WSP) vs Web Application Project (WAP)

Matt Simner ASP.NET, Visual Studio , , , ,

ASP.NET 2.0 originally came without support for the ‘traditional’ Web Application project that everyone had become familiar with in ASP.NET 1/1.1.  Some people liked the new approach as it affords more ‘on-the-fly’ updates, but obviously enough people ‘didn’t’ for Microsoft to release a patch for Visual Studio .NET 2005 to allow creation of WAP’s.  The support was then formally re-added in VS 2005 SP1 (making the original patch redundant).


Info on the situation can be found here.


This post (as well as saving the links for me) is also a reminder of the limitations of the Web ‘Site’ model (hereafter known as WSP) and why I choose not to use it.



  • Namespaces.  WSP does not explicitly add a namespace to any page, class etc.  It uses ‘special folders’ with some implied names (e.g. App_Code) to determine the namespace hierarchy.  This whole situation can also lead to strange ‘circular reference’ errors with user controls – especially after converting from VS 2003.  At the very least you’ll be pulling your hair out wondering why you can’t reference some page or control from somewhere else in your site.
  • Code Reuse.  Only code in the App_Code folder (and below) can actually be referenced by another class in the project.  This forces a structure that you wouldn’t otherwise choose.  You can of course create separate assemblies – and should in many cases.
  • Unit Testing support in VS 2005.  WSP does not build to a single assembly when built in VS 2005, and must be ‘precompiled’ using a Web Deployment Project which in turn uses the asp_merge (publish) utility in order to achieve this.  The standard publish function doesn’t support a single assembly, although it’s possible to get the App_Code into a single DLL. This all means that because you don’t have an output at build time, you can’t run unit tests in the WSP – regardless of how much code you’re ‘reusing’ in the App_Code project.  You can jump through some hoops to call the NUnit Console runner, but why bother!?   
  • Included/Excluded files.  Because WSP doesn’t have the concept of a project file to say what’s ‘in’ and what’s ‘out’, VS 2005 uses a rather nasty ‘rename’ method of excluding files – simply suffixing the file with .exclude to denote it should be disregarded.
  • References are actually just copied in.  If you create a reference to an external assembly, VS 2005 will actually just copy the file into your bin folder.  This means you’ll end up putting all sorts of binaries in your source tree (under source control), that you maybe otherwise wouldn’t
  • Automated Build.  NAnt and other automated build tools can’t work out whether a Web Site project is some sort of ‘enterprise template’ project, or a tub of lard – because it’s not really a project.  This means that you can’t use the <solution> task with NAnt.  you have to call a custom <exec> task instead, calling the asp_merge.exe tool, then call all other projects separately too.  This all works, but again, why bother?  A cynic might conclude MS was trying to cause issues for NAnt, whilst getting people interested in MSBuild.

For me, any change that introduces new ‘non-standard’ tools, just so you can have the convenience of ‘on-the-fly’ updates just isn’t worth it.  You’ll actually find that this all goes out the window when you deploy to a server anyway, because depending on how you ran asp_merge, you probably won’t be able to do any ‘real’ updates because the assembly names are generated in that process and you’ll break the site by changing source files.  In my opinion if you are using this approach then use the Web Deployment project and build to a single assembly to minimse these issues.  If you’ve got any sort of structure around your production deployments (and you can’t just ‘copy over’) then I see literally no advantage in the WSP model, as it just seems to provide too much pain for no visible gain.

ASP.NET Open Source Content Management Systems – The Winner

Matt Simner ASP.NET, CMS , , , ,

Well, it’s been a little while since I first talked about Content Management Systems, but I can declare that


mojoPortal is the one for me.


There’s a number of reasons, but I’ll go through the main pro’s than means it wins out over DotNetNuke



  1. It’s XHtml compliant out of the box, and has minimal use of tables.  All the people producing skins for MojoPortal are also well evolved along the accessibility curve too.

  2. It uses standard .NET features.  This is due in no small part I’m sure to the fact that it started after DNN and more facilities were around in ASP.NET at the time.  This means that Skins, Themes, Master pages are all present and correct with MojoPortal, rather than the proprietary (but well documented) skins in DNN.

  3. It seems to be quick(er than DNN)

  4. The facilities are stable and work very nicely.  There are less modules, but the developer video tutorials are a really good way to get yourself into developing your own modules and edit pages.

  5. You can get involved and work with the code – after downloading from SVN (I fixed a small bug and felt really good about it!)

  6. Finally – and this is an easy clincher – the support for the product is just fantastic.  Joe Audette is like a man possessed on the forums, and you’re likely to get a really well thought out answer to any query within a few hours (depending on the time zone!).  He’s sorted me out on a few occasions and set me along the righteous path. 

In summary, mojoPortal is something I’m happy to be using for a client as I’m more keen to use standard .NET features than proprietary skinning.  I also like the philosophy more of the development community, and how Joe Audette’s running the project

VB.NET – I know I shouldn’t care but I just don’t like it!

Matt Simner .NET Framework, ASP.NET, C#, Visual Studio ,

Aaargh! I thought to myself for the umpteenth time as I looked through my inherited VB.NET web site (it’s bad enough that it was a web ‘site’ with dodgy auto-generated (i.e. NO) namespaces), but the following things are now officially going on my list of reasons I choose C# over VB.NET.  I know I shouldn’t care as it all compiles to the same thing, but (just from this project) –



  • VB.NET still allows you to dodge the Option Strict and Option Explicit (definitely a ‘Web Site’, as there’s no option in the property pages like for any other standard .NET project).  This means that you happily declare untyped variables, and do all sorts of dodgy late binding.  Some people obviously like this facility, but it’s one of the things that holds VB programmers back in the world of object-oriented design.
  • Modules still exist!  OK you could argue this is just a public class with everything marked as static, but it’s still ‘global’, and you don’t need to reference the module name when you access a method or variable.  This often leads to the ‘where the hell is that defined?’ question
  • Variants still exist.  This is obviously an extension of the first one, but it’s a big enough annoyance that people use to get themselves out of a (I don’t know how to implement this properly using object-oriented techniques) hole
  • Syntax ‘feel’ – e.g. Me vs this, and MyBase vs base – it feels a bit ‘Mickey Mouse’.
  • Verbose syntax causing RSI:

    • #Region “String Constant” vs #region whatever you like without having to put quotes around (C# regions can also be indented with the code unlike VB)
    • Global functions instead of operators like TryCast instead of ‘as’, CType instead of (Mytype)variable.  CStr, Cint etc still exist.  Not only is this more typing in many cases as you need to enter two or more parameters, it also feels like yet more ‘baggage’ from the bad old days, as you can still pass in your objects to generic ‘library’ functions rather than use methods on the object themselves (like ToString()).  Many VB programmers will lap this up because the language still allows them and they don’t have to learn something new.

  • Case insensitivity.  OK I’ll give you this one as it was one of the ‘speed’ things in VB6.  It does lead you back to the horrible pseudo-hungarian thing (for some people) though as you get naming conflicts with properties and variables if you follow the general pascal/camel C# standard (can’t remember whether there’s an option to switch that off though).  The alternative to the pseudo-hungarian notation is the _ prefix for class variables, but even that seems like too much of a concession.
  • Methods can still look like properties.  Call a method in VB without parameters and it will happily let you write MyMethod.  This just feels like inconsistency.
  • Tool support and productivity. 

    • VB.NET simply doesn’t have the same support in Visual Studio or refactoring addins (ReSharper’s only catching on to VB.NET now) This isn’t the language’s fault, but it’s easier to be more productive through tools with C#.  (I know this is improved with every release of VS).
    • The default VS 2005 refactoring capability (limited but present in some form) for C# is basically non-existent for VB.NET.  Maybe Microsoft think VB programmers don’t need refactoring support?
    • Intellisense is also generally rather lacking for VB.NET
    • XML Documentation comments (just now catching up, but was really lacking)

  • Angle brackets <> look uglier than square brackets [] for attributes (OK that’s a bit picky!)

The bottom line is that VB.NET lets you be sloppy, like VB always did.  The problem is that a fair percentage of those who migrate from VB to VB.NET (not all I agree – don’t shoot me!) take the same shortcuts that they always did – because they still can.  


My opinion is that on average you’ll find more elegant design, better formatted and more object-oriented code from C# programmers as they’re more likely to have come from a C++ or Java background.


Did I mention that I was a VB programmer for years, and have only dabbled a bit in Java and not really ever C++.  I loved VB6 (at the time) as I could get systems written quickly and well.  What I didn’t love was how much backwards-compatible support it kept leaving in with each new version, just so people could upgrade their crap legacy code.  I’ve seen some very clear, consistent, well formatted and commented VB.NET code, but I’ve seen an awful lot more that’s not.  The flip side is that C# coders often think they’re great just because they’re writing in C#.  I’ve seen plenty of horror stories there too, but the ‘bad’ percentage is much lower (sorry – it just is).


VB unfortunately doesn’t encourage discipline in programmers, whereas C# benefits from a clean slate without the historical baggage.  I believe the slightly more formal language specification of C#, and the fact it attracts more ‘OO’ coders, tends to lead people to think a little more about design rather than just skipping straight to implementation (which is where the ‘real’ problem is 🙂 ).  You can write the same crap code in any language you like.  VB unfortunately just makes it easier.

ASP.NET Extender Control for Expiring Content

Matt Simner ASP.NET, Web , , ,

I recently had a specific requirement to ‘expire’ some content on a web site.  There’s a million ways to do this, but my previous use of ExtenderControl in Windows Forms development sparked my interest when I noticed the Ajax toolkit supports this (mainly for client-side functionality). 


After downloading System.Web.Extensions, and about half an hour later I’d got the ‘ExpiringExtender’ Control that can be added to your ASP.NET (2.0+) page to allow content to phase in or out. 


The only down side to this approach is that your source code becomes littered with expired code like the Earth’s orbit does with old satellites!  This was therefore a quick solution to a specific problem – not an approach I’d advocate if this is a core requirement (you need a good Content Management System with built-in scheduling).


Anyway – here’s the class (chuck it into your App_Code folder if you’re using a Web Site project – as in my example).  The code’s pretty simple – just set a couple of properties (defaulting to min and max dates if not supplied) and the control’s visible property gets set appropriately.


using System;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;


namespace CodeBureau.WebControls
{


    /// <summary>
    /// This control works as a simple Extender to any server or html control to allow crude time-based 
    /// show-hide functionality.  NOTE This requires the Ajax Toolkit.
    /// </summary>
    [TargetControlType(typeof(Control))]
    public class ExpiringExtender : ExtenderControl
    {

        #region Private Attributes

        private DateTime showFrom = DateTime.MinValue;
        private DateTime showTo = DateTime.MaxValue;

        #endregion

        #region Public Attributes

        /// <summary>
        /// Gets or sets the show from date.  This indicates that the control should be visible from this date/time
        /// </summary>
        /// <value>The show from.</value>
        public DateTime ShowFrom
        {
            get { return this.showFrom; }
            set { this.showFrom = value; }
        }

        /// <summary>
        /// Gets or sets the show to date.  This indicates that the control should be visible to this date/time
        /// </summary>
        /// <value>The show to.</value>
        public DateTime ShowTo
        {
            get { return this.showTo; }
            set { this.showTo = value; }
        }

        #endregion

        #region Event Handlers

        /// <summary>
        /// Raises the <see cref=”E:PreRender”/> event.
        /// </summary>
        /// <param name=”e”>The <see cref=”System.EventArgs”/> instance containing the event data.</param>
        protected override void OnPreRender(EventArgs e)
        {
            base.OnPreRender(e);

            Control control = FindControl(this.Page, this.TargetControlID);
            if (control != null)
            {
                DateTime now = DateTime.Now;
                if (now < showFrom || now > showTo)
                {
                    control.Visible = false;
                }
            }

        }

        #endregion        

        /// <summary>
        /// Gets the script descriptors.
        /// </summary>
        /// <param name=”targetControl”>The target control.</param>
        /// <returns></returns>
        protected override System.Collections.Generic.IEnumerable<ScriptDescriptor> GetScriptDescriptors(Control targetControl)
        {
            return null;
        }

        /// <summary>
        /// Gets the script references.
        /// </summary>
        /// <returns></returns>
        protected override System.Collections.Generic.IEnumerable<ScriptReference> GetScriptReferences()
        {
            return null;
        }

        /// <summary>
        /// Finds the given control (recursively).
        /// </summary>
        /// <param name=”parent”>The parent.</param>
        /// <param name=”id”>The id.</param>
        /// <returns>the control if found (else null)</returns>
        private Control FindControl(Control parent, string id)
        {
            Control recurse;
            if (parent.ID == id)
            {
                return parent;
            }

            foreach (Control child in parent.Controls)
            {
                recurse = FindControl(child, id);
                if (recurse != null)
                {
                    return recurse;
                }
            }
            return null;
        }

    }

}



Colorized by: CarlosAg.CodeColorizer


And to use it in a page (I’ve got it within a master page here) you just add the registration for the extender control (note the Assembly=”App_Code” – I had to google for a while to find that.


You also have to add the ScriptManager control (an Ajax requirement), then just make sure the content you want to phase in or out has runat=”server” (it should work for HTML or Server controls).


<%@ Register Assembly=”App_Code” Namespace=”Coles.WebControls”  TagPrefix=”uc1″ %>


<asp:Content ID=”Content2″ ContentPlaceHolderID=”body” Runat=”Server”>
<asp:ScriptManager id=”ScriptManager1″ runat=”server”></asp:ScriptManager>
    <uc1:ExpiringExtender runat=”server” ID=”a” TargetControlID=”header” ShowTo=”13 March 2008 16:15:00″></uc1:ExpiringExtender>

<h1 id=”header” runat=”server”>Hey – I turn into a pumpkin at 4:15…</h1>


Colorized by: CarlosAg.CodeColorizer