Skip to main content
edited body
Source Link
TarmoPikaro
  • 5.4k
  • 3
  • 60
  • 71

Then concerning packaging. choco seems to be a subset of nuget - it extends unspecnuspec with it's own xml tags supporting software update. (referred web pages: https://chocolatey.org/, https://learn.microsoft.com/en-us/nuget/reference/nuspec)

Then concerning packaging. choco seems to be a subset of nuget - it extends unspec with it's own xml tags supporting software update. (referred web pages: https://chocolatey.org/, https://learn.microsoft.com/en-us/nuget/reference/nuspec)

Then concerning packaging. choco seems to be a subset of nuget - it extends nuspec with it's own xml tags supporting software update. (referred web pages: https://chocolatey.org/, https://learn.microsoft.com/en-us/nuget/reference/nuspec)

Source Link
TarmoPikaro
  • 5.4k
  • 3
  • 60
  • 71

There are multiple axis on this problem - source code building, installation of package, external repositories, api/abi breaks, build system itself.

First of all your requirements - are you interested only in packaging and/or also installation.

For packaging itself it's possible to use for example following packaging systems: nuget, conan, vcpkg, choco.

Most probably you will be also interested not only publishing the packages itself, but also debug symbols for them.

For azure devops / debug symbols publishing documentation can be found from following links for example:

https://azure.microsoft.com/en-us/blog/deep-dive-into-azure-artifacts/ https://learn.microsoft.com/en-us/nuget/create-packages/symbol-packages-snupkg

Conan (c++ packaging) at the moment does not support symbols publishing: https://github.com/conan-io/conan/issues/4047

To get source code distribution it's possible to use git itself. Git submodules does allow to create external git repository reference, but once you have added external submodule, you need to use double commit to change everything - one git commit to sub repository, one git commit to update referenced git hash from master repository.

There indeed exists some walkarounds to this problems like: nested git without submodules:

Nested git repositories without submodules?

=>

http://debuggable.com/posts/git-fake-submodules:4b563ee4-f3cc-4061-967e-0e48cbdd56cb

If you build however main repository with prebuilt binaries instead of source codes - in ideal solution you don't need that external git repository, meaning also that no git clone / checkout of external repository is needed.

Then it's also possible to have either all-in-one solution or multiple solutions, each compiled separately.

Easier indeed to have all-in-one solution, because it's less hassle with dependent solutions compilation.

To achieve fully dynamic solution generation, it's possible for example to use cmake - it can generate solution depending on preconfigured options used from cmake. (See cmake's "option").

cmake is good alternative indeed for C++ (supports precompiled header, unity building speed up), but maybe not so straightforward for C# (difficult to find necessary parameters how to configure it correctly).

At the moment (5.2020) haven't found any better alternative to cmake, but there are multiple tools and ecosystems evolving in parallel to cmake, so need to observe what future might bring.

Then concerning packaging. choco seems to be a subset of nuget - it extends unspec with it's own xml tags supporting software update. (referred web pages: https://chocolatey.org/, https://learn.microsoft.com/en-us/nuget/reference/nuspec)

If you want to publish nuget package or even installer package, it's possible to use nuget repository (without any extra costs).

If insufficient for your needs, it's also possible to upgrade nuget server to choco server, but it might costs something - see chocolatey web pages.

Api/abi breaks cannot be observed on any level, until actualy compilation / link error occurs or application crashes at run-time - only alternative it's possible to do - is to control versioning of packaging itself - so master package nuget(or choco) version would require higher version of dependent nuget (or choco) version.

If main repository is developed by same guys as child repository - then api/abi breaks can be done by developer itself, but if two gits are independent from each other and developed by different teams - then api/abi breaks can occur at any point of time.

Best way to ensure that repos are consistent - is to have unit testing on of master repository, which would check that no api/abi break occurs.

Theoretically if api/abi breaks occurs - build system itself could continue with two build alternatives -

  1. follow main repository with last working child repository
  2. follow child repository without building main repository

Same mechanics could be applied by using branches, e.g.

  1. "main git: master branch" + "child git: release/1.0 branch"
  2. "child git: master branch"

This is of mechanism might require to observe not only two repository's, but also switching branches in case of long lasting failures. (E.g. development team of child git does not care about build breaks occurring in main git)

Suspect there does not exists any ready made tools for this purpose (please leave comment if such will appear), as this might require reconnect tools from two potentially different build chains from potentially different git repositories, from potentially different organizations.

And last, but not least - if you want your application to be software update capable - then nuget/choco distribution download could be used with additional nuget/choco server.

Here is good example of download part for nuget package: https://github.com/mwrock/NugetDownloadFeed

Install package building is bit more complex issue - see for example following links:

(In order best-worse based on my opinion)