[:de] Irgendwie konnte ich GetOpt noch nie leiden. GFlags überzeugt mich in einigen Aspekten auch nicht. Ist aber besser als selber irgendeinen CmdLine-Parser zusammenzustecken.

Ich habe mich bei dem Nuget-Paket auf die statische, thread-sicher Library beschränkt. Wenn ihr eine andere Variante braucht, dann könnt ihr natürlich gerne die AppVeyor-Artefakte herunterladen. Da sind praktisch alle dabei.

Wie üblich, Paket-Code ist frei: https://bitbucket.org/sgrottel_nuget/gflags_nuget[:en] Somehow, I never liked GetOpt. I am not convinced by all details of GFlags as well. But, it is the better option than whipping up some CmdLine parser myself.

For the nuget package I focused only on the thread-safe static library. If you need another variant, feel free to reuse my AppVeyor artifacts. Those include basically everything.

As usual, the package code is free: https://bitbucket.org/sgrottel_nuget/gflags_nuget[:]

[:de]Die Community für native Libraries in Nugets scheint mir nicht sonderlich aktiv. Ich vermute die meisten Leute benutzen cmake, und müssen daher irgendeine zusätzliche Methode für die Paketverwaltung auf ihren Betriebssystemen nutzen, oder so. Wasweisich. Ich mag Nuget. Daher, ohne große Umschweife: hier ist mein neues Nuget-Paket für die LibYAML.

Und, wie üblich, der Paket-Code ist frei verfügbar: https://bitbucket.org/sgrottel_nuget/libyaml-nuget[:en]The community for native library nugets seems not very active. I assume most people use cmake, and have to use some extra scripting for some platform dependent package management, or something. I don’t know. I still like nuget a lot. And so, without further ado: my new Nuget package for LibYAML.

As usual, package code is free: https://bitbucket.org/sgrottel_nuget/libyaml-nuget[:]

[:de]Ich habe das Nuget Package für Lua aktualisiert (https://www.nuget.org/packages/lua/).

Bei der Gelegenheit hab ich das Package auch gleich modernisiert. Ich benutze nicht mehr Coapp, sondern schreib einfach die Nuspec- und Targets-Dateien direkt selbst.

Lasst mich wissen, wenn Ihr mit dem neuen Package probleme habt.[:en]I updated the Nuget package for Lua (https://www.nuget.org/packages/lua/).

And I used this opportunity to modernize the package. I no longer use Coapp, but simply write the nuspec and targets file manually.

Let me know if you have any problems with the new package.[:]

[:en]Previously, I wrote about using one global msbuild xml file to override nuget package content for local development. While this does work, it comes with a warning if multiple packages use this mechanism:

***Test\packages\***.0.7.1-prerelease-\build\native\***.targets(7,5):
warning MSB4011: "***Test\packagesoverride.xml.user" cannot be imported again. It was already imported at "***Test\packages\***.0.7.1-prerelease-\build\native\***.targets (6,3)".
This is most likely a build authoring error. This subsequent import will be ignored. [***Test\***Test.vcxproj]

While this is not realy a problem, it is a warning. And I don’t like warning. I like my projects to build entirly without warnings.

A soltion for this comes from classic c++ programming: use an include guard. These are the changes required:

The packagesoverride.xml.user must define a default variable. I named it HAS_packagesoverride:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <HAS_packagesoverride>True</HAS_packagesoverride>
    <NugetDevPackageTest_testLib_DevDir>C:\Dev\SomeProject\Dir</NugetDevPackageTest_testLib_DevDir>
  </PropertyGroup>
</Project>

And now importing this xml in the nuget packages‘ target files can this for this variable to avoid multiple import:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" InitialTargets="FaroMorfCopySymbols">

  <!-- Import override settings, if they exist -->
  <ImportGroup>
    <Import
      Condition="Exists('$(SolutionDir)packagesoverride.xml.user') and '$(HAS_packagesoverride)' != 'True'"
      Project="$(SolutionDir)packagesoverride.xml.user" />
  </ImportGroup>

<!-- ... -->

 [:]

[:en]Previously, I wrote about using NuGet for software components, which are still in active development. One of the most important factors was the capability to override the nuget package’s content with content fetched from a directory, e.g., a working copy clone. The key element for this was a MSBuild variable NugetDevPackageTest_testLib_DevDir.

The original plan was to edit this variable using a project property page. While having a UI is nice, this has proven not to work on larger projects. The reason is simple: in larger projects, we talk about a vs solution with multiple vc projects, and many of these projects might reference our NuGet package. If we now need to switch to our local directory, we need to adjust the project properties for every project consuming the package. This is tiring and error prone. Forget to adjust just one project and you might end up with inconsistent builds. Therefore, I was seeking a more centralized configuration.

Update 2019-03-02

I updated the code examples to reflect the updates I recently came up with.

Dev. Override – II

The principle idea of having a variable to control the override remains valid. The targets in your nuget might look like this:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <!-- ... -->

  <!-- Compiler settings: defines and includes -->
  <ItemDefinitionGroup Condition="'$(NugetDevPackageTest_testLib_DevDir)' == ''">
    <ClCompile>
      <PreprocessorDefinitions>HAS_NUGETDEVPACKAGETEST_TESTLIB;%(PreprocessorDefinitions)</PreprocessorDefinitions>
      <AdditionalIncludeDirectories>$(MSBuildThisFileDirectory)include\;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
    </ClCompile>
  </ItemDefinitionGroup>
  <ItemDefinitionGroup Condition="'$(NugetDevPackageTest_testLib_DevDir)' != ''">
    <ClCompile>
      <PreprocessorDefinitions>HAS_NUGETDEVPACKAGETEST_TESTLIB;HAS_NUGETDEVPACKAGETEST_TESTLIB_DEVDIR;%(PreprocessorDefinitions)</PreprocessorDefinitions>
      <AdditionalIncludeDirectories>$(NugetDevPackageTest_testLib_DevDir)\Project\include\;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
    </ClCompile>
  </ItemDefinitionGroup>

  <!-- ... -->

</Project>

The obvious question is the definition of our DevDir variable.

For this is propose a central msbuild xml at the level of the vs solution!

We include it in our targets file, right after the root Project tag starts:

<ImportGroup>
  <Import Project="$(SolutionDir)packagesoverride.xml.user" Condition="Exists('$(SolutionDir)packagesoverride.xml.user') and '$(HAS_packagesoverride)' != 'True'" />
</ImportGroup>

This line imports the msbuild xml file, if it exists. Notice, how the file name is generic and not related to our specific package. This is because multiple nuget packages can share this file!

The content of this central configuration is very simple:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <HAS_packagesoverride>True</HAS_packagesoverride>
    <NugetDevPackageTest_testLib_DevDir>C:\Dev\SomeProject\Dir</NugetDevPackageTest_testLib_DevDir>
  </PropertyGroup>
</Project>

Now if you need to override a nuget package for your whole solution, just create this file!

Drawback 1: If the file did not exist previously, an you create it, then you need to rebuild all projects with nugets referencing this package. Because they might be affected by this file.

However, once the file does exist, changes to the file are currectly and automatically detected by visual studio, and build operations are correctly triggered in the affected projects. So, it might be a nice idea to keep a file with an empty property group in place, just in case.

If you need to override multiple nugets at once, just add multiple entries into this one property group.

Drawback 2: There is no UI. So you need to edit it in your favorite text editor, meaning, you are prone to all typing errors you can come up with.

All in all, I believe this central file for the nuget override configuration is an improvement.[:]

[:de]Und hier ist nochmal ein neues Nuget Package:

https://bitbucket.org/sgrottel_nuget/teamcity-gtest-streamer

https://www.nuget.org/packages/teamcity-gtest-streamer

Eine kleine Bibliothek für eine bessere Integration von GoogleTest in TeamCity. Tatsächlich ist es eine einzelne Datei als Header Only Library. Es gibt trotzdem ein Nuget-Paket für einfache Integration und Updates.[:en]And here is another Nuget package:

https://bitbucket.org/sgrottel_nuget/teamcity-gtest-streamer

https://www.nuget.org/packages/teamcity-gtest-streamer

A small library for better integration of GoogleTest into TeamCity. It’s actually a single header-only file library. But it still has a nuget for easy integration and update.[:]