Fourteen and a half crazy frog burpers

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!

24th October 2008

Visual Studio 2008 & SQL 2005

Filed under: Microsoft SQL,Visual Studio — Tags: , , — Alex Holt @ 3:22 pm

I’ve had a bit of a problem of late, namely: SQL Developer Edition 2005 and installing it.

When installing Visual Studio 2008, it installs SQLExpress 2005 which is a newer version that what I originally had on disk (though arguably not after updates). The SQLExpress however, didn’t come with all the client connectivity tools such as Management Studio (the replacement Enterprise Manager if anyone still knows it by that name), so I needed to get my version of SQL on my machine.

I decided the easiest way of installing would be to remove anything SQL’y in Add/Remove Programs and then to do the same for Visual Studio, as I have installed the combo on other machines when done VS2008 after SQL2005.

This went relatively successfully and I was able to install it… almost.

SQL Install says:
SQL Server Setup failed to obtain system account information for the ASPNET account. To proceed, reinstall the .NET framework, and then run SQL Server Setup again.

What? I have the most recent version of the .NET framework on my machine and its fully patched – how can the ASPNET account not be OK? I thought that maybe SQL (being a little older), needed an older version of the .NET framework. So I removed a few editions back to version 2.0 – still no luck. Googling was only finding limited useful answers, but I eventually stumbled upon what I needed:

Open up Command Prompt and go to
“C:\Windows\Microsoft.NET\Framework\v1.1.4322″ folder and run “aspnet_regiis -i” command.

This wasn’t perfect guidance for me, as the file didn’t exist in that specific directory, but hunting around the newer versions of the framework allowed me to find the file. Upon running that, a fairly unceremonius process runs and then when you retry your install process – Jobs a good ‘un!

Maybe I didn’t do this the best way, but I eventually have achieved what I wanted to and I feel all the better for it. And that’s no bad thing!

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