For any extension, be sure to remove all dlls in the src/lib directory when doing any major upgrades. I try hard to gitignore them, but I don't catch it everytime and some folks do so out of habit. They should be periodically removed and re-downloaded.
So far I only have downloaded repositories once, did not update any of them, switched sometimes to something like "v8" branch and after that run that download script.
But speaking generally, despite this download script is definitely a working way to go temporarily, for some period time of some initial development cycle, in general, it is not a correct way to manage dependencies. Dependencies should reside in the package repository, and be precisely versioned. I've already noticed, that you and/or your LANDIS development team have already started to use MyGet service as a package repository, so it looks like you just need to go few more steps in that direction, to get rid completely of those support library download scripts and have NuGet as a sole dependency management tool, as it is normally supposed to be.
For most extensions, I have been removing the reinstall of some core libraries. Assuming there's a succession extension installed, reinstalling these just raises the risk of old dlls overwriting newer ones.
In my case, the thing did not work with newer DLL but started to work with older DLL. Please review again what I've written about version of Universal Cohorts library. Again, we would have this thing solved easier, if all dependencies live in the package repository, and all I would need to get in sync is to just make all involved projects pointing to the same version of the dependency.
Some general notes from me:
-
It would be good, if LANDIS would always print exception stacktrace and full information about any inner exceptions for all the errors after which it stops. That might look a bit uglier to the "normal" end-user, but finally it does not matter, it's easy to learn to ignore that, if required. But for developers it would be obviously far easier to find the place in source code where the problem has happened and think further to make a fix.
-
LANDIS prints me this warning:
Warning: The decimal separator of your system is ','. Most LANDIS-II
Warning: scenario files use '.' for the decimal separator. The scenario
Warning: files may not run or your results could be inaccurate.
It could be fixed in the code of libraries and extensions. Just need to always pass System.Globalization.CultureInfo.InvariantCulture.NumberFormat to methods like double.Parse() and double.TryParse() - and don't bother users for changing their regional settings or edit scenario files.
So far I only have downloaded repositories once, did not update any of them, switched sometimes to something like "v8" branch and after that run that download script.
But speaking generally, despite this download script is definitely a working way to go temporarily, for some period time of some initial development cycle, in general, it is not a correct way to manage dependencies. Dependencies should reside in the package repository, and be precisely versioned. I've already noticed, that you and/or your LANDIS development team have already started to use MyGet service as a package repository, so it looks like you just need to go few more steps in that direction, to get rid completely of those support library download scripts and have NuGet as a sole dependency management tool, as it is normally supposed to be.
In my case, the thing did not work with newer DLL but started to work with older DLL. Please review again what I've written about version of Universal Cohorts library. Again, we would have this thing solved easier, if all dependencies live in the package repository, and all I would need to get in sync is to just make all involved projects pointing to the same version of the dependency.
Some general notes from me:
It would be good, if LANDIS would always print exception stacktrace and full information about any inner exceptions for all the errors after which it stops. That might look a bit uglier to the "normal" end-user, but finally it does not matter, it's easy to learn to ignore that, if required. But for developers it would be obviously far easier to find the place in source code where the problem has happened and think further to make a fix.
LANDIS prints me this warning:
Warning: The decimal separator of your system is ','. Most LANDIS-II
Warning: scenario files use '.' for the decimal separator. The scenario
Warning: files may not run or your results could be inaccurate.
It could be fixed in the code of libraries and extensions. Just need to always pass System.Globalization.CultureInfo.InvariantCulture.NumberFormat to methods like double.Parse() and double.TryParse() - and don't bother users for changing their regional settings or edit scenario files.