Modelon Solutions

Well, one thing we can rely on to be constant is… change…

Nuget in VisualStudio has worked a certain way for a few years… add a line of text to packages.config via the nuget screen and then the restore process will restore that nuget package to a subdirectory named “packages” of your solution. Nuget will then run some stuff from the downloaded package which usually entails adding an assembly reference in your project to an assembly that was contained in the nuget package. Voilà, it works.

Things have changed in the world of UWP (actually .net core and so this applies to aspnet 5 and PCLs). References to nuget packages are simply added to project.json. There are no references to add, nothing. The magic occurs when the compiler starts and creates a project.lock.json file which basically includes the extra magic required for actual compilation (think the dependency of a nuget package). Packages get restored to  c:\users\YYY\.nuget\packages.

I didn’t think I needed to know this until I started testing a pre-release version of  the SQLite-pcl.raw nuget package for UWP. That package is a very low level API to SQLite, and I use another package called SQLite-net-pcl for the high level API. The high-level-api package has dependency on the low-level-api; makes sens. The problem lies in the fact that the package name for the low-level-api has changed from SQLite-pcl.rawbasic to SQLite-pcl.raw. With the old nuget behaviour, since I did not reference the old package name in the package.config, it was never downloaded and the compiler was satisfied because the new package had added the right assembly reference. With UWP, it insists on restoring the high-level-api, the low-level-api i want and the low-level-api specified as a dependency of the high-level-api; that’s when the compiler complains that it found two assemblies with the same name…

Will keep you posted when I find a solution.