Sorry for the (very) late post! I fell rather ill on the day before I was going to write the next post, and haven't been well enough to write it until now! Hopefully more cool posts will be on their way soon :-)

How many times have you just finished adding a new feature to your latest and greatest program, and hit the "Run" button in Visual Studio or Monodevelop? Have you ever wondered what happens under the hood? Have you ever encountered a strange build error, and just googled the error message in the hope of finding a solution?

In this post, I'm going take you on a journey to understand the build process for a typical C&sharp; program that happens every time you press Ctrl + Shift + B (or F8 in Monodevelop). I also hope to show you why I think it's important to understand what happens behind the scenes.

To start any journey, we need a map. I've created a simple diagram for our journey. We'll dive into the world of the project file further down. Lastly, we'll end our journey at the individual source code files that actually make up your project.

Before that though, we need to make a quick stop in your sln file. The sln file (or Solution File) is the place where everything starts. Normally, you only get one solution file for each project you create. It's the file that keeps track of the name of your project, its id, and where all the projects are that your solution references (they're usually in appropriately named subfolders). Note that it doesn't keep references to the other projects that you reference (that's done at the project file level).

Solution files sometimes automatically detected too (xbuild does this for sure). If you're in a command line or terminal, you can build an entire solution with just one command, without having to open Visual Studio or Monodevelop:

With that out of the way, we can talk about project files. Project files define which source code files should be built, and how. You can even add custom triggers that run at any time before, during, or after the build process here (this is how I embedded commit hashes in a C&sharp; binary)!

Though the syntax is quite simple, much of it is, sadly, un or underdocumented. Thankfully most of it is quite intuitive, and a little experimentation goes a long way:

The above is a (simplified) example if a project file. It might be called something like CoolSpace.csproj. It references a few core assemblies, specifies a few C&sharp; files for compiling, and embeds a resource or two.

Of course, these files are generated for you automatically, but it's always helpful to know how to works so not only can you fix it more easily when it goes wrong, but you can also extend it to do extra things that you can't through the user interface, like use wildcards (careful! Too many wildcards can slow down your build) to specify a range of files that you wan to embed without having to go around them all one by one.

Next, let's talk about references. References allow you to pull in code from elsewhere, like a core system library, another project (that's how you link 2 projects in (or even out of!) a solution together), a library of sorts (like Nuget), or another random DLL or EXE (yes, you can reference other executable files) file lying around. With references, yo can spread your code around loads of files and pull in libraries from all over the galaxy and have the build process follow all of your references around and tie everything up into a nice neat package for you.

The next piece of the puzzle is the builder. The software that actually builds your code. On Windows with Visual Studio, it's called msbuild, and is the original build tool, created by Microsoft, that sets the standard. On Linux, there's a different (but very similar) tool called xbuild. xbuild implements the standard that msbuild sets, allowing solutions written on Windows with Visual Studio to be compiled 9 times out of 10 on Linux (and probably Mac too, though I don't have one to check - let me know in the comments if you have one!) without any changes.

The final stone in the bridge, so to speak, is your code itself. The builder (whether it be xbuild or msbuild) preprocesses each included file into an object file, which are then all linked together into the final executable binary, which itself contains common intermediate language (or CIL) which is executed by your operating system (or mono on Linux / Mac). While CIL is a different topic for a separate time, it's still important, so I'm mentioning it here.

If you've made it this far, congratulations! I hope that it made sense. If not (or even if it did!), please leave a comment down below and I'll try to help you out :-)

Comments

Leave a comment

Mess with this field at your own risk. It is here to catch spambots, and so altering it could cause anything to happen!

Comment:

?

Commenting FAQ

What are the commenting rules?

Never use your real name.

Do not give away any personal informtion.

Criticism is welcome, but it must be constructive.

No abuse or inappropriate content of any kind will be tolerated.

Do not spam.

Any comments that are seen to not follow these rules will probably be deleted. It may also result in a ban for the offending user such that they are unable to view the site for an arbitrary length of time.

These rules may also be ammended without notice, so please check them often.

How can I format my comments?
Basic markdown can be used to format your comments:

Type this

To get this

Notes

*bold text*

bold text

-

_italics text_

italics text

-

~~deleted text~~

deleted

-

`code text`

code text

Inserts some monospaced code. Eventually syntax highlighting will happen automatically. It is preferred that large blocks of code are linked to using a service such as Pastebin, Github Gists or Ideone.

Inserts a hyperlink. Please use responsibly. [rel=nofollow] is in use and spam will be deleted.

---

Inserts a horizontal line. The previous line must be blank.

All HTML will be escaped with HTML entities such that code in <code> blocks will be visible, and for security reasons.
The maximum number of characters allowed is 2000.
What is my email address used for?

Your email address, should you choose to provide it, is used to send you notifications of replies to your comment(s). It is used to display your Gravatar.

Your email address will be kept securely on the server, and nobody else will be given your email address. You will not receive any spam either.

If you do not wish to recieve emails anymore, please email emails@starbeamrainbowlabs.com and I will prevent emails from being sent to your email address. I will eventually write an automated system to handle this, but for now I will deal with requests manually. I should get back to you within 48 hours. Note that your (gr)avatar will also disappear and be replaced by an identicon.

Built by Starbeamrainbowlabs. Feedback can be sent to feedback at starbeamrainbowlabs dot com. Comments can be made on all blog posts. Some icons from the awesome Open Iconic icon set.