Showing posts with label visual-studio. Show all posts
Showing posts with label visual-studio. Show all posts

Wednesday, January 5, 2011

Opening the Fisheye page for your current file from your IDE

Our revision control system is SVN, with a Fisheye server providing easy browsing of the repository. I use Fisheye very much and was tired of having to dig through the deep hierarchies of our project to display the information about a file. I therefore wrote a very little script that I can launch from Visual Studio to open the Fisheye page for the current file, with the correct branch/trunk information.

This script assumes that the directory structure on the disk mimicks the directory structure on the SVN repository, with a prefix (here: f:\work): f:\work\theProject\branches\aBranch\foo.txt corresponds to file foo.txt in the root directory of project theProject on branch aBranch. This will open page https://your-fisheye-server/browse/theProject/branches/aBranch/foo.txt. Of course, you will probably want to edit the location of the server...

rem
rem Launch a browser directed to the Fisheye page for
rem a particular file.
rem
rem mailto:xavier.nodet@gmail.com
rem

@echo off

rem Assumption: first argument is a absolute path to the file
rem on the disk for which we would like to display the
rem corresponding Fisheye page.
set FILE=%1

rem Remove the "f:\work" prefix from the file path
set FILE=%FILE:f:\work=%
rem @echo %FILE%

rem Replace all the backslashes with forward slashes
set FILE=%FILE:\=/%
rem @echo %FILE%

start "c:\Program Files\Mozilla Firefox 4\firefox.exe" https://your-fisheye-server/browse%FILE%

You will have to launch this script from your IDE with as single argument the full path to the file you want to see in Fisheye. Here is how to do this from Visual Studio. Open the 'Tools' -> 'External tools...' menu, click the 'Add' button, and fill the information needed, using $(ItemPath) for the argument:
You now have a 'Current file on Fisheye' entry on your Tools menu, that you simply have to choose to launch Firefox...

I hope you'll find this useful...

Thursday, August 27, 2009

A short introduction to VSProps files in Visual Studio

Until recently, from the moment I created a second project in my solution, I started muttering against Visual Studio because I had to change the same information in several places to update the configuration of my projects. Maybe this is over now...

Suppose you have a Visual Studio solution with several projects : two libraries, a DLL build from them, a few EXE projects to test the DLL. Suppose the two libraries and the DLL use a third-party library, and you'd like to be able to change the version of this library easily. Suppose also that you'd like to add pre-compiler definititions to all the projects.

Visual Studio offers a feature to solve this issue, the Visual Studio Property Sheets, or VSProps. These files are more or less equivalent to the configuration/properties part of the Project files. You can assign Property Sheets to Projects, and Property Sheets can inherit from other Property Sheets. Such a tool can greatly ease the management of project configurations in Visual Studio.

With suitable property sheets, each configuration data appears once: changing the version of the library, or which values are defined, does not require you to change them in each project.


Creating a Property Sheet

To create a Property Sheet, choose 'View' -> 'Property Manager'. Right-click on the project into which you want to add the Sheet, choose 'Add new project property sheet...', and specify a name and a path.

The new sheet appears as a sub-node in each of the existing configurations. Right-click one one of those sub-nodes, choose 'Properties', and you are presented with the full dialog that you already know from the properties of a project.

The values you enter here will be used by any project that uses this property sheet (the first such project being the project into which the sheet was created).

Inheriting the values of Property Sheet

If you look at the 'General' tab of the project's properties, you will notice the 'Inherited Project Property Sheets' property now has the name of the Property Sheet you just created. This means that this project uses all the values defined in the property sheet.

A project may use several property sheets, listed in this field. The values in the ones listed on the top override, when applicable, those that come from sheets listed below.

Note that Property Sheets themselves can inherit values from other property sheets. You can thus build hierarchies of sheets to separate concerns (e.g. one sheet to configure the libraries used in the project, and one other to configure the compiler settings).


Example: choosing a library version

Suppose several projects in your solution use a third-party library that's available in two different versions that you wish to support. Build two separate sheets, one for version X and one for version Y of the third-party library. In each sheet, specify the include path to add and the lib to link with. Name them libX.xml and libY.xml. Then you build a single property sheet lib.xml that has no configuration value but inherits either from libX.xml or libY.xml. Let all your projects inherit from lib.xml. The effect is that changing the version of the library only entails changing which sheet lib.xml inherits from. One change, for the whole solution...