0

A few of our NuGet packages, in a framework we use for our ASP.NET MVC sites, reference binaries EVOPdf / EVOPDFtoHTML to be exact that I'd rather not have hard pathed on our build machine. The specific versions we are using are not found on nuget.org any more, so we are forced to hold onto the .dll's ourselves.

The solution I have come to involves housing those binaries in source control, and building them as an in-house NuGet package to be distributed to the other packages that need them; while this works, and though it eliminates hard-pathed references, it goes against standard practice to house binaries in source control.

Because I am one of the few who access this NuGet framework (and the wonders of VSTS) I am not too worried about slowing down our branch splitting/merging times but I am still wondering if there is a more practical way to accomplish this.

Naveen
  • 1,441
  • 2
  • 16
  • 41
Cian Estella
  • 15
  • 5
  • If the only problem is that your source control shouldn't be holding binaries, you can always store those somewhere else, keep paths in your source control and wire up some script/build step/process magic to get the binaries when the time is ripe for building. Another lame workaround, if the DLLs involved are .NET assemblies, is to `ildasm` them -- presto, now you have actual source, albeit IL, and you can `ilasm` them together again as a build step. (Of course, this will not work if your assemblies are signed, as you presumably lack the key.) Some tweaking is necessary for a safe roundtrip. – Jeroen Mostert Aug 20 '19 at 14:08
  • Last but not least, you could simply forego all of this, accept that you have no source and that source control is inappropriate, and arrange for a good backup scenario for your custom packages. Presumably they will never need to be built again, so it makes no sense to keep them in a *versioning* system. – Jeroen Mostert Aug 20 '19 at 14:10
  • Kind of defeats the purpose of continuous integration to keep specific DLLs on the build machine IMO but I see your point. I think my best option here is to keep the DLLs in source control, as they have to be housed somewhere. Since we aren't going to be seeing changes to these binaries, I feel there will be no issues usually associated to the normal issues with keeping binaries in source control like manual handling upon merging branches and whatnot. Thanks – Cian Estella Aug 20 '19 at 14:18
  • Well, you don't need to keep them on the build machine per se -- in fact I'd recommend against that, they should be stored independently. You're just not strictly required to store them in the source control system; a separate file share would also do. Of course then you need to set that up and give the build machine access. – Jeroen Mostert Aug 20 '19 at 14:23

0 Answers0