Now it bumps all dependent versions numbers and only after that, it builds all needed projects so that a build error can be fixed and the build be restarted without have inconsistent version numbers.
laptop:~/Projects/active/NugetCracker$ ./nugetcracker NugetCracker 0.6 See https://github.com/monoman/NugetCracker
Using /home/rafael/Projects/active/NugetCracker/MetaProject.NugetCracker Scanning '.' > '/home/rafael/Projects/active/NugetCracker' . Scanned 144 directories Found 2 components Sorting... Finding dependents...
Ready > l Listing all components... [0001] Commons.Prevalence.1.0 - Minimal prevalence support for .NET [C# Nuget Project] [0002] NugetCracker.0.6 - A builder for versioned nugets within a web of dependencies [C# Project]
Ready > help Available Commands: BumpVersion Bumps up a version for a component Help, ? Show this list of commands or an specific command help List List components, optionally filtered by regular expression Quit, Exit Stops interactive mode Rebuild Rebuilds current version for a component
Ready > r Commons Rebuilding component Commons.Prevalence.1.0 XBuild Engine Version 2.11.0.0 Mono, Version 2.11.0.0 Copyright (C) Marek Sieradzki 2005-2008, Novell 2008-2011. Build started 9/11/2011 2:13:20 PM. __________________________________________________ Project "/home/rafael/Projects/active/NugetCracker/Commons.Prevalence/Commons.Prevalence.csproj" (default target(s)): Done building project "/home/rafael/Projects/active/NugetCracker/Commons.Prevalence/Commons.Prevalence.csproj". Build succeeded. Time Elapsed 00:00:00.8898590
Ready > r Nug Rebuilding component NugetCracker.0.6 XBuild Engine Version 2.11.0.0 Mono, Version 2.11.0.0 Copyright (C) Marek Sieradzki 2005-2008, Novell 2008-2011. Build started 9/11/2011 2:13:46 PM. __________________________________________________ /home/rafael/Projects/active/NugetCracker/NugetCracker/NugetCracker.csproj: warning : Cannot import project '/usr/lib/mono/4.0/Microsoft.CSharp.targets' again. It was already imported by '/home/rafael/Projects/active/NugetCracker/NugetCracker/NugetCracker.csproj'. Ignoring. Project "/home/rafael/Projects/active/NugetCracker/NugetCracker/NugetCracker.csproj" (default target(s)): /home/rafael/Projects/active/NugetCracker/NugetCracker/NugetCracker.csproj: warning : Cannot import project '/usr/lib/mono/4.0/Microsoft.CSharp.targets' again. It was already imported by '/home/rafael/Projects/active/NugetCracker/NugetCracker/NugetCracker.csproj'. Ignoring. /usr/lib/mono/4.0/Microsoft.Common.targets: warning : Found a conflict between : 'System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' and 'System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Using 'System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' reference. Done building project "/home/rafael/Projects/active/NugetCracker/NugetCracker/NugetCracker.csproj". Build succeeded. Warnings: /home/rafael/Projects/active/NugetCracker/NugetCracker/NugetCracker.csproj: warning : Cannot import project '/usr/lib/mono/4.0/Microsoft.CSharp.targets' again. It was already imported by '/home/rafael/Projects/active/NugetCracker/NugetCracker/NugetCracker.csproj'. Ignoring. /home/rafael/Projects/active/NugetCracker/NugetCracker/NugetCracker.csproj (default targets) -> /home/rafael/Projects/active/NugetCracker/NugetCracker/NugetCracker.csproj (default targets) -> /usr/lib/mono/4.0/Microsoft.Common.targets (ResolveAssemblyReferences target) -> Time Elapsed 00:00:04.7531090
Ready > help bumpversion Usage:
BumpVersion [options] pattern
Bumps up the [AssemblyVersion]/Package Version of the component and rebuilds/repackages. The [AssemblyFileVersion] attribute also is kept in sync with the [AssemblyVersion]. If component generates a Nuget it is not automatically published unless the --cascade or --publish options were specified.
Options -part:major|minor|build|revision|none Increments the major, minor, build, revision version number. If option is ommitted the default is to increment build number. -dontcascade Update all dependent components to use the new build/package, and them their dependent components and so on. If some components generate a Nuget, the Nuget is published to a temporary output 'source' and the dependent components have their package references updated, if all goes successfully packages are them published to the default or specified source. -publish Specifies that package should be published if successful. -to: Specifies source other than the default to publish nugets to.
Ready > b nug Bumping component 'NugetCracker' version from 0.6 to 0.6.1 ==== cascading Setting new version to 0.6.1 Building NugetCracker.0.6.1 XBuild Engine Version 2.11.0.0 Mono, Version 2.11.0.0 Copyright (C) Marek Sieradzki 2005-2008, Novell 2008-2011. Build started 9/11/2011 2:15:27 PM. __________________________________________________ /home/rafael/Projects/active/NugetCracker/NugetCracker/NugetCracker.csproj: warning : Cannot import project '/usr/lib/mono/4.0/Microsoft.CSharp.targets' again. It was already imported by '/home/rafael/Projects/active/NugetCracker/NugetCracker/NugetCracker.csproj'. Ignoring. Project "/home/rafael/Projects/active/NugetCracker/NugetCracker/NugetCracker.csproj" (default target(s)): /home/rafael/Projects/active/NugetCracker/NugetCracker/NugetCracker.csproj: warning : Cannot import project '/usr/lib/mono/4.0/Microsoft.CSharp.targets' again. It was already imported by '/home/rafael/Projects/active/NugetCracker/NugetCracker/NugetCracker.csproj'. Ignoring. /usr/lib/mono/4.0/Microsoft.Common.targets: warning : Found a conflict between : 'System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' and 'System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Using 'System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' reference. Done building project "/home/rafael/Projects/active/NugetCracker/NugetCracker/NugetCracker.csproj". Build succeeded. Warnings: /home/rafael/Projects/active/NugetCracker/NugetCracker/NugetCracker.csproj: warning : Cannot import project '/usr/lib/mono/4.0/Microsoft.CSharp.targets' again. It was already imported by '/home/rafael/Projects/active/NugetCracker/NugetCracker/NugetCracker.csproj'. Ignoring. /home/rafael/Projects/active/NugetCracker/NugetCracker/NugetCracker.csproj (default targets) -> /home/rafael/Projects/active/NugetCracker/NugetCracker/NugetCracker.csproj (default targets) -> /usr/lib/mono/4.0/Microsoft.Common.targets (ResolveAssemblyReferences target) -> Time Elapsed 00:00:04.2109010
I approach this with a more systemic view to have something like the MonoMagic App Wall (chose another name because a store would emphasize a commercial offering), with apps that may be easily installable/usable on any of the miriad platforms where Mono/.NET is available, Pinta could just be the forerunner.
Imagine an iPad/Android version of Pinta, with your drawings/photos synced to your personal cloud storage, so that you can take your editing session back at your Linux notebook later...
monoman:~/Projects/NugetCracker$ mono NugetCracker/bin/Debug/NugetCracker.exe -c list NugetCracker 0.4 See https://github.com/monoman/NugetCracker
Using /home/rafael/Projects/active/NugetCracker/MetaProject.NugetCracker Scanning '.' > '/home/rafael/Projects/active/NugetCracker' . Scanned 128 directories Found 2 components Sorting... Listing all components... [0001] Commons.Prevalence.1.0 - Minimal prevalence support for .NET [C# Nuget Project] [0002] NugetCracker.0.4 - A builder for versioned nugets within a web of dependencies [C# Project] Done! monoman:~/Projects/NugetCracker$ mono NugetCracker/bin/Debug/NugetCracker.exe -c bumpversion -part:minor nu NugetCracker 0.4 See https://github.com/monoman/NugetCracker
Using /home/rafael/Projects/active/NugetCracker/MetaProject.NugetCracker Scanning '.' > '/home/rafael/Projects/active/NugetCracker' . Scanned 128 directories Found 2 components Sorting... Bumping component 'NugetCracker' version from 0.4 to 0.5 Setting new version to 0.5 Building NugetCracker.0.5 Done! monoman:~/Projects/NugetCracker$ mono NugetCracker/bin/Debug/NugetCracker.exe -c list NugetCracker 0.5 See https://github.com/monoman/NugetCracker
Using /home/rafael/Projects/active/NugetCracker/MetaProject.NugetCracker Scanning '.' > '/home/rafael/Projects/active/NugetCracker' . Scanned 128 directories Found 2 components Sorting... Listing all components... [0001] Commons.Prevalence.1.0 - Minimal prevalence support for .NET [C# Nuget Project] [0002] NugetCracker.0.5 - A builder for versioned nugets within a web of dependencies [C# Project] Done!
Version 0.4 - BumpVersion now increments version, builds project and packs nuget Uses new color-capable indenting console-logger
Sample session:
NugetCracker 0.4
See https://github.com/monoman/NugetCracker
Using C:\Projects\MetaProject.NugetCracker
Scanning '.' - 'C:\Projects'
..........................
Scanned 6454 directories
Found 36 components
Sorting...
Ready - l inad
Listing components filtered by 'inad' ...
[0001] ManagementPluginAD.2.5.35 - ActiveDirectory Management Plugin [C# Nuget Project]
Ready - help
Available Commands:
BumpVersion Bumps up a version for a component
Help, ? Show this list of commands or an specific command help
List List components, optionally filtered by regular expression
Quit, Exit Stops interactive mode
Ready - help b
Usage:
BumpVersion [options] pattern
Bumps up the [AssemblyVersion]/Package Version of the component and rebuilds/repackages.
The [AssemblyFileVersion] attribute also is kept in sync with the [AssemblyVersion].
If component generates a Nuget it is not automatically published unless the --cascade
or --publish options were specified.
Options
-part:[major, minor, build, revision}
Increments the major, minor, build, revision version number.
If option is ommitted the default is to increment build number.
-cascade
Update all dependent components to use the new build/package, and them their dependent
components and so on. If some components generate a Nuget, the Nuget is published to
a temporary output 'source' and the dependent components have their package references
updated, if all goes successfully packages are them published to the default or specified
source.
-publish
Specifies that even if not cascaded package should be published if successful.
-to:
Specifies source other than the default to publish nugets to.
Ready - b -part:revision inad
Bumping component 'ManagementPluginAD' version from 2.5.35 to 2.5.35.1
Setting new version to 2.5.35.1
Building ManagementPluginAD.2.5.35.1
Packaging ManagementPluginAD.2.5.35.1
Attempting to build package from 'ManagementPluginAD.csproj'.
Packing files from 'C:\Projects\ManagementPluginAD\bin\Debug'.
Using 'ManagementPluginAD.nuspec' for metadata.
Found packages.config. Using packages listed as dependencies
Successfully created package 'C:\Projects\ManagementPluginAD\ManagementPluginAD.2.5.35.1.nupkg'.
Ready -
Using C:\Projects\xxx\MetaProject.NugetCracker Scanning '.' > 'C:\Projects\xxx' .......................... Scanned 6454 directories Found 36 components Sorting... Ready > help Available Commands: BumpVersion Bumps up a version for a component Help Show this list of commands or an specific command help List List components, optionally filtered by regular expression Quit, Exit Stops interactive mode Ready >
Well lately I've been a heavy user of NuGet packaging, trying to tame versioning issues in some proprietary projects I work on that evolve, and partly reuse, near to a hundred libraries (many of them in vertically-dependent sets aligned to 'plugins' in the applications).
Let's put it bluntly: IT'S A NIGHTMARE.
First of all, we have many solutions as it is unfeasible to load and work with a single one containing hundreds of projects.
Also we needed to organize source in a hierarchy of folders, for subsystems, for specific plugin trees, for product, separating test projects, etc... So it means we have tree of folders with projects in leafs, nested 3,4, or more levels down from the solution that uses them.
Finally, we have solutions that share some projects (one of the purposes of adopting NuGet is to avoid this pattern, but we aren't there yet).
Summing up the above points, we are very very far from the NuGet assumption of a single-solution, with all projects nested just one level, and mainly using external NuGets from the standard source feed.
<digression>
The standard NuGet feed is rarely used by us, because most packages there just don't support .NET 2.0, which our projects are still bound to, the sole package we could use from there was log4net, which is stable for some years, The rest we needed to cook our own versions of nugets for Npgsql, nHibernate 1.2, Castle.ActiveRecord 1.0RC3, and so on. All of this is published on a server shared folder, as we doesn't have time allowance to setup a NuGet server
</digression>
Let's just exemplify what all that means...
A contrived and simplified scenario:
Library NugetCracker.Core 1.0.0.0 depends only on framework assemblies.
Library NugetCracker.CLI 1.0.0.0 depends on NugetCracker.Core 1.0.0.0 and framework assemblies
Library NugetCracker.Web 1.0.0.0 depends on NugetCracker.Core 1.0.0.0 and NancyFX and framework assemblies
Program NugetCracker 1.0.0.0 depends on NugetCracker.CLI 1.0.0.0 and NugetCracker.Web 1.0.0.0
Now if we allow the Package Manager to get away with forcing bindingRedirects in the app.config (or web.config), we could publish a new nuget for NugetCracker.Core 1.0.1.0 and update just the NugetCracker program. Now, this may work if the changes are non-breaking, but if, for example, you need to add a new method to some interface in core that the other libraries must implement and the program uses, we will have to update the intermediary nugets, build and publish new nugets, and them update the program.
I think that now you can easily extrapolate that for my real scenario that means many iterations of building/publishing/updating across many solutions.
Well time to fast-forward to what I expect to be able to do when my newest project NugetCracker 1.0 is done:
In the command line:
> NugetCracker
Scanning for solutions in .
Found NugetCracker.sln
-- Project NugetCracker.Core generates nuget for version 1.0.0.0
-- Project NugetCracker.CLI generates nuget for version 1.0.0.0 depends on NugetCracker.Core
-- Project NugetCracker.Web generates nuget for version 1.0.0.0 depends on NugetCracker.Core, NancyFx
-- Project NugetCracker generates program for version 1.0.0.0 depends on NugetCracker.CLI, NugetCracker.Web
No nugets sources specified using default feed
No publishing feed/share specified, publishing to folder .\NugetPackages
Command > BumpVersion --minor --cascade NugetCracker.Core
Bumping version of package NugetCracker.Core to 1.1.0.0
Building NugetCracker.Core
Packaging NugetCracker.Core.1.1
Publishing NugetCracker.Core.1.1 to .\NugetPackages
Updating Package Dependency on NugetCracker.Core to 1.1 in NugetCracker.CLI, NugetCracker.Web
Bumping version of package NugetCracker.CLI to 1.1.0.0
Building NugetCracker.CLI
Packaging NugetCracker.CLI.1.1
Publishing NugetCracker.CLI.1.1 to .\NugetPackages
Bumping version of package NugetCracker.Web to 1.1.0.0
Building NugetCracker.Web
Packaging NugetCracker.Web.1.1
Publishing NugetCracker.Web.1.1 to .\NugetPackages
Updating Package Dependency on NugetCracker.CLI to 1.1 in NugetCracker
Updating Package Dependency on NugetCracker.Web to 1.1 in NugetCracker
Bumping version of program NugetCracker.Core to 1.1.0.0
Building NugetCracker
Packaging .\NugetCracker.1.1.zip for zip installation
Command > PublishTo -Apikey xxxxxxx -Source http://nuget.mycompany.com/
Publishing NugetCracker.Core.1.1 to http://nuget.mycompany.com/
Publishing NugetCracker.CLI.1.1 to http://nuget.mycompany.com/
Publishing NugetCracker.Web.1.1 to http://nuget.mycompany.com/
I'm developing my first app for the iPhone using Mono, MonoTouch and MonoDevelop in a Mac Mini. Never used seriously a Mac before, and last time I've developed something professionally for an Apple platform was for the Apple II, back in the 1970s (yes, I'm that old...).
Anyway, it is awesome to be able to leverage my skills with Mono and C#, instead of having to resort to Objective-C, to get the job done.
So far, I'm tackling the still steep learning curve over Cocoa, Interface Builder, and the limitations imposed over Mono by the AOT compiling the iPhone platform mandates.
My app has just a Login View, so far, that already interacts and validates against a hard-coded password, and Monodevelop generates an executable with some 4.7 Megabytes to be deployed to the iPhone Simulator.
When you think that all the Mono native runtime and huge parts of the basic class library already in native binary format is in there, I think it is a reasonable size, that won't grow much until I add loads and loads of functionality to the application.
I've been using the evaluation version of Monotouch so far, but I think it is proving itself worth the price, and my boss already said the investment on buying one or two (if we buy a second mac) enterprise licenses has a green.
Now I'm going to move more code from our J2ME version of the app to C#, while also trying to build an usable interface on top of it along the Apple guidelines.
Starting a new open source (BSD license) project at google code: DinDin, which is a Brazilian Portuguese slang for money, as it is a distributed multi-platform home finance system based on Mono (WinForms+ASP.NET+Ajax) and maybe Moonlight.
Yes, I know, DinDin is also a childish slang for Dinner in English.
Ben has started a series of posts, similar to what I intended to do (always the lazy blogger excuse) about how to go incrementally developing a web application in the test-first way (writing the unit tests before the code). What I normally do differently from him is that he goes backwards throughout the layers (he starts with the controllers' layer, going down to the service layer, and so on) and I tend to begin at the service and model layers, and go up afterwards, because most of my projects tend to have requirements for supporting multiple-UI and/or for publishing some SOA interface (binary or xml, web services).
I think the repeated maxim "put yourself in your user's shoes", is very hard to try to accomplish in practice, for some reasons.
But for complex functionality I think two reasons are foremost:
You really may not know enough of your users everyday tasks related with it, and how they are used to deal with it, but as you are being paid to develop something new, probably they aren't happy with it anyway, and they are waiting for you to come with some breakthrough, so they are only the best sources to gather "hints" on what should be designed, but not the "reference" for it. So as some have said, you need to cross those hints with ideas from other realms. This mindset is hard to come by, or develop: to keep your mind open to many influences/ideas and look out for the 'hidden' connections that could be explored to come up with an innovative solution.
Complex UIs need to be simplified, and that means putting most important features in front of the user's nose (or mouse pointer), and hiding what can be guessed by the code. But here the problem is if you have a single user it is somewhat simple to figure out, what it really NEED to do, and find some good guesses from usage stats, but normally you are faced with a variety of users, maybe approaching your UI with different needs, so you'd end up with an 'averaged' solution that's dissatisfies more than satisfies most of your users. Cloning the UI in per-user-profile fine-tuned simplifications yields better results, but navigation and maintenance become harder. Another approach is to make the UI adaptive and then customizable, first keeping more frequently/recently used things on the 'top' and allowing the user to pin/unpin things and defining default values and such.
In short both issues compound to this conclusion: Good complex UI/functionality design isn't the thing you can expect to be able to do (even after intensively training yourself) in minutes/hours, it just takes more time and more than that some inner peace to be able to "imagine" the solution.
