My history with Build Servers & Continuous Integration Servers consisted of two phases, first when I was working for employers who aren't aware of benefits of CI process, I used to have my own servers & tools. I used to treat myself as a Team, first they used to laugh at this attitude until they realised how helpful it can be. Later, when CI & CD processes became more popular and I joined more skilled teams, it was normal to find such services already available, so I didn't bother to have mine.
Recently, I decided to have my own build server again to use it for both experiments & OSS. So I needed it to be accessible from `anywhere`. Obviously the word `anywhere` immediately triggers the Cloud muscle in our heads & that what happened :)
First, I thought about a very economic option, The Amazon Web Services - Free Tier. I found that I can have a micro VM instance for free that hosts Windows Server 2012. I gave it a try. I believe that Amazon has a wide range of cloud services but it's not very popular for us, .Net developer, because of our focus on Windows Azure & Microsoft technologies which integrate very well with tools we use everyday. I created the instance & installed TeamCity & configured a project but that took a huge amount of time! The micro instance is very slow (by design). It was 100% CPU most of the time although I'm waiting. Then TeamCity started to behave in a weird way. I couldn't install a Build Agent & when I install it I cannot find it to assign it a job! It think that was a result of TeamCity Java applications won't crazy because of lack of resources. At this point I decided this is not a good experience & will cause issues in future, I'd better to try a paid service & see how much it costs. I believe this is what is call it "What You Pay Is What You Get" I don't blame Amazon or AWS at all.
Next day, I decided to try same steps on Windows Azure Virtual Machine (small 1.75GB Ram), back familiar land, which was much faster than the micro instance obviously. I configured a TeamCity project for my recent pet project ReliableUnitOfWork.SqlAzure but the build failed! Though It builds successfully "on my machine" (pardon me for this!) The build was complaining about those errors
- Debug\DebuggingCommandInterceptor.cs(16, 17): error CS0012: The type 'System.Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Runtime, Version=18.104.22.168, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
- Debug\DebuggingCommandInterceptor.cs(16, 17): error CS0012: The type 'System.Exception' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Runtime, Version=22.214.171.124, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
I tried to solve this at the beginning but but then I guessed that this not the real cause of failutre. By digging further in the build log I found the error hiding in a warning message!
- C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(983, 5): warning MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.5" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
I couldn't find a way to reinstall .Net 4.5, the installer says there's an already installed recent version. I tried to use .Net Framework Repair Tool but the tool couldn't solve the issue & just generated a mass of logs! Finally I found the solution after jumping between different links & questions on StackOverflow, I found it here. Briefly, I have to copy the .net framework assemblies folder "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5" from my machine to new the build server where the MSBuild expects to find it. During this search, I saw many developers mentioned that they gave up & installed VS2012/13 Express though they don't like this. The folder was about 100 MB and takes 17 MB after compression. I shared the zipped file via Google Drive to download it from the build server & finally the shiny Green moment of truth happened! :)
I think Microsoft is already aware of such issues in Windows Server 2012 & they have a list of known issues already. Also releasing the repair tool, 5 days ago, is a good step though it seems it doesn't catch all issues yet but hopefully in future.
At the end, I hope this may save someone's time until a proper fix is ready.