Showing posts with label Visual Studio 2010. Show all posts
Showing posts with label Visual Studio 2010. Show all posts

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.


2. Following where Task Extensions are located


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 1, 2010

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

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=, 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!


Related Posts

Popular Posts