Create Nuget Packages for C# #177
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… accepting whatever GitVersionTask gives us
also - fix some minor bugs - and provide a way to increase the verbosity
also, make sure that all MsBuild tasks use a consistent Configuration
…mal logging mode)
… for normal logging mode)" This reverts commit 112f811.
Also fix a bug where a former codegen file was still being declared, but not referenced.
bpkroth
commented
Nov 14, 2020
bpkroth
commented
Nov 14, 2020
bpkroth
commented
Nov 14, 2020
bpkroth
commented
Nov 14, 2020
...al/ExternalIntegrationExample/ExternalIntegrationExample.SettingsRegistry/build/Common.props
Outdated
Show resolved
Hide resolved
bpkroth
commented
Nov 14, 2020
source/Mlos.NetCore.Components.Packages/Mlos.NetCore.Components.Packages.proj
Show resolved
Hide resolved
bpkroth
commented
Nov 14, 2020
source/Mlos.SettingsSystem.CodeGen/build/Mlos.SettingsSystem.CodeGen.targets
Outdated
Show resolved
Hide resolved
…ust NuGetPackageId
This works around the fact that GitVersionTask doesn't support pre-release tags (the only kinds we have for the "master" branch in ADO atm), when attempting to compute the current "version" as an offset from the last tag in Mainline mode. Instead, we detect when we're on the ADO branch by looking for the ADO `.pipelines\pipeline.windows.yml` file and disable GitVersionTask in that case. Also, since Mlos.NetCore.Components.Packages.proj is not a .csproj, it doesn't include the `build/version/Mlos.NetCore.Version.props` file, so we move those property definitions to `build/Mlos.Common.props`. Note that this doesn't prevent that project from packaging things when built on ADO (though it isn't included by default in `dirs.proj`), so one could still test the `ExternalIntegrationExample.SettingsRegistry.csproj` manually, however the versions of the `.nupkg` files it produces will currently always be `1.0.0` so some additional effort may be required to replace previously restored packages using that version.
bpkroth
commented
Nov 17, 2020
bpkroth
commented
Nov 17, 2020
source/Mlos.SettingsSystem.CodeGen/build/Mlos.SettingsSystem.CodeGen.targets
Show resolved
Hide resolved
sergiy-k
approved these changes
Nov 18, 2020
3 tasks
bpkroth
added a commit
that referenced
this pull request
Dec 2, 2020
Work to make it easier/possible to integrate the C++ components of MLOS with an external C++ project (e.g. LevelDB, MySql, etc.) via `cmake`. - Fixes some issues with our own `cmake` config assumptions. - Adds examples patterns and documentation for using in an "external project" (currently just a minimal example). - Hooks those into the CI pipelines. This branch was split off of the work from #177 (since merged) to build NuGet packages for some of the C# components, so many of the original commits are shared.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the first step in a line of work aimed towards making MLOS more natively consumable by external projects.
The basic idea here is that we use the standard .NET.Sdk method of packaging each of the relevant
.csprojs as their own.nupkg.This let's us rely on
dotnetto automatically trackPackageReferenceandProjectReferencedependencies and generate them into the.nuspecthat produces the.nupkg.Since
.nupkgfiles are considered immutable, we have to create unique version numbers for each of them.To do this, I added
GitVersionTask, but only for the OSS builds.Typically, GitVersion expects one to use GitFlow or GithubFlow workflows with develop and release branches.
We are currently only using a Mainline workflow model, so the
GitVersion.ymlfile is configure as such.The versions produced use SemVer by default, so when building on a branch, we get a version like the following:
Mlos.SettingsSystem.CodeGen.0.1.1-codegen-nuget-for-external-project-integration.33.nupkgWhere
0.1.1portion is taken as the number of commits on the mainline branch since the last v0.1.0 tag found in the repo-codegen-nuget-for-external-project-integrationis the name of the branch.33is the number of commits since that branch point.In effect, we can use
git tagto version ourx.y.zreleases, at least until we start addingrelease/0.1.xstyle servicing branches.For the moment, the
.nupkgfiles are not signed and not published (e.g. to nuget.org). Instead, we produce them into thetarget/pkg/$(Configuration)/tree whenever either the newMlos.NetCore.Components.Packages.projis build or else whendotnet packis run on some.csproj.The
ExternalIntegrationExample.SettingsRegistry.csproj(which otherwise uses no Mlos build rules and acts as a standard.NET.Sdkexample) is used for testing and is configured to pull from that tree (for local testing) as well.The next stage of work (separate PR) is to configure a set of
cmakerules usingFetchContentto grab the C++ components, build these packages and reference them when building the rest of a C++ project and its dependencies.TODO:
WONTFIX: