Saturday, December 11, 2010

MSBuild: Quickly produce the Visual Studio Build scripts.

If you have been using MSBuild to build windows based solutions, I believe you already are aware of the raggra(read: hassle) of creating a master msbuild file that contains several projects with each project referencing one or other.

I actually had to manually create the master project (.*proj) file - but that was quite some time ago. So, this time I researched for any improvements that I would find in the latest msbuild. I was looking for something that would ease build writing process a bit; more precisely - I wanted something that would read all of projects and references from within the .sln file, which already "know" the project references and relationships.

Planning to look more into the msbuild, my backup plan was to look into the NAnt functionality. So, fortunately, I found that MSBuild v3.5 or higher allows a .SLN (Visual Studio Solution File extension) as an input argument and generates the master project file from the .sln file including all the project references. Wo-ho!

I'm sure this has made a developers' build job fairly easy, that would otherwise turn into a nightmare with the expanding list of projects in a solution.

A two step solution is to:

1. Using command line set the MSBuildEmitSolution=1
2. Run the command line: msbuild yoursolution.sln /p:Configuration=Release (or Debug if you want)

Note that you can check the list of arguments and switches that come with the msbuild by running msbuild/? on your command prompt. Also note, while you run the above command, you might end up with invalid command; so you must reference the path to you msbuild executable program.

In case you don't know the msbuild.exe location, following might help:

1. Registry locations from where you can find the actual msbuild.exe.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\2.0
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\3.5

2. Following where Task Extensions are located

%ProgramFiles%\MSBuild

As a side note, I'm not sure if I would recommend using the generated .csproj files for production, but I think using the generated .sln files is a good idea.

Be aware that .sln files are not actually valid msbuild project files - they are transformed into msbuild projects by msbuild itself when they are used as inputs.

If you "do" test driven development (TDD), you might want to run your build along with your unit tests. In this case, you can wrap your .sln in a continuous build script project with msbuild tasks to build your projects and run your unit tests together.

This way the developers don't have to run the unit test every time they build - but every time they integrate their code the unit tests will run.

There are couple of other ways to approach the build process:

1. Use MSBuild csproj, and run using the batch file.






2. Create a manual batch file

d:\Program Files\Microsoft Visual Studio 9.0\VC>set MSBuildEmitSolution=1

3. Use PowerShell implementation that recursively scans the script directory for .csproj files and adds them to a generated solution file.

4. Command line
msbuild mysolution.sln /p:Configuration=Release

5. Set variable from within a dll and call the dll from within MSBuild tasks.
Enjoy building, but dont break it! (0:

Wednesday, December 8, 2010

SQL Server: How to find the user who last modified the stored procedure

I believe SQL Server doesn't store this information in its system tables. You can see who owns the procedure, but that is not necessarily the same as who created or last modified the procedure.

You might be able to find out through the default trace (the your data folder for .trc files), but this information is only kept for a few files(5 files and ~100MB each).

There is a Standard Report that will show you the schema change information that comes from the default trace. This simplifies things somewhat for you. (Unless you have the default trace turned off.)

In SSMS, right click on Server Name, choose Reports --> Standard Reports --> Schema Changes History.
The list is in time order with most recent at the top. However, once the report is created, you can export to Excel to make it easier to search for a specific name.

Wednesday, December 1, 2010

Windows XP: Hardware Interrupts consumes >50% CPU, hogging system

Windows XP: Hardware Interrupts consumes >50% CPU, hogging system

Goto: Right click My Computer-->Properties-->Hardware-->Device Manager that would display all of the devices installed in your system.

But we are interested in UNINSTALLED devices. Select Other Devices tree node and open it. If you see the uninstalled devices as mine, then right click and disable those devices. That worked for me.

S0, either install a valid driver or disable the device!

Enjoy!

VS2010: The type or namespace 'FluentNHibernate' could not be found (are you missing a using directive or an assembly reference?

Error:
The type or namespace 'FluentNHibernate' could not be found (are you missing a using directive or an assembly reference?

Problem Statement:
I am using Visual Studio 2010(VS2010); and trying to use NHibernate, but couldnt because of the above error. The namespace(s) already added but somehow it does not read it. Though, my other another project, Visual Studio 2008, with similar FluentNHibernate.dll added to it works fine.

And "Output" window had following information

warning MSB3253: The referenced assembly "FluentNHibernate" could not be resolved because it has a dependency on "System.Data.SqlClient, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which is not in the currently targeted framework ".NETFramework,Version=v4.0,Profile=Client". Please remove references to assemblies not in the targeted framework or consider retargeting your project.

The project was targeting .Net Framework 4 Client Profile by default; I tried changing to .Net Framework 4, worked!

Enjoy!

Related Posts

Popular Posts