NDepend – Visual Studio Addin: takes you as far as you want to go

First of all I’d like to point out that I was kindly given a license by the folks at NDepend (not very often that sort of thing happens I can assure you!) and I’m under absolutely no obligation to write anything about it.

In the beginning…

The funny thing is that it was probably over a year ago when I first installed the product without any specific requirement or
expectation. I had a little play with it (on Visual Studio 2008 as I recall), then the work I ‘had’ to do overtook my will to learn this new product and it lay gathering dust on my hard drive.  This probably explains why I haven’t posted in all that time!

But then…

Recently, I picked up an existing project (on visual Studio 2010), and wanted to have a good look inside to see what I was getting myself into. I dusted off NDepend and told myself I’d give it a good go this time…

First Impressions

The first thing I learned is that this is one significant addin, and you realistically need to ‘know you need it’ before you get it (see ‘laying
dormant comment above’). This also means you need to know what it can do for you – which is plenty!

If you’re reading this and thinking of trialling NDepend, then you either have problems to solve or you’re wanting to invest in ongoing improvement to your code. Both are very good reasons as it happens.

NDepend has few limitations in what it can do, as it has your entire codebase, Visual Studio extensibility and its own powerful rules engine at its disposal. It also employs its own CQL (code query language), to allow you to find all sorts of patterns and complexity problems with your code.

The biggest problem is knowing where to start, or discovering that first task you want to achieve with it. It’s easy to get overwhelmed by the
information it bombards you with when you spin it up).

To be fair, there’s plenty of links trying to lead you to ‘what you’re looking at is…’

Reasons to try/buy

If you’re interested in the quality of your code I believe there really is no equal.  This is the tool you need. You may already be using FX Cop in your build process to check for certain snytactical rules, and ReSharper for sorting out your code as you go, but NDepend can do all sorts of ‘different’ funky stuff (through CQL) that goes in depth to your code to enforce things that would be otherwise difficult to do It can obviously do all the simple stuff like show you where your dependencies are between methods, classes and projects, and redundant code etc.

Some highlights I quite like – made possible through CQL:

  • Enforcing of layering constraints – i.e. ‘this UI project cannot directly reference ‘that’ ‘DAL’ project
  • Simple spot check stuff like queries on a ‘lines of code’ threshold – indicating complexity
  • Code not meeting an acceptable test coverage
  • For all the possibilities you’ll need to look here.

Things to be aware of

  • It’s a technical tool, and it’s easy to get a little overwhelmed with what it can do and where to start.
  • Time is needed to understand some of the concepts and power of the product.
  • You’ll need a beefy machine to avoid things slowing down with the addin loaded (I had to disable it for a while when I was using a solution with 60 projects as I was starting to experience memory issues).  If you don’t want to run it in Visual Studio, you can run it in the standalone ‘Visual NDepend’ application.
  • I’ll admit I haven’t spent a lot of time with the interactive reports, and I don’t find some of the graphical representations of the metrics that easy to use.
  • I think like most products, you get comfortable with what you see as valuable, and tend to only try other things when you have time.


Clearly NDepend’s a very impressive tool for any serious development team to be using. It will help you to learn about reducing complexity, dependencies and generally designing your code in an efficient way. It’s basically all about improving quality.

It’s also a big product that’s not for the faint hearted. You basically get out what you put in as far as effort in understanding what it’s trying to achieve for you.

I think the key is finding the right balance between all the technical information it presents, the time you have available, and the business benefit you’ll get from code improvements.

As I said at the start. It can basically take you as far as ‘you’ want to go.

Worth taking a look at: http://www.ndepend.com/

Deploying the minimum Oracle Instant Client files with ODP.NET

If you’re looking for the smallest and least hassle deployment of Oracle client files with a .NET application, then forget about everything else you’ve been told – the following did the trick for me, and involves just 5 Oracle dll’s.

Deploying ODP.NET with Oracle Instant client

One thing I found with this was that on my dev machine I already have (more than) one ‘standard’ Oracle installation and all the network config from that was really getting in the way meaning I couldn’t connect for one reason or another – OR I was connecting, but not using the correct client, meaning deployed files wouldn’t work on a ‘virgin’ machine.  All of this rather depends on how your company deploys Oracle server and clients I guess.

Rather than muck about with setting environment variables (that’s so 80’s) if you use a full connection string syntax as follows you can use your hostname and SID rather than try and fathom out service names. 

In your web.config

  <add name=”MyDB” connectionString=”Data Source=(DESCRIPTION = (ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = machinename)(PORT = 1521)))(CONNECT_DATA =(SID = mysid)));User Id=username;Password=password;” providerName=”” />

Any other variation of the (mucho confusing) Oracle connection syntax just didn’t work for me.

As an aside – I also kept getting System.OutOfMemoryException when building a web site project in Visual Studio 2008 when I was using the Oracle Basic client dll’s (110mb +).  I switched to the smaller Basic ‘Lite’ versions and it was happy again.  I guess a single file of over 100mb blows the lid off the IDE.

ASPNETCOMPILER The Target Directory could not be deleted. Please delete it manually or choose a different target – SubVersion

I’d added some projects to SubVersion today and later on added a CruiseControl.NET build.  I then started getting build failures due to the following:

ASPNETCOMPILER The Target Directory could not be deleted. Please delete it manually, or choose a different target

After a bit of looking around with the SysInternals Process Monitor I couldn’t find anything weird (e.g access denied due to someone locking the folder) and then saw that my output folder from the project (ASP.NET Web Deployment Project) was under SubVersion control (below)

Whoops! – after a swift delete of the folder (also in SubVersion) normality was resumed.  That’s another good reason not to put binaries into source control!

How to generate a list of Visual Studio Shortcuts

I’d seen addins that list Visual Studio shortcuts before, but seem to have lost them.  I also used to use ReSharper, so memorised its shortcuts.  I’m now back to ‘naked’ Visual Studio, so am having to re-learn the standard shortcuts.

I was surprised to find this article on MSDN that has code for a macro to produce a html page of all the shortcuts.  Just run the macro, open it up and search in the browser whenever you’re having problems remembering – unless you really want to print it (in which case I’d be inclined to bang a bit of CSS in there 🙂 ).  I might improve upon the whole situation if I find myself needing to refer to it more often, and will post updates here.

More reasons to love JQuery

I’ve only recently started using JQuery, but needless to say – it rocks!

for those that don’t know it’s a Javascript library that’s basically revolutionising how you write client-side code.  My reasons to love JQuery.

  1. It’s open source, well tested and an open design.  This means you write less code and you can rely on functionality just ‘working’ in different browsers – or gracefully failing if something’s not right.
  2. It’s really light (especially when ‘packed’ – 31kb)
  3. It’s got a strong community with lots of really cool plugins (just take a look before you start developing that ‘widget’ in flash)
  4. It plays well with other libraries and code.  you just use it for what you need and plugins sit with other plugins.
  5. It’s obviously gaining momentum, as Scott Hansleman announced Microsoft are going to ship it with ASP.NET MVC and Visual Studio (that’s a pretty amazing move from Microsoft).

If you’re just getting started with it, and you’re familiar with Javascript already I’d start with the tutorials.  Some are better than others, but run through the first couple to understand how it works, then scan down the list to find something related to what you need to do.  Typically you’ll be wanting to write a plugin, so I found this one quite good for starters.

You should find everything you need in the Documentation

you’ll then spend most of your time in the API section, looking for specifics on how to do things. 

Upgrading TortoiseSVN, Subversion 1.5 and AnkhSVN.

I thought I’d upgrade to v1.5 of TortoiseSVN this morning (leaving the server on V1.4.x) – of course completely forgetting that I use AnkhSVN in Visual Studio. 

New versions of TortoiseSVN and Subversion tend to upgrade the format for Working Copies.  This means AnkhSVN (1.02) was no longer compatible with my ‘new’ Working Copy and I got the following error…

This client is too old to work with Working copy ‘xxx’. Please get a newer Subversion client.

Thankfully AnkhSVN 2.0 is on the way and I downloaded a nightly build (2.0.4523.91) and installed (without uninstalling 1.0.2).  I usually do this to ‘test’ whether people write good installers.  Most people do the right thing with AutoUpgrade and 1.0.2 dutifully disappeared.

I loaded up Visual Studio with the same solution and – ‘Where’s my AnkhSVN menus gone?’.  As V2.0 is not even Alpha yet there’s not much in the way of obvious help on the Collabnet site.  The community area may have more, but I luckily didn’t need it.

I noticed in the application folder that there’s now an Ankh.Scc.dll.  Well blow me if they haven’t gone and made it a ‘standard’ Visual Studio SCC Provider!  Tools –> Options –> Source Control –> Plug-in Selection.  There it is.

Once you’ve got over that, then you might find a few little errors here and there, but the main difference is that instead of an ANKH menu on Tools and in the Solution Explorer context menu – you get a Subversion context menu. 

I’m liking it so far.  I think it’s probably stable enough to put your faith in and make the jump to SVN 1.5.

Update (08/07/2008) 
I submitted a bug report yesterday on an error I encountered (from the nice ‘send error details’ link) and got a reply saying ‘fixed in latest build’ the next day.  This bodes well!!!  Reasons to pay money for VisualSVN now disappearing fast…

Update (23/07/2008)

AnkhSVN v2.0 now officially out (that was a quick alpha/beta phase!)

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

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.

Visual Studio Documentation – Have your say

Brad A’s just been highlighting the MSDN Survey to get opinions on how Visual Studio and MSDN documentation works (or doesn’t) for people.  I added my 2c and it made me think a little about how I access ‘help’ these days.  Here’s what I wrote in the ‘other comments’ (Q 14 I think).

I generally access MSDN content through google (as it’s quicker than accessing the MSDN site, waiting for it to load the TOC, then searching).  It’s probably testament to the indexing of the site that a search such as “msdn Path.Combine” will take me straight to the specific page I ‘know’ I’m looking for.  I guess this means I’ve got some knowledge of how things are structured and I use that to good effect.  In a simple comparison…

Local Help
Typing Path.Combine into VS.NET code editor – selecting the text and hitting F1 came up with a false start (my current machine doesn’t even have the docs installed apart from Enterprise Library 3.1.  It did find some less than useful reference from EntLib!).  I went to Help options and chose ‘use online first’, and tried again (incidentally I didn’t even realise you could pull in your own list of sites to search (Codezone community) – cool).  It chose a different ‘Path property’ first and took about a minute in total to get to the right ‘Path class’.

MSDN Library Site
Opening up the MSDN site (which still feels too heavy in my book – and now curiously like BBC news) and searching for ‘Path.Combine’ took about the same time (1 min).  This includes opening the browser, loading up the MSDN home page, searching, clicking the first item in the search results, and loading that page.

Google search on MSDN
Opening up Google (admittedly my home page – but I’m looking for speed here) and searching for ‘msdn Path.Combine’ took 20 seconds.  The first item in the list was what I wanted so got straight to it.  It’s also worth noting that Google’s become a little fat puppy too with all my iGoogle stuff on it, but it’s still way quicker than any of the alternatives.


Getting the most out of ASP.NET Web Deployment Projects

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” />


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):


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.