Anyone Have Experience Calling Rake from Msbuild for Code Gen and Other Benefits? How Did It Go? What Are Your Thoughts/Recommendations

NAnt or MSBuild, which one to choose and when?

I've done a similar investigation this week. Here's what I've been able to determine:

NAnt:

• Cross-platform (supports Linux/Mono). It may be handy for installing a web site to multiple targets (that is, Linux Apache and Windows IIS), for example.
• 95% similar in syntax to Ant (easy for current Ant users or Java builders to pick up)
• Integration with NUnit for running unit tests as part of the build, and with NDoc for producting documentation.

MSBuild:

• Built-in to .NET.
• Integrated with Visual Studio
• Easy to get started with MSBuild in Visual Studio - it's all behind the scenes. If you want to get deeper, you can hand edit the files.

Subjective Differences: (YMMV)

• NAnt documentation is a little more straightforward. For example, the MSBuild Task Reference lists "Csc Task - Describes the Csc task and its parameters. " (thanks for the "help"?), vs the NAnt Task Reference "csc - Compiles C# programs." UPDATE: I've noticed the MSBuild documentation has been improved and is much better now (probably on par with NAnt).
• Not easy to figure out how to edit the build script source (*.*proj file) directly from within Visual Studio. With NAnt I just have Visual Studio treat the .build script as an XML file.
• Apparently, in Visual Studio, Web Application Projects don't get a *.*proj file by default, so I had great difficulty figuring out how to even get MSBuild to run on mine to create a deployment script.
• NAnt is not built-in to Visual Studio and has to be added, either with an Add-In, or as an "External Tool". This is a bit of a pain to set up.
• (Edit:) One of my coworkers brought this up--if you want to set up a build machine using CruiseControl for continuous integration, CruiseControl integrates with NAnt nicely out of the box. UPDATE: CruiseControl also has an MSBuild task.
• Please see comments below for full and up-to-date discussion of subjective differences.

Good techniques to use Makefiles in VisualStudio?

We use a NAnt script, which at the compile step calls MSBuild. Using NAnt allows us to perform both pre- and post-build tasks, such as setting version numbers to match source control revision numbers, collating code coverage information, assembling and zipping deployment sources. But still, at the heart of it, it's MSBuild that's actually doing the compiling.

You can integrate a NAnt build as a custom tool into the IDE, so that it can be used both on a build or continuous integration server and by the developers in the same way.

Using Makefile instead of Solution/Project files under Visual Studio (2005)

I've found some benefits to makefiles with large projects, mainly related to unifying the location of the project settings. It's somewhat easier to manage the list of source files, include paths, preprocessor defines and so on, if they're all in a makefile or other build config file. With multiple configurations, adding an include path means you need to make sure you update every config manually through Visual Studio's fiddly project properties, which can get pretty tedious as a project grows in size.

Projects which use a lot of custom build tools can be easier to manage too, such as if you need to compile pixel / vertex shaders, or code in other languages without native VS support.

You'll still need to have various different project configurations however, since you'll need to differentiate the invocation of the build tool for each config (e.g. passing in different command line options to make).

Immediate downsides that spring to mind:

• Slower builds: VS isn't particularly quick at invoking external tools, or even working out whether it needs to build a project in the first place.
• Awkward inter-project dependencies: It's fiddly to set up so that a dependee causes the base project to build, and fiddlier to make sure that they get built in the right order. I've had some success getting SCons to do this, but it's always a challenge to get working well.
• Loss of some useful IDE features: Edit & Continue being the main one!

In short, you'll spend less time managing your project configurations, but more time coaxing Visual Studio to work properly with it.

Why is no one using make for Java?

The fundamental issue with Make and Java is that Make works on the premise that you have specify a dependency, and then a rule to resolve that dependency.

With basic C, that typically "to convert a main.c file to a main.o file, run "cc main.c".

You can do that in java, but you quickly learn something.

Mostly that the javac compiler is slow to start up.

The difference between:

javac Main.java
javac This.java
javac That.java
javac Other.java

and

javac Main.java This.java That.java Other.java

is night and day.

Exacerbate that with hundreds of classes, and it just becomes untenable.

Then you combine that with the fact that java tends to be organized as groups of files in directories, vs C and others which tend towards a flatter structure. Make doesn't have much direct support to working with hierarchies of files.

Make also isn't very good at determining what files are out of date, at a collection level.

With Ant, it will go through and sum up all of the files that are out of date, and then compile them in one go. Make will simply call the java compiler on each individual file. Having make NOT do this requires enough external tooling to really show that Make is not quite up to the task.

That's why alternatives like Ant and Maven rose up.

Embed git commit hash in a .NET dll

We use tags in git to track versions.

git tag -a v13.3.1 -m "version 13.3.1"

You can get the version with hash from git via:

git describe --long

Our build process puts the git hash in the AssemblyInformationalVersion attribute of the AssemblyInfo.cs file:

[assembly: AssemblyInformationalVersion("13.3.1.74-g5224f3b")]

Once you compile, you can view the version from windows explorer:

You can also get it programmatically via:

var build = ((AssemblyInformationalVersionAttribute)Assembly
  .GetAssembly(typeof(YOURTYPE))
  .GetCustomAttributes(typeof(AssemblyInformationalVersionAttribute), false)[0])
  .InformationalVersion;

where YOURTYPE is any Type in the Assembly that has the AssemblyInformationalVersion attribute.

---

Related Topics