Fourteen and a half crazy frog burpers

12th July 2009

Nerd Dinner

Filed under: C#,MVC,Reviews — Tags: , , , — Alex Holt @ 12:30 pm

I was going to write a review on a great book I read over the last month or two called Professional ASP.NET MVC 1.0 which is published by Wrox and written collaboratively by Scott Hanselman, Scott Guthrie, Phil Haack and Rob Conery. Then I decided that one of the main things I really liked about the book was the first chapter “NerdDinner” which is a great tutorial on ASP.NET MVC 1.0.

I will first of all prefix this review with the very relevant disclaimer that I am (at this moment) a novice when it comes to MVC, which my background strongly in Classic ASP and PHP. I have a fair understanding and beginners comprehension of a lot of the core elements – but I’m still almost always looking up answers to very simple and run-of-the-mill problems.

The chapter is available online, free of charge, from ScottGu’s blog and the entire project has been added to version control at NerdDinner @ Codeplex (a useful tool when typing large amounts of text!).

The chapter covers a number of topics in addition to the core functionality of MVC, this includes things such as LINQ, Unit Testing, AJAX, Memberships & Roles and mapping software. Starting off with an empty Visual Studio, you can have a fully working NerdDinner website within an afternoons worth of work (or if you are me, a couple of nights worth).

I would highly recommend making some time to do this chapter if you are a ASP.NET developer. It will help show you the benefits and disadvantages of MVC. However, there are a few pitfalls as you are progressing through the chapter and I feel that the testing of the chapter could have been improved as there were errors and omissions scattered around as I was trying to complete it. There weren’t lots and errors were mostly ones which could be guessed and fixed without too much stress. Even in instances where you are unable to find the mistake, a look through the CodePlex site would give you a good indication as to what you were doing wrong.

I found the most frequent errors were that of ensuring the using statements were made, or a variable named differently on one page to the pages preceding. It takes me back to the good ol’ days of copying BASIC code from the back of computer magazines to make a spider walk across the screen and go up on a string from its web. Ahh, that’s classy stuff.

The book and the chapter do a great job of letting you know the key advantages and disadvantages of using MVC, outlining some of the core differences and changes to the ways in which applications are designed/developed. I particularly liked the way the application was grown and improved, simulating actual software development. Instead of the application being coded to the full application, it is initially built very basic and as the chapter goes on, layers of complexity are added bit by bit. This served for a greater understanding of how you might approach such development.

Overall, it’s one of my favourite and relevant tutorials and I highly advise finding the time to have a go at it. I’d also go so far as to say it’s very much worth spending the pennies and getting yourself a copy of the book too. It’s even sticks to the age old tradition of having funny pictures of developers on the cover and that alone is worth the dosh! :)

5th June 2009

Multiple Subversion Projects in one Visual Studio Solution using svn:externals

Filed under: Subversion,Visual Studio — Tags: , , , — Alex Holt @ 7:05 pm

Cake mix:

400g of Visual Studio 2008
100g of fresh Subversion
1tsp of VisualSVN (1tsp of AnkhSVN subsitutes if you can’t get hold of any).
Instructions: Put into a large bowl and beat the living-poop out of it with a spike covered hammer.

Or alternatively….

I’ve been quite frustrated that no matter where I looked on the web, what I searched for, which search engine I used – all the articles I found on opening multiple projects in Visual Studio (while still using Subversion), all seemed to explain only a portion of what was needed and never the full tale. So being frustrated, I decided it’s the exact type of thing I needed to note here – even if it’s just me that ever reads it!

The Scenario:

I have a Visual Studio solution with two projects in it: Project01 which is an MVC Web Application and the associated Project01.Tests project for testing. As I want to apply to DRY principles, I created another solution with a Class Library project (and associated test project) for putting any code that might be used again outside of the scope of the current project. This causes a couple of pickles:

  • Visual Studio doesn’t let you open more than one solution, so I’m forced to chose between Project01 and Libraries (which is hardly perfect).
  • Moving the Libraries projects within the Project01 Solution causes Subversion to get confused and causes a coupling of the code that would be difficult when Project02 came along.

I read that svn:externals was the way to go – but I didn’t understand how exactly to go about this. Sometimes the guides weren’t clear on how to apply the svn:externals but almost always, they weren’t specifically detailing how to get the setup I wanted within Visual Studio.

The Solution:

People were right! svn:externals is definitely the way forward, but there are a few things that need to be done to get the (seemingly) perfect setup.

A few notes before we start:

  • My example below includes Tests projects, these are of great value but not needed as far as this example goes (obviously).
  • The Screenshots are for AnkhSVN, but the scenario works with VisualSVN. Where the stage differs, I’ll endevour to explain the differences where appropriate.
  • This is my current setup and I haven’t run into any issues with it. However, by following this guide you are aware that I’m occasionally wrong and that gremlins may eat your data if you don’t ensure that everything is working as it should. ;)
  • My working setups are Visual Studio 2008, VisualSVN Server 1.7.2 (which includes Subversion 1.6.2),TortoiseSVN and VisualSVN or AnkhSVN. Tested on Windows 7 and Windows XP.
  • I’m going to suggest using the standard trunk, tags and branches layout within a repository – but you’d prefer not to it should be easy to customise.

The Steps

  1. You may already have this step done if you are working from an existing code base, but I started with two seperate solutions; Project01 (my application) and Libraries (my shared resource).
  2. Add both solutions to Subversion however you normally do it. For example, in AnkhSVN you right-click the solution and select “Add Solution To Subversion” and fill in the following pop-up box similar to below.�

    Add both solutions to your SVN repository however you want.

    Add both solutions to your SVN repository however you want.

  3. After adding each of the solutions, you should make sure that you “Commit” to update the server’s version of the files.
  4. Your repository should look something like the following:
  5. Ok, you can close Visual Studio 2008 (not sure if you need to, but I feel safer doing so).
  6. Open your repository browser. (e.g, right clicking on a file in Windows Explorer -> TortoiseSVN -> repo-browser.�

    Your repository should look something like this now.

    Your repository should look something like this now.

  7. Right click on the trunk of Project01 and click “Show Properties”.
  8. A list of properties (possibly including svn:ignore are shown. Click “New”
    SVN Properties
  9. Within the “New Properties” window, you want to add “svn:externals” to the top right drop down box (this may not already be in the list – don’t be detered). Within the main box, you want to put the name of the directory within your Project01 you want to create, followed by the URL to the repository with the code you want to fill it with : e.g:
    Don't forget to type "svn:externals" into the top right hand box.

    Don't forget to type "svn:externals" into the top right hand box.

  10. Reopen Visual Studio and your Project01 Solution.
  11. Right click the Solution name and “Update” to the latest version. You should see it add the External Library project in the text that flies past. This is basically the main part finished, but you’ll spot the two Libraries projects are not visible within our solution still…
  12. Right click again on the Solution name and add an “Existing Project”. Navigate to your Project01 directory and you should spot there are now 4 project directories with two of them being your Libraries projects! Simply go into them and add them one at a time.�

    Adding an existing project in Visual Studio

    Adding an existing project in Visual Studio

  13. Commit your changes and you’re done!

Testing Your Setup

You should be able to test your project by making changes etc to both sets of project files and committing them to your database. What should happen is your Project01 files will go to the Project01 directory in your repository and the Libraries files will still (dispite being in your Project01 solution on your development machine) be committed to the Libraries solution directory in your repository.

This setup should work for Project02 as well. Just repeat the appopriate steps and bang! – you have a fully working second project using the same Libraries!

If anyone runs into any dramatic side effects or knows of any issues with this methodology, I’d be very interested in hearing them as I’m currently on Cloud 9 with it!

4th April 2009

The Layout of a Subversion Repository

Filed under: Subversion,Visual Studio — Tags: , , , , — Alex Holt @ 1:07 pm

In and amongst other things recently, I’ve been working on sorting out a replacement for Microsoft SourceSafe / nothing at all. I’ve done my research and I believe Subversion an excellent starting place for using version control and will probably keep most, if not all developers happy. If distributed (and GIT) turns out to be too much of an advantage to ignore – the fact that Subversion is such a mature and well used product, there will always be an upgrade path.

I’ll try not to go into too much detail, as there are plenty of useful resources dotted around that you can find information from. However, before I go onto the directory layout of our repository, I feel I should mention the hardware and software layout of Subversion itself in our environment. Where I work, we are migrating from our historically used Classic ASP code to using C# in ASP.NET, though we have some systems using PHP too. I mention this because we want to be able to use Subversion to look after all code – not just one specific language.

Server Software: In my opinion, I believe you need both Subversion and Apache HTTP for an optimal setup. As we have an Active Directory server as well, it seemed like a good idea to use this rather than create further usernames and passwords for all our developers. For this, you can download and configure everything manually (after all, there is an excellent resource in the free eBook on Subversion) – but actually – you might as well just download the excellent VisualSVN Server. It takes almost all the hardwork out of creating the Subversion server. It’s truely a brilliant piece of kit and if you are new to Subversion, I’d advise using this (or at least having a nosey at it and seeing how it does things – if you’re that way inclined). It’s possibly worth me mentioning that all these applications have the most agreeable price-tag of absolutely nothing at all. Woo!

Client Software: For this, every developer wanting to use Subversion must install TortoiseSVN. TortoiseSVN is a great explorer based client for Subversion that allows developers to perform standard (and advanced) commands from the safety of the right click context menus. This works for all languages and files, but I’d advise for anyone working in Visual Studio, that downloading and paying $50 for VisualSVN is money well spent. It doesn’t require VisualSVN Server, but it gives you a way of utilising all the TortoiseSVN context menus from within Visual Studio, meaning you needn’t worry about mulitple windows and all that. Just concentrate on your coding! Also, because you have installed VisualSVN (or Apache seperately) you can allow (authenticated) users to view the repository in their web browser of choice.

All this and we’re almost up and running. But before we can continue, we need to sort out the structure. This is how I’ve suggested our team uses it:

svn / aspnet  / libraries  / trunk
                           / branches�
                           / tags
              / project01  / trunk
                           / branches
                           / tags
              / project02  / trunk
                           / branches
                           / tags
              / users      / amadiere
                           / user02

Basically speaking:

  • Every language has it’s own repository. There is no need to bring multiple languages into one repository, especially when the amount of code for each language is sufficient to live in its own. I think there may be exceptions to this rule, but those can be taken on a case by case basis.
  • Every language would have a ‘libraries’ directory (this is the equivalent to ‘include’ or whatever). Some things will obviously be used multiple times, so it makes sense to keep them in a central area, this is nothing new. With everything being in one repository however, it means moving something from Project01 to the libraries area will still keep all the history and version attached to it. This is a big plus from where I’m sitting and is why I’ve gone for this layout.
  • Each library or project folder would have the standard 3 directories for trunks, branches and tags. There is plenty of advise and advantages for this structure, most detailed in the SVN book. A project may involve further sub-project folders if it was relevant, before creating the trunk, branches, tags folder structure. However, depending on the nature of the project, it might be better to create multiple top level projects than sub projects with ‘different trunks’.
  • Each user would have their own area (without the 3 standard directory structure). There isn’t a need here for the trunks, branches and tags because this area shouldn’t be used for projects. This area should be used by developers to simply ‘Sandbox’ or test small bits of code etc. There isn’t an end product to need to branch. In the end, this code is the developers to work with – so I guess if they wanted the branches, then they can go for it.

I think with this format, we’ve got a good standing point for where we want to be going with Version Control and the ASP.NET environment. I’m confident, but until we really start using it in anger – we’ll never know! But the idea is then, when I want to develop something, I open Visual Studio and a blank solution. I then add the projects that I’ll need (e.g. Project01, Libraries and Amadiere) and off I go – I have everything open I need and they are all going to their appropriate places in Subversion! Genious!

Older Posts »

Theme designed & built for by Alex Holt. Powered by WordPress