After a month of off & on tinkering, here's my wisdom (All Arc* software referenced below is version 10.4.1, and "the SDK" is shorthand for "the ArcObjects SDK"):
The Short Answer
The path of least resistance is to install the SDK, which has two prerequisites:
- The product(s) against which you are developing (full install)
- A free flavor of Visual Studio supported by the SDK (and indeed required by the SDK installer)
Showing My Work
I created a NuGet package of the needed DLLs in our on-site repo and consumed it in my test solution (the desktop extension with which I'm most familiar). This worked, but it created a confusing (at least to me) tangle of dependencies and strange warnings from MSBuild on my dev machine (stuff I did contradicted the SDK?). And so I abandoned the NuGet approach having never even checked those changes into source control, and I resigned myself to installing the SDK on the build server. That re-requires Desktop, Server, or Engine; and I decided to install ArcEngine since it's the smallest. We installed Engine and re-tried the SDK install, but then received notification that Visual Studio must be installed so we installed Visual Studio Community 2015. Installing the SDK then succeeded.
Our first build attempt failed with the message in the Jenkins console output:
"C:\Path\To\MyProject.csproj(1250,5): error MSB3073: The command "esriRegasm.exe "C:\Path\To\MyDll.dll" /p:Desktop /s" exited with code -1." Running that command directly on the server, we could see that the complete error was
Registration failed. Specified product is not installed. Oh of course. If you're registering COM components with a particular product then that product must be available to be registered against. We uninstalled Engine and installed Desktop, and the build worked. More details on the Desktop install:
- We custom-installed only the "Applications" icon. Everything else--including ArcCatalog and ArcMap--was excluded from the installation.
- We did not license it
Edit: After six more months during which I added more projects to Jenkins (including stuff that needed arcpy, which I neglected to install earlier), I found that you might as well do a full installation. Still no licensing needs for me but that may end up changing. At least that won't take re-installation.
That describes the current state of ArcObjects on our new build server, but despite the functioning build I still wondered...
The SDK is needed on development machines, but what about on a build server? The test build worked even after uninstalling the SDK, with the bare-bones Desktop install supplying all my needed DLLs and EsriRegasm.exe. But there are a couple DLLs available exclusively through the SDK (Addins, Addins.Factory, Desktop.Addins, and SoeSupport), and one anticipated future build is an SOE so we reinstalled the SDK. Another realization I made was that COM registration is needed at install time, not compile time--it's baked into SDK project templates primarily (I think) for working inside Visual Studio's debugger.
Taking those two observations together, all I need on the build server are DLLs. It seems a shop that's a little more savvy & a lot more determined (e.g. they must support multiple versions of Esri software at once?) could completely obviate Esri software on a dedicated build server by implementing the NuGet idea and removing the esriregasm calls in MyProject.csproj (or more likely conditioning them such that they aren't run on the build server but are still available to dev machines for debugging). My biggest concern would be that all that rigmarole could unduly confuse my successors (who will likely contend with plenty other sources of confusion): any new projects developed using the SDK's templates would have to be manually altered to remove/condition the COM registration out during builds.