2
votes

I have an Azure Function app, written in C#. I can run and debug it locally, using Visual Studio 2017 (Professional, version 15.5.3). I can also build it locally using msbuild from the developer command prompt for vs 2017.

This app will not build on our Jenkins instance - either using Visual Studio Build Tools or by installing Visual Studio Community on the VM (I don't have a licence for professional for a build server) and using the developer command prompt there. (I have ensured that the .NET Core build tools are installed, see Visual Studio 2017 MSBuild failed to build Azure Functions)

I'm getting the following error:

C:\Program Files\dotnet\sdk\2.1.4\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(557,9):
error MSB4186: Invalid static method invocation syntax: "[System.IO.Directory]::GetParent().get_Name()".
Method 'System.IO.Directory.GetParent' not found. Static method invocation should be of the form: $([FullTypeName]::Method()), e.g. $([System.IO.Path]::Combine(a, b)).
[c:\jenkins\workspace\Folder.Name\Job Name\Project.Name\Project.Name.csproj]

I have checked that the mentioned SDK is the same version as that which works on my local machine.

What do I need to do to get this VM able to build an azure function app?

1
Is it possible for you to share your code that triggering that System.IO.Directory::GetParent() code path? That's nothing to do with Functions, so it's likely some kind of configuration issue. - Chris Anderson-MSFT
Also, you may want to check if you're using v1.0.8 on the Azure Functions SDK NuGet package. I was running into build issues on my build server with this version and bumping it to v1.0.9, which was released yesterday, solved my problem. Note: I didn't get the same error as you, but could be worth a shot - Aaron Krone
@ChrisAnderson-MSFT FWIW.... I've got the same error, for a really basic set of azure functions we're trying to get to build with TeamCity. ... also, updating the Functions SDK to 1.0.9 didn't make any difference for me. - reidLinden

1 Answers

0
votes

We had the same issue: "manual" builds — even running on the build server, albeit with a different login — would succeed. The same build scripts failed when run via Jenkins.

The fix for us was to always use a project-local packages directory when restoring (and therefore when building). Jenkins was using a .nuget directory under the \windows\system32 folder, if memory serves. This folder was shared by multiple build jobs, etc. and something was being referenced incorrectly.

Adding a -PackagesDirectory parameter to NuGet restore solved the problem, e.g.:

NuGet -PackagesDirectory mySolutionDir\packages mySolutionDir\mySolution.sln

If you're using dotnet restore, I believe the --packages parameter does the same thing.