If you are using the NANT management to generate a process, then you will pay attention to Msbuild. The reason is very simple, because it belongs to Microsoft, you don't like it, but you must learn to use it.
After a few nights, I finally made myself adapted to the grammar of Msbuild. This is really not easy, especially when you are used to Nant's lowercase specification. But this is not a problem, because with your own understanding of Msbuild, you really like it.
Ok, let me briefly introduce my experience in learning MSBuild use. If you are still in the door of Msbuild, then I hope this thing can take you into the door.
Ready to work
The first thing to mention is about how to use some important resources in MSBuild. They are:
1. Alex Kipman's MSDNTV SHOW:
Http://msdn.microsoft.com/msdntv/episode.aspx?xml=episode/en/20040122vsnetak/manifest.xml
2. Alex Kipman and Rajeev GOEL speakers on PDC2003:
http://microsoft.sitestream.com/pdc2003/tls/tls347.htm
The above two from the Alex Kipman from the MSBuild development group, in theory, he should be the first person to learn Msbuild, and several demonstrations he gave me very helpful. (But I don't like his voice, and it is harmful.)
3. MSBuild Doc
Http://msdn.microsoft.com/longhorn/toolsamp/default.aspx
This is the most important, including five important documents of the Alex Kipman main pen: MsbuildFileFormat, MsbuildWalkthrough, MsbuildTasks, HOWTOWRITEATASK, and MSBuildCommandline. This may be the most detailed documentation of MSBuild that can be obtained in the current situation.
Demo
Ok, everything is ready, let us start with a simple example.
First write a simple C # Console program (you can also change it to vb.net):
// Hellomsbuild.cs
Using system;
Class Hellomsbuild
{
Public static void
Main
()
{
Console.writeline ("Hello Msbuild!");
}
}
Below we will write a .csproj file to control the entire generation process. It is worth noting that if there is no specific project file when calling msbuild.exe, the MSBuild engine finds a project file named *. * Proj in the current directory. If you write multiple such project files in the same directory, you need to manually specify the target file of MSBuild.exe, the method is:
Msbuild a.csproj
Otherwise, MSBuild will prompt an error and ask you to manually specify the target project file.
The following is a project file:
Directories = "$ (bin)" Condition = "! EXISTS ('$ (bin)')" /> Sources = "@ (source)" Targettype = "EXE" Outputassembly = "$ (bin) / $ (outputassembly) .exe" /> Command = "$ (bin) / $ (outputassembly) .exe" /> If you haven't had the experience of Nant's development experience, then these things are definitely scary. At this time, the best way is to open the MsbuildFileFormat, find the meaning of the corresponding item elements in accordance with the above code. Below I explain it for important project elements. Project element. This is the outermost element of each project file, which represents a range of projects. If this element is missing, MSBuild will report to the target element that cannot be identified or not supported. The Project element has multiple properties, which is most commonly used in the defaultTargets property. We all know that there may be a few different tasks in a project's generation process (such as compile, unit test, check-in to source control servers), where each task can be represented by Target. For projects with multiple Target, you can specify which (a few) Target you want to run by setting up Project's defaulttargets (note is the plural) property, such as: ... or: ... If there is no setting, Msbuild will run only the Target that is ranked in the forefront. 2. Property element. In the project you must have to access some information frequently, such as the path name that needs to be created, the final generated program set name. This information you'd better don't have Hard Code into the project unless you have never changed it once. At this time, Property can be used to use it. You add the information mentioned above in the form of Name / Value, followed by access as $ (propertyName). This way you don't have to let the entire project file hurt the bones in order to change a file name. For example, bin in the above code is the path name that will be created, and AssemblyName is the finals of the final generated. The names of these attributes are not fixed, you can name it in your own habits. When using, you need to put the property name in "$ (" and ")" pairs (excluding quotation marks) to indicate that this will be replaced with a value of a Property element. In addition, if the number of PROPERTY elements is more, you can also put them in different PropertyGroups to increase the readability of the code. This doesn't have any effect on Property itself. For example: 3. Item element. In the entire project file, you must provide some input resources (INPUTS) information that can be referenced, such as source code files, quoted assembly names, which require embedded icons. They should be placed in Item for reference. The syntax is: The TYPE attribute can be seen as a category name of the resource, such as for the .cs source file, you can set their TYPE to Source, set Type to Reference for reference, so that you will then want to quote this When the category resources are referenced, you can quote this Type, the method is @ (TypeName). Don't fill the reference method with Property. Since Type is the class name of the resource, include the specific resource name. For example, in the sample code above, the include reference is the name of the C # source code file. You can also use wildcards * to expand the reference range. For example, the following line code specifies all C # files in the current directory to reference @ (SOURCE): In addition, you can also put the associated item in ItemGroup by a similar approach to the PropertyGroup. 4. Target element. The above has been mentioned that Target represents a virtual task unit that needs to be completed. Each Project can include one or more Targets to complete a series of customized tasks. You need to set a Name property to each Target (the two Targets under the same project cannot have the same name) to reference and distinguish. For example, in your project generation process, you may need to complete the three phases of tasks: First, from the check-out source code in the VSS, next to compile these code and perform unit tests, and finalize them Check-in return VSS. So usually, you can create three different Targets to clearly divide three different stages: ... ... This way, you can control the entire generation process very clearly. In order to reflect the dependencies between different targets (only after Check-in can be compiled, only CHECK-OUT ... can be completed, you need to set the targetsontargets attribute of Target (note that it is plural), to indicate only when these target The current Target can be performed after completion. When the MSBuild engine starts performing a Target (don't forget the Project's DefaultTargets attribute), it will automatically detect whether the target that it depends on has been completed, thereby avoiding accidents due to a generation of loop missions. You can specify which (several) Targets starting from the Project's DefaultTargets property, or you can use the T switch to manually specify the target to run when calling msbuild.exe. The method is as follows: MSBuild / T: Checkout In this way, only Checkout (and the Target it depends on) will be executed. 5. Task element. This may be the most important of the entire project file because it is a true part of the actual executable (this is why I said that Target is virtual). You can place multiple tasks under Target to sequentially perform the corresponding tasks. For example, in the above sample code, you can arrange MakeDir, CSC, and Exec three different TASK in two different Targets in the sample code. These tasks distinguishes to each other through the Name attribute, each with different other properties to complete different tasks, such as the CSC has an Sources (source code file), TargetType (Target Type), OutputAnsembly, Makedir Simply set the Directories (a list of path names that need to be created). Maybe you will be strange that these Task names and properties come from. Ok, please use the text compiler to open the% windir% / microsoft.net / framework / v1.2.30703 / microsoft.buildtasks file, have you seen it? It should be like this by default (different versions may have a small difference): You will notice that all of the UsingTask arranged under the DefaultTasks element, which indicates each Task TaskName (name) and AssemblyName. For example, the first USINGTASK corresponds to our CSC task, its full name (Namespace Class) is Microsoft.Build.Tasks.csc, located in the Msbuildtasks.dll program (please confirm this in the same directory) The existence of a .dll file). Thus, the MSBuild engine determines the assembly of the CSC through the registration information here when encountering the call to the CSC task, thereby finally run the corresponding managed code. This way, if you have written different Task, please register it in the same way to use. If you quote a Target that has not been registered yet, then the MSBuild engine will not find its existence and cause generation failure. Of course, MSBuild Task's registration method is more than just one. The impact of the above registration methods is a whole game, and you can apply those TASK registered above every Project. But you can also choose to register Task within the Project range, which will correspond to another method. I will give specific introductions in an article behind. Here, you only need to understand where the task you need is found, and their specific usage can be obtained by referring to the Msbuildtasks, here I will say it. OK, introduce a long string, or hurry up our build.csproj. Enter the following command in the same directory of the shell: Msbuild or: Msbuild build.csproj The results of the operation are as follows: D: / dev / mymsbuilddemo> msbuild build.csproj Msbuild build.csproj Microsoft (R) .NET Build Engine Version 1.2.30703.4 [Microsoft .NET Framework, Version 1.2.30703.4] Copyright (c) Microsoft Corporation 2003. All Rights Reserved. Target "Build" in Project "build.csproj" Task "Makedir" Creating Directory "bin". Task "CSC" Csc.exe /out:"bin/hellomsbuild.exe "/ target: Exe" Hellomsbuild.cs " Target "Run" in Project "build.csproj" Task "EXEC" Hello Msbuild! It can be seen that the two Targets and three tasks specified in build.csproj are sequentially run in accordance with the appropriate order. Msbuild also shows the specific commands currently executed, while in the original Visual Studio .net age, you are Unable to learn what is currently executing (according to Alex Kipman, even Visual Studio .NET does not know the specific command being executed, because those commands have been entered "black box", which cannot be extracted at all.). Ok, a simple MSBuild file usage example is here. If you haven't been exposed to Msbuild or Nant before, you hope that this article will make you a preliminary understanding of Msbuild's usage. There are still many details I have not involved in the text. If you are interested, please download the MSBuild documents I mentioned in front of you. I will introduce how to develop my own MSBuild Task in the next article. -------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------- Musicland http://blog.joycode.com/musicland
