Month: April 2008

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

How do you ‘rate’ a developer or team lead?

Matt Simner Development Process, IT Musings, Miscellaneous , ,

Just going through some old notepads from previous employment and found a table that I’d come up with to ‘rate’ all the developers in the department (I was a team lead there at the time – I also rated myself and the other team leads).  The purpose was to effectively work out who to put where – i.e. what teams.  It’s pretty a simple process, and is essentially a straw poll on some high-level KPI’s, but assumes you’re experienced, and ‘pretty good’ yourself, and can recognise/score people objectively and consistently.  If you let personal preference get in there then your results mean nothing.


Each person is scored on 4 categories as some may be stronger in different areas.  Each score is on a scale of 1-10, and the scores are simply added to get the overall rating ( out of 40).  You can obviously make this a percentage etc if you wish.  You could also apply an average to scores given by multiple people.


Developer Categories:



  1. Ability. Raw development ability.  Can they achieve a technical solution?
  2. Discipline. Their ‘normal’ work practice.  Do they take pride in their work?  Do they lead others in the processes they follow?  how do they work when unsupervised?
  3. Commercial Focus / flexibility,  When faced with a deadline or changing scope do they cope?  Do they think creatively and work with others to keep things on track, potentially adding commercial compromise into their original design?
  4. Control. How do they work under pressure? Do corners get cut, do they fall to pieces, or do they rise to the occasion? 

Team Lead (Technical) Categories:



  1. People leadership. How do they treat their team members?  Do they instil confidence and inspire their team to achieve?  Does their team ‘like’ them? You have to be careful with the last one, because on its own it shouldn’t give a big score.  It’s the icing on the cake rather than the meat in the sandwich!.
  2. Getting Stuff Done.  Do they get results?  Does their team get results?  Do they deliver regardless of obstacles and issues?
  3. Upward Management. How well do they communicate changes, issues etc to managers and stakeholders?  Do they ‘sit’ on issues and hope they’ll go away until they ‘blow up’?

  Team leads can obviously be rated as developers too…


 

The best gmail Google Gadget

Matt Simner Miscellaneous, Web ,

When I say ‘best’ – I mean one that allows you to use gmail where you’d otherwise be blocked.  This does everything within the one window rather than opening up gmail (and alerting the company web police).  This requires a bit of real estate so you might want to create another iGoogle tab with one column.


I can probably uninstall Gmail lite from my home box now…


Here it is


 

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.