Recently I’ve been attempting to streamline my workflow, to help me Get Things Done 🙂 So I thought I’d share some of that work, in a mini-series of blog posts:
- Visual Studio Workflow
- Automating Your Builds with Nant.Builder
- DIY AppHarbor – Deploying Your Builds onto Windows Azure
I won’t spend much time expounding on the tools that I use, as excellent guides are but a Google search away, but I’d recommend installing and using the following:
- Powershell – Yeah it’s a bit clunkier than bash, but it’s extremely powerful and lets you easily automate your day to day life
- Console2 – A nice way of working on the CommandLine and Powershell- read Hanselman’s excellent guide
- Git – As a looooong time SVN user and aficionado I was reluctant to move to Git, but now I have I have to confess I’m enjoying the experience
- PoshGit – Work with Git in Powershell, read Haack’s excelent guide to getting it set up here and here.
- Nant – My build tool of choice, I’ll talk about it a bit more in follow up posts.
- Nuget – Jump start your projects with this excellent package manager, and then upload some packages of your own 🙂
Configure your workspace
I’d encourage all dev teams to configure their workspace in the same way. That way you can jump onto a colleague’s machine and you’ll know where to go to find the code if pairing etc. Also it makes it easy to share buildscripts around the team. I set up my workspace as follows:
C:\dev \builds \releases \tools \work
So all work is done in the C:\dev dir. We then create 4 subdirs:
- builds – used solely by your build tool to copy files into for compilation, running unit tests etc
- releases – used by your build tool to copy your solution in a format that can be easily released, ideally any subfolders here would be dated or versioned
- tools – contains any tools you use to help with developing code, ie Nant, NUnit etc
- work – the main event, contains all your various solutions
So for example we might have:
C:\dev \builds \DemoApp1 \releases \DemoApp1-Build-120508-0915 \DemoApp1-Build-120508-1115 \DemoApp2-Build-120507-1506 \tools \Nant-0.91 \Nunit-2.6 \work \DemoApp1 \DemoApp2
Creating a new empty solution
A number of years ago I read the excellent Code Leader, the author advised using a tool called TreeSurgeon to set up a new solution. This tool is slightly long in the tooth now and could do with being updated, but you can follow the guide below to quickly define a new solution in the same style:
- Create a new blank solution in c:\dev\work and name it after your project – eg SampleSolution
- Your solution will open in Visual Studio and will contain only the solution file. Now you can add projects to your solution you might want to add a Web project a Services project and a Tests project.
- So right-click on the solution file and select Add | New Project
- As per .Net convention you should call the various projects <solutionname>.<projecttype>. So we’ll add SampleSolution.Web, SampleSolution.Tests, SampleSolution.Services.
- When you add the project ensure you set the location of the project to the /src folder within your solution
- Right-click on the solution file again and select Enable Nuget Package Restore. Click Yes when you get the pop-up about wanting Nuget to manage packages restores for you. A couple of nuget files will be added to the root of your solution.
We should now have a nice neat solution, with all projects saved in the src dir, eg:
Now to test if Nuget is working lets add a package to see if all is working as expected, lets add the awesome Twitter Bootstrap. So if we run the command in the Package Manager console
Twitter Bootstrap will be installed successfully, and if we now look at our Solution dir, you’ll see we now have a new packages dir, containing Bootstrap and its dependencies
Now that we’re happy you can add your solution to the source code management tool of your choice, I’d recommend checking out Git. BTW with nuget installed, you do NOT add the Packages directory to Source Control.
I’ll look at using Nant, to quickly build our solution.