Das Nuget Package für Lua hat das Update auf die Version 5.4.3 erhalten (https://www.nuget.org/packages/lua/).
Das war ein spannendes Update, weil es das erste Nuget-Package-Update auf meinem neuen Computer war. Ein schöner Test ob ich alle notwendigen Dateien auch schon im Repository hatte. Und, der Test war erfolgreich. Das Update war einfach und problemlos, so wie geplant.
Das Nuget Package für Lua hat das Update auf die Version 5.4.2 erhalten (https://www.nuget.org/packages/lua/).
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
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
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.
Dieser Artikel is nur auf Englisch verfügbar.
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>
<!-- ... -->
