1

I have been trying to find an "elegant" way to integrate non-NuGet package with my Bamboo builds.

There's a plethora of stacks on the topic of adding non-NuGet packages into NuGet bundles:

managing non-nuget dlls along with nuget packages

Creating NuGet package with reference to a non-NuGet reference

Trying to add non-.NET libraries to NuGet package

and the list goes on. There's also many a stack about using NuGet in Bamboo and that part works smoothly.

None of these deal with the situation of having an automated build environment, which may be sitting on some other remote server, running Bamboo.

Specifically, I'm trying to automate Xamarin.iOS deployments to HockeyApp.

The steps are:

  1. Coding and local testing in VS2015 on Windows and with Mac for iPhoneSimulator
  2. Merge into deployment branch and push to Bitbucket server
  3. Bamboo picks up the push and kicks off build
  4. Build checks out deployment branch
  5. Runs NuGet downloads
  6. Starts compile for Ad-Hoc/iPhone environment, creating IPA
  7. Kicks off the HockeyApp deployment (there's a free addon for that)

Nearly all the steps are in place, except for the one where I have 2 dependencies which the commercial vendor (Syncfusion) has for unknown reasons decided to bundle into their "Studio" product, from where my Visual Studio project/solution has to refer to them by location outside of my project directory.

As a result, my Bamboo build fails with not-found DLLs, because they're missing as they would have to come in somewhere between 5. and 6. above.

I don't want to copy the binaries and then check/commit/push them into my repository, as that's considered a Bad Thing. My Bamboo Plan already successfully grabs NuGet packages before the actual build without having to drag binaries along.

Simply copying the DLLs on to the Bamboo build machine (i.e. where the remote agent is running) was one idea, but the problem is that the VS/MSBuild project file now has hard-wired directories - so, I'd have to install the whole Syncfusion Studio, or emulate their directory structure just for those 2 DLLs.

So I would need to adjust the .csproj references in an automated fashion. Not sure how I would do that, except with Yet Another Task and Script.

Apart from yelling at Syncfusion (which I've already done) about making all their DLLs available through NuGet (because some are, and those I'm successfully receiving in step 5. above), does anybody have a suggestion how to get this missing step to work?

Community
  • 1
  • 1
Marakai
  • 1,163
  • 11
  • 26

1 Answers1

0

For expediency sake, I have now added the libraries to the repository in a separate sub-directory.

It's not how I wanted to do it, but as the 2 libraries were a mere 200-300KB each and as there just didn't seem to be a simpler solution it solved the issue for now.

Specifically:

  • Leave .dll in .gitignore
  • Copy libraries you need into local sub-directory, e.g. LocalLibs/
  • add specific libraries with git add -f LocalLibs/speciallib.dll so that only these become a part of the repo
  • Change the project reference in Visual Studio to point to the local libraries, instead of their main install location
  • Verify that builds still work from within Visual Studio but also with MSBuild

I may revisit this and update if a better way comes along, especially if the libraries are significantly larger, such that you definitely would not want to add them to your repository.

Marakai
  • 1,163
  • 11
  • 26