After a lot of dillydallying, mainly due to laziness, Radical (well a part of it) it is finally arrived on nuget:
Cool…but what a pain Smile, I’ve rebuild/reorganized everything 3 times before banging on target.
Some tips for the first time user:
  • First of all read the manual Smile;
  • Get the tools, especially if, like me, you don’t like the console Winking smile;
  • Go and read David Ebbo’s posts, they are a lifesaver and avoid that you bang your head against the wall…as I did Confused smile;
After those 3 things…well breath, breath and breath again…now review some of your code and concepts:
  • nuget packages must be small, when you add a nuget reference all the assemblies found in package will be referenced in the project;
  • Visual Studio will try to add the most suitable reference…what does it mean? imagine that the package has the following structure:
    • Package:
      • net35
        • Radical.dll
        • Radical.Windows.dll
      • net40
        • Radical.Windows.dll
and that the project you are working on targets the .net 4.0 framework, you end up having only the Radical.Windows.dll referenced by the project.
So the solution is to have small packages that depends on other small packages, at first you can think that it is a mess, but in the end you’ll find that handling small packages is far better because lets you handle dependencies and upgrades in a more agile manner;
  • One last, but not least, thing I really like of nuget is a side-effect: basically nuget force you to do a deep use o unit tests, even if you are only using nuget just for your own needs; basically the update process is a process and as all the processes requires a bunch of steps every time you need to upgrade a component, and once you have deployed a failing component you need to update all the stuff once again…a pain, far far better to unit tests everything in order to dramatically reduce the effort of the redeploy;
Happy nugetting Smile with tongue out