Friday, 16 December 2016

Bonkers Build Server

Setting up a VSTS Build Server to do automated builds and run unit tests. Life is good, I have provisioned the VM and installed all the necessary tools required to build and test my solution. I queue a new build and watch helplessly as my build fails on the step to execute my lovely unit tests (SSDT unit tests if you must know).

This is the exception that I get:

Microsoft.Build.Exceptions.InvalidProjectFileException: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.  ... Aborting test execution.

But wait, I have logged on to the build server vm and built and tested my solution manually so I know all the bits are on the machine, so what's up dude, you're ruining my day!!

The key word in the exception is "<Import>". My test project is configured to deploy a database project before executing the tests. If I unload my database project and search for 'Import' this is what I find:



Since the Visual Studio version in which the SSDT target exists is 14.0, and the test project clearly doesn't specify a version when it references the database project, I only needed to change the default VisualStudioVersion in the database project file to 14.0 rather than 11.0 for the build server to find it and run my tests. Yeehhhaa!!

Now to figure out why the Build Agent can't upload the test results to VSTS :-(

Later dudes and dudettes.

Thursday, 15 December 2016

VSTS Agent Proxy Hell

Well, not quite fire and damnation but quite a lot of grief.

Let me start by saying how much I appreciate Visual Studio Team Services (aka VSTS) - it is a fantastic product and although stuff keeps changing (and you need to remember that) it is usually for the better.

For example: the build agent that you can download and install on a local build server is often changing. I can tell this because the folder structure changes almost every time I set up a new build server. I think this is great! It means that the VSTS team are continually improving the product.

However, one issue relating to agents that can be quite annoying and time consuming is trying to figure out how to tell it to use a proxy server to connect to VSTS. In the old days an agent would use the default IE proxy settings, then came the 'modify the agent config file' approach which meant adding the following to the VsoAgent.exe.config and VsoAgentService.exe.config files:



But now there is a different approach (and it is a little Git-ty) where you simply add a .proxy file to the root of your agent folder. Really simple if you know to do it and rather painful if you don't because the previous approaches just won't work :-(

Check this out https://www.visualstudio.com/en-us/docs/build/admin/agents/v2-windows#web_proxy

Happy days dudes and dudettes, it now works!

Monday, 5 December 2016

"Microsoft" -and "Licensing" -eq "Pain"

This is new to me...

Apparently, you can't use Reporting Services to connect to an incorrectly matched SQL Database SKU: https://blogs.msdn.microsoft.com/psssql/2013/02/20/rs-database-engine-does-not-meet-edition-requirements/

If you try to, you get this lovely exception in SSRS:


The interesting thing is I got this exception trying to setup a SQL Express Reporting Service data source connecting to a Developer edition of the database server. I thought Express was free so why would they put restrictions on what database server it connects to?

Ahh well...time to install SSRS Developer edition I guess :-)