I've spent a fair amount of time recently with MSBuild, and have the following set of observations about its relationship to [N]Ant:
1) There is an inter-target dependency engine. Targets can declare their inputs and their outputs, which are in turn fed to the dependency engine to determine the minimal set of targets to build. This is a good thing for more complex builds. 2) There is a concept of an Item, which on the surface looks a lot like a FileSet. However, it goes quite a bit deeper than that. Items can be transformed by individual tasks. So, for example, you could generate output assembly names based on the value of an Item passed as input to a task. Those output assembly names are themselves Items, and can be fed as input to other downstream tasks. Items can also have arbitrary metadata (think a property bag associated with each item), and that metadata can be inspected by individual tasks. 3) MSBuild is integrated with the project system in VS.NET Whidbey. So *.proj files are MSBuild files. 4) MSBuild tasks are very similar to [N]Ant tasks. There is a bool Execute() method as opposed to a void ExecuteTask() method. The logging interface has different method names. But all in all, [N]Ant tasks can easily port to MSBuild and vice-versa. Today I just built an FTP task that works in both MSBuild and NAnt. I'll ship these tasks in the next week or so once I get a chance to write up some detailed commentary about MSBuild in an upcoming issue of my newsletter. If you want to see a rather unorthodox use of MSBuild, check out my AssemblyDiff utility that I wrote to calculate the diff between two different sets of assemblies (I used it to figure out all of the new types in Whidbey). It's at http://www.iunknown.com/000364.html. What's interesting about AssemblyDiff is that I use MSBuild as the engine to drive two custom MSBuild tasks: one to generate a text file containing assembly metadata and another one to drive GNUWin32 diff.exe. The use of Items to generate the set of input files to my custom tasks was a natural fit for this type of utility. I believe that a [N]Ant developer / user will feel fairly at home in MSBuild (at least this one does). Cheers, -John http://www.iunknown.com PS Here's a sample MSBuild script that I pulled from some docs I have here: <Project MSBuildVersion = "1.2" DefaultTargets = "SmallBuild" > <Property AssemblyName = "BruteForceEngine.dll" /> <Property DelaySign = "false" /> <Property OutputType = "Library" /> <PropertyGroup Condition="'$(Config)'== 'DEBUG'"> <Property Optimize = "false" /> <Property OutputPath = "bin\Debug\" /> <Property WarningLevel = "1" /> </PropertyGroup> <PropertyGroup condition="'$(Config)'=='RETAIL'"> <Property Optimize = "true" /> <Property OutputPath = "bin\Release\" /> <Property WarningLevel = "4" /> </PropertyGroup> <Item Type="References" Include="System" /> <Item Type="References" Include="System.XML" /> <Item Type="References" Include="System.Data" /> <Item Type="PrjReferences" Include="..\Logging\BruteForceLogging.proj"/> <Item Type="PrjReferences" Include="..\Graphics\BruteForce3D.proj" /> <Item Type="WebReferences" Include="http://akipman1/service1.asmx"; /> <Item Type="XSD" Include="**\*.xsd" /> <Item Type="Blueprint" Include="**\*.xaml" /> <Item Type="CodeFiles" Include="**\*.cs" Exclude="**\generated\*.cs" /> <Item Type="CodeFiles" Include="..\..\Resources\Constants.cs" /> <Item Type="EmbeddedResources" Include="Resources\Strings.resx" /> <Target Name = "BigBuild" DependsOnTargets = "SmallBuild; PostCompile" /> <target Name = "SmallBuild" DependsOnTarget = "BuildProjectReferences; BuildWebReferences; GenerateSources; BuildResources; Compile" /> <Target Name = "GenerateSources" DependsOnTarget = "XSDTranslation; XAMLTranslation" /> <Target Name = "BuildProjectReferences"> <Task Name = "MSBuild" Projects = "@(PrjReferences)" > <OutputItem TaskParameter="TargetOutputs" Type="References" /> </Task> </Target> <Target Name = "BuildWebReferences" Inputs = "@(WebReferences)" Outputs = "@(WebReferences->%n.dll)" > <Task Name = "WSDL" URI = "@(WebReferences)" > <OutputItem TaskParameter="GeneratedProxies" Type="References" /> </Task> </Target> <Target Name = "XSDTranslation" Inputs = "@(XSD)" Outputs = "@(XSD->%n.cs)" > <Task Name = "XSD" Sources = "@(XSD)" > <OutputItem TaskParameter="GeneratedDataSets" Type="CodeFiles" /> </Task> </Target> <Target Name = "XAMLTranslation" Inputs = "@(Blueprint)" Outputs = "@(Blueprint->%n.cs)" > <Task Name = "XAMLC" Sources = "@(Blueprint)" > <OutputItem TaskParameter="GeneratedSources" Type="CodeFiles" /> </Task> </Target> <Target Name = "BuildResources" Inputs = "@(EmbeddedResources)" Outputs = "@(EmbeddedResource->%n.resources)"> <Task Name = "ResGen" Sources = "@(EmbeddedResources)" > <OutputItem TaskParameter="OutputResources" Type="DotResourcesFiles" /> </Task> </Target> <Target Name = "Compile" Inputs = "@(Code)" Outputs = "$(OutputPath)\$(AssemblyName).dll" > <Task Name = "CSC" Sources = "@(CodeFiles)" Resources = "@(DotResourcesFiles)" References = "@(References)" TargetType = "$(OutputType)" Optimize = "$(Optimize)" WarningLevel = "$(WarningLevel)" > <OutputItem TaskParameter="OutputAssembly" Include="$(OutputPath)\$(AssemblyName)" Type="finalAssembly" /> </Task> </Target> <Target Name = "PostCompile" > <Task Name = "FXCop" Binaries = "@(finalAssembly)" /> </Target> </Project> ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
