Codebureau - Matt Simner

  <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="" />

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

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

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...

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.

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 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.

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.

I'm currently without ReSharper (eek), so am trying to make the best of it.  Looking around for VS 2005 addins (that I haven't already got), I stumbled across a few resources....

Carl J has a list of Free Addins, and, wait - there's another list...

Not forgetting Hanselman's (old) list

I'm sure there's more, but I don't want to overcapitalise and slow my machine down more than Resharper did (maybe I should look at CodeRush?)

I'd only really tried Monaco (still the favourite) in Visual Studio, but found a good collection of programmer's fonts here.

Scanning through Hanselman's blog and found this.  Not near a dev machine at the moment, but It'll certainly come in useful...

There's a fairly major annoyance about VS2005 and the fact that when you create 'New Class' it effectively creates the class as private.  This article explains how to change it...

http://mark.michaelis.net/Blog/ChangingTheDefaultItemTemplatesInVisualStudio2005.aspx

ReSharper's got plenty of functionality (more of which I find and use as time goes on), but I found this on Joe White's blog that is certainly a useful reference and taught me a couple of new things too..

I spotted an old post from Brad Abrams on breaking changes for .NET 1.1 apps recompiled with 2.0.  The links had moved but are still relevant...

http://msdn2.microsoft.com/en-au/netframework/Aa570326.aspx

My own observations from converting projects are a little higher level in that I'm also interested in what effort you're liable for when converting, and also things to watch out for if (like me) you're having to persist a 'shared' code base of 1.1 and 2.0 core libraries (temporarily) while you migrate all your client apps.

ASP.NET Projects.  This includes Web Service projects.  You'll find that you'll probably have to reconstruct these projects based on the content files and you'll also need to make a decision on the model you're going to use for debugging - i.e. whether to use the new debugging host (removing IIS from the debugging equation) and whether to use a dynamic or static port.  Steer clear of the 'Web Site' project too as this could leave you confused for hours wondering why you can't debug anything - look for the ASP.NET projects.  More info on the ASP.NET side can be found from Peter Laudati's post.  Microsoft also have an article covering conversion of ASP.NET projects

DataSets.  These have changed in that a 'designer' file is now the main source file (apart from the .xsd).  If you're sharing DataSets across 1.1 and 2.0 projects just share the .xsd file otherwise you'll be asking for trouble as the other generated files are incompatible.  Any structural changes to a DataSet in one project (say .NET 1.1) will not be reflected in the corresponding 2.0 project.  You'll need to check out the XSD in both places (assuming you're using VSS) and build both in order to avoid breaking one of the projects.

Windows Forms.  I've had a recent experience where the InitializeComponent() method in a form (edited with VS 2005) places calls that aren't compatible with .NET 1.1.  The code compiles (as below) but 'exception thrown by target of an invocation' gets thrown on the following line...

((System.ComponentModel.ISupportInitialize)(this.validatingProgress)).BeginInit();

This is because the control (a PictureBox in this case) doesn't implement ISupportInitialize in .NET 1.1 but does in 2.0.  The equivalent in 1.1 is SuspendLayout()

This would just be one example of something that's syntactically correct, but could fail at runtime.

I've just had to apologise to my peers for breaking the build (thankfully not something that happens often).  I encountered an interesting situation where writeable files don't show as such (a build script had 'got latest' but left files writeable).  I then made some changes and performed an incomplete checkin as half of the changed items weren't checked out.  Visual Studio interestingly showed all of the files as 'locked' even though they were writeable.  VS2003 used to detect that and give you a different type of 'tick' to show the file was writeable but not checked out (I think ).

'Silly boy' - I hear you cry - yes I should have done a get latest before checking in (but didn't - my bad).  This does highlight however the Source Control settings available in the Tools-->Options dialog.  We enforce Checkin comments (through a VSS Addin) and so for safety (knowing what VS2005 is doing with VSS) it's always worth ensuring the following are enforced:

• Prompt before checkout
• Prompt before checkin (to allow comments)
• Don't allow editing of checked-in items
• Checked-in item behaviour
  • On Save - prompt for checkout
  • On Edit  - prompt for checkout

I'd changed some of these items in the past week but some had reverted to previous settings (a little concerning!!).

Anyway - it's all good - the build passed and I'm a little wiser about what options to tick in future.

Visual Studio 2003 doesn't give you any way of exporting your customised colours (I've gone for a 'black' theme) - well, black is the new black you know!

The theme's shown below (not that it's that great - but illustrates the effect the registry entries (further below) have...  In Visual Studio 2005 of course you can simply export your entire settings.  Oh yeah - also ignore the code as that's simply a work in progress for something I'm going to post on CodeProject in the next couple of months.

To create this look - simply copy the text below and save in a .reg file.  Take a backup of your current colours first of course by exporting the key: [HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\FontAndColors] to a file.  I've got some ReSharper v2 settings in there too so you can remove those if you don't use ReSharper (shame on you!)

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\FontAndColors]
"Color Palette"=hex:ff,ff,ff,00,ff,ff,ff,00,ff,ff,ff,00,ff,ff,ff,00,ff,ff,ff,\
  00,ff,ff,ff,00,ff,ff,ff,00,ff,ff,ff,00,ff,ff,ff,00,ff,ff,ff,00,ff,ff,ff,00,\
  ff,ff,ff,00,ff,ff,ff,00,ff,ff,ff,00,ff,ff,ff,00,ff,ff,ff,00

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\FontAndColors\{A27B4E24-A735-4D1D-B8E7-9716E1E3D8E0}]
"Colorable item format version"=dword:00000008
"FontName"="Monaco"
"FontPointSize"=dword:00000008
"FontCharSet"=dword:00000000
"Plain Text Foreground"=dword:00ffffff
"Plain Text Background"=dword:00000000
"Plain Text FontFlags"=dword:00000000
"Line Numbers Foreground"=dword:00c0c0c0
"Line Numbers Background"=dword:00000000
"Line Numbers FontFlags"=dword:80000000
"Collapsible Text Foreground"=dword:0000aaaa
"Collapsible Text Background"=dword:00000000
"Collapsible Text FontFlags"=dword:00000000
"Comment Foreground"=dword:002cef10
"Comment Background"=dword:02000000
"Comment FontFlags"=dword:00000000
"Current Statement Foreground"=dword:00000000
"Current Statement Background"=dword:0000ffff
"Current Statement FontFlags"=dword:00000000
"HTML Element Name Foreground"=dword:008080ff
"HTML Element Name Background"=dword:02000000
"HTML Element Name FontFlags"=dword:00000000
"HTML Operator Foreground"=dword:004080ff
"HTML Operator Background"=dword:02000000
"HTML Operator FontFlags"=dword:00000000
"HTML String Foreground"=dword:0000ff00
"HTML String Background"=dword:02000000
"HTML String FontFlags"=dword:00000000
"HTML Tag Delimiter Foreground"=dword:0000ffff
"HTML Tag Delimiter Background"=dword:02000000
"HTML Tag Delimiter FontFlags"=dword:00000000
"Identifier Foreground"=dword:00dfdfdf
"Identifier Background"=dword:02000000
"Identifier FontFlags"=dword:00000000
"Keyword Foreground"=dword:00538bff
"Keyword Background"=dword:02000000
"Keyword FontFlags"=dword:00000000
"Other Error Foreground"=dword:0000ff00
"Other Error Background"=dword:02000000
"Other Error FontFlags"=dword:00000000
"Preprocessor Keyword Foreground"=dword:00c0b4f3
"Preprocessor Keyword Background"=dword:02000000
"Preprocessor Keyword FontFlags"=dword:00000000
"ReSharper Completion Replacement Range Foreground"=dword:00e1e4ff
"ReSharper Completion Replacement Range Background"=dword:00000000
"ReSharper Completion Replacement Range FontFlags"=dword:00000000
"ReSharper Current Line Foreground"=dword:00ffffff
"ReSharper Current Line Background"=dword:00313131
"ReSharper Current Line FontFlags"=dword:00000000
"ReSharper Matched Brace Foreground"=dword:01000000
"ReSharper Matched Brace Background"=dword:00ffff00
"ReSharper Matched Brace FontFlags"=dword:00000000
"ReSharper Method Identifier Foreground"=dword:008b8b00
"ReSharper Method Identifier Background"=dword:01000001
"ReSharper Method Identifier FontFlags"=dword:00000000
"ReSharper Operator Identifier Foreground"=dword:008b8b00
"ReSharper Operator Identifier Background"=dword:01000001
"ReSharper Operator Identifier FontFlags"=dword:00000000
"ReSharper Read Usage Foreground"=dword:01000000
"ReSharper Read Usage Background"=dword:00face87
"ReSharper Read Usage FontFlags"=dword:00000000
"ReSharper Usage Foreground"=dword:01000000
"ReSharper Usage Background"=dword:00face87
"ReSharper Usage FontFlags"=dword:00000000
"ReSharper Write Usage Foreground"=dword:01000000
"ReSharper Write Usage Background"=dword:00c1b6ff
"ReSharper Write Usage FontFlags"=dword:00000000
"String Foreground"=dword:0034cb65
"String Background"=dword:02000000
"String FontFlags"=dword:00000000
"XML Doc Comment Foreground"=dword:002cef10
"XML Doc Comment Background"=dword:02000000
"XML Doc Comment FontFlags"=dword:00000000

This is a really simple one, but if you want to build a solution in a specific 'Configuration' and you have a big solution open, it can sometimes be an awfully long time to switch configurations - e.g. Debug -> Release.  You may find yourself needing to do this when you're needing to build and rebuild setup projects whilst testing.

You could of course run a command line compile, but a simple way to stay in the IDE and Debug configuration whilst running a Release build is the Batch Build facility. 

Just go to Build --> Batch Build, then select all the Release versions of the projects you want to build (or whatever you want to build), and then click Build.  The settings will be remembered for the next time you go in too...

I said it was simple. 

It finally happended today.  The thing that's plagued so many other people who've installed and uninstalled multiple Visual Studio addins.  My C# Class, Form (and probably every other) wizard gave up the ghost which meant no new projects or new classes because the wizards had got themselves in a twist. 

It happened at work today so I googled and luckily got sorted out within 5 minutes!  If you're in the same fix then look here as that very quickly did the trick for me!  I didn't need to go as far as reinstalling the scripting engine thank goodness.

You might need to alter paths a little as your extensibility.dll may be in a publicassemblies folder (like mine) rather than the IDE fiolder.  dir /s should sort you out anyway

Looks like they still haven't sorted out the ReSharper installer then!

This article runs through some amendments I've made to an already excellent VS Addin to 'visualise' datasets in the IDE.  There's definitely some improvements that can be made, but it shows how you can use the debugger to return useful information at runtime...

http://www.codeproject.com/csharp/dswatchex.asp