The Nuget Package for Lua did get it’s update to version 5.4.3 (https://www.nuget.org/packages/lua/).
This was interesting, because it was the first nuget package update on my new computer. A test, whether or not I included all required files in the repository. And the test was a success. The update was easy, just like planned.
The Nuget Package for Lua did get it’s update to version 5.4.2 (https://www.nuget.org/packages/lua/).
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
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
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.
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>
<!-- ... -->
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.
I updated the code examples to reflect the updates I recently came up with.
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.
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.
GLM
is a nice, lean, good math library for OpenGL. It’s header-only. Does a NuGet package make sense anyway? I say “Yes”. The simple usage and the clean versioning make up for the minimal additional overhead.
I am now also helping in maintaining the GLM Nuget package. And I updated the package to version 0.9.9.
