DotNetBuild is a build tool designed to simplify how we work with .NET family projects.
C:\> md coolstuff && cd coolstuff
C:\coolstuff\> powershell -Command "& { wget https://raw.githubusercontent.com/buildcenter/DotNetBuild/master/scaffold.ps1 -UseBasicParsing | iex }"
C:\coolstuff\> build configure
C:\coolstuff\> build debug *
C:\coolstuff\> build clean debug *
C:\coolstuff\> build release *
C:\coolstuff\> echo my-secret-apikey > .\credentials\nuget.org.repokey
C:\coolstuff\> build publish .\releases\coolstuff.1.0.0.nupkg
Congrats! You have just built your assembly and published it as a package on NuGet.org. Say what?
Why not indeed! DotNetBuild is not meant to replace your favorite IDE with console and notepad. Instead, it works as a human friendly layer on top of the XML based makefile that MSBuild uses. DotNetBuild takes care of generating the right artifacts, so you can concentrate on the codes that matter.
Compared to VS, DotNetBuild uses a JSON-like format to configure your build:
global.bsd
- Only one per repo. Applies to all projects. It looks like this.project.bsd
- One per project. You can append or override global settings in here. Here is a sample.
The command build configure
creates a working directory and do the following things:
- Copies out your source code to the working directory
- Download the .NET SDK if needed and sets up the
dotnet
cli environment - Creates global level artifacts such as solution file, nuget configuration, global.json, etc.
- Generates project makefiles for MSBuild such as
csproj
- Generates
AssemblyInfo
metadata code (which you configure inglobal.bsd
andproject.bsd
) - Creates localization resources automatically from a special
Properties/StringData.txt
file in your project. - Process text templates in your codes using PowerShell syntax.
The working directory is compatible with Visual Studio for the most part. You can open up your solution file using VS, try out code changes, debug, build and perform unit tests. When you are done, remember to copy your new code back to the source folder.
There is no need to work with files like Properties/AssemblyInfo.cs
, .resx
or csproj
. Just edit your project.bsd
and run build configure
to churn out the artifacts.
DotNetBuild is designed to operate from the command line. This is very important when you are building projects in a CI server:
- Remember to run
build configure
first. - Run
build debug *
to compile all projects in debug configuration, orbuild debug [project1] [project2]
to compile selected projects. - Name your test projects "[project].Tests" to automatically run unit tests after compiling.
- If needed, clean your build output using
build clean debug *
. You can also clean selected projects usingbuild clean debug [project1] [project2]
- Build for release configuration by substituting 'debug' in step 2 for 'release':
build release *
- Release builds produce
nupkg
files too!
DotNetBuild will compile for all target frameworks, runtimes and CPU platforms per your project.bsd
settings.
Share your package with the world or your private NuGet server:
C:\> build publish .\releases\mylibrary.1.0.0.nupkg
Again, you will specify NuGet servers via global.bsd
or project.bsd
configuration. DotNetBuild will automatically push to all servers in your configuration.
The sample source in /src/global.bsd and /src/MyFoo.CSharpLib/project.bsd are rich commented. You should be able figure everything out just by looking at the comments.
Specific schematics are documented in the docs.
Since everything is script and template driven, you should just look at the source whenever in doubt.
If you are interested in fixing issues and contributing directly to the code base, please see the document How to Contribute, which covers the following:
- The development workflow, including debugging and running tests
- Coding Guidelines
- Submitting pull requests
- Contributing to translations
Please see also our Code of Conduct.
- Request a new feature right here.
- Ask a question on Stack Overflow.
- Vote for popular feature requests.
- File a bug in GitHub Issues.
- Tweet us with other feedback.
DotNetBuild dependencies live in their own repositories on GitHub:
Copyright (c) Lizoc Inc. All rights reserved.
Licensed under the MIT license.