Clearing all bin and obj folders using SlightlyPosher and PowerShell

 

Sometimes an msbuild.exe /t:Clear doesn’t remove everything and it can be a little slow on larger solutions. Within the SlightlyPosher environment you’ll find a Module called VS.psm1, and this contains a handy little script when you need to do some house keeping.

function Clear-Assemblies($directory)
{
    Get-ChildItem $directory -include bin,obj -Recurse | foreach ($_) { 
        "Cleaning: " + $_.fullname
        remove-item $_.fullname -Force -Recurse 
    }
}

 

It’s pretty simply and to the point, just navigate to the root directory of the solution you want to clear down, and run this command.

Clear-Assemblies

It will recursively remove all bin and obj folders, and let you know what it deleted.

image

Great for when you need to copy source code without the added bulk of these folders or just purge any old bits for a clean build.

SlightlyPosher now supports 64bit PowerShell

 

When trying to write some scripts to automate IIS, I was getting some strange COM errors which were down to trying to run cmdlets targeted at a 64bit process.

It turns out Console2 as a 32bit process can only host a 32bit command prompt, which is unfortunate. Luckily Console2 does have a beta 64bit version, and I’m shipping this side by side with the 32bit version to satisfy everyone.

When you run update.bat you will find a new folder in your root.

image

Running [intptr]::size against the original shell yields:

image

And running it against the new shell:

image

I can now automate my 64bit IIS without errors. If everything is running fine you won’t need the new shell, but at least its there for the day you do need it.

WPF Toolkit ported to .Net 4.0 and VS 2010

Today I needed to make use of the WPF Toolkit from Codeplex in a .Net 4.0 WPF application.  Those who have used the WPF Toolkit will know that it was built for .Net 3.5 WPF, and a number of features within the toolkit got folded into the .Net 4.0 WPF framework (most notably a DataGrid control and the VisualStateManager).

Unfortunately the fact that these features got folded into WPF itself means that there a number of naming clashes between the toolkit and WPF 4.  This has been reported on the forums a few times and there is also a thread in which someone from MS China states “the WPF Toolkit will not be updated to 4.0 anytime soon”.

I really needed to use the charting controls from the toolkit and I didn’t want to deal with naming conflicts, so I forked the WPF Toolkit from Codeplex into a Bitbucket repo, upgraded it to .Net 4.0 and VS 2010 and removed all the bits which conflict with WPF 4.  The following have been removed:

  • VisualStateManager
  • DataGrid
  • Calendar
  • DatePicker

I have also dropped out the Visual Studio design-time support.  You can grab the code or the compiled assemblies from Bitbucket.

Enjoy!

July 21 2011

How to focus on the wrong thing when writing code

A recent discussion on our mailing list revolved around the use of regions, and whether stripping them out of a codebase was a useful first task when joining a new project!  The conclusion was, sensibly, that there were more likely bigger fish to fry (especially since region outlining can easily be disabled in your IDE) and so regions should be left alone.  Along the way, however, someone voiced an opinion that the software devs have a professional responsibility to adhere to existing standards.

Consistency in code is a great aid to readability – no doubt about it – but often someone needs to be the first to write a unit test, for example.  The benefit that comes about from automated testing massively outweighs any benefit from uniform code, by many orders of magnitude.  Similar arguments apply to use of IOC, good design of code, proper consideration of class / method / variable names, refactoring, SOLID principles and so on.  All of these things are simply more important than whether you group all your methods into a region named “Methods” or not.  And unfortunately, none of these items can be adequately codified into standards – it’s simply not possible.

Curiously, coding standards are so mechanical that they can actually be captured by software and fixes can be automatically applied.  These are the only coding standards that I personally ever bother to try and apply on a project.  I want development tools to be worrying about capitalisation, the presence or absence of underscores at the start of variable names, positioning of braces, and so on.  I do not want developers to concern themselves with such issues – the time and brain power of a good developer is simply too valuable to waste on such niceties.

Adherence to coding standards is just like tidying the decks of a ship.  It’s a good thing to do … just make sure that you aren’t on a Titanic that is slowly sinking into the deep!

Newer Posts Older Posts