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/
It includes the WebM subproject, that will allow reading/writing WebM files/streams generally and decode/play such streams in Moonlight.
Little time to work on it, so the progress is very slow, but if you want to contribute, please do: Fork it at Github and send those fantastic Pull Requests.
Also please post issues there to help guide/prioritize development, I'm trying to first be able to read the Matroska files, them I'll start the decoder and pump some video data, and last plug it into Moonlight. Writing streams/files has low priority at this point, unless someone really want to develop a video producing app, or a slideshow-to-video converter and want to contribute code and testing to that end.
First step: porting Matroska's JEBML (a Java parser for EBML) to C#. EBML is the "binary xml" format that is the basis for the Matroska (thus WebM) container.
I tried to convert libebml2 (written in C) to C#, but it is too "unobjectifiable" and so I searched a bit more for some easier path. Didn't look at some of the C++ parsers available, but JEBML although looking a bit abandoned of late seems to model the main concepts and surely is a good starting point. JEBML is LGPL-licensed which should not compromise the whole effort.
Going with renaming .java files to .cs, and doing wholesale Find&Replace, but have to stop now, while it doesn't even compile yet. Tomorrow I hope to fix it into a somewhat compilable state, and then, I'll need to move to .NET system classes, and use generics to slim down the whole thing.
The sources so far were uploaded into my Managed.Commons group, later I'll decide if add a project on Google Code, or GitHub.
I've been reading and watching the videos from Google's Campfire One, about the new features they've added to App Engine, specially the Java support, and got thinking of some possibilities when throwing Mono in the picture:
We can see if they have interest in having Mono support in the App Engine, meaning basically to be able to host ASP.NET apps in there. That entails customizing the core libs/APIs using Mono as the VM and the libraries source, and also developing a plugin for Visual Studio (and maybe Monodevelop/Sharpdevelop) to give ASP.NET devs (WebForms and MVC) the same integrated experience they've provided for Java devs using Eclipse
We can help Keerthi's proposal to GSOC for implementing a clone of Azzure take off, and integrate it into Monodevelop, and perhaps Visual Studio. The advantage here being that we would have an open-sourced cloud implementation, that more people can host, even as an in-house solution.
We can retarget the Java in App Engine ideas from Computing in the Cloud, to Computing in the Crowd (Sovereign Computing), it even keeps itself in the Java realm for the Sneer implementation of SC.
Sneer.NET could offer something akin to Azzure
We can drop all but the main concepts and have some Mono-based Cloud Implementation.
Well possibly some other permutations are also viable.
I've just thought to get the ball rolling on discussing those dreamable projects.
Nice screencast from my friend Rodrigo, the creator of boo and boojay.
Highly recommended. The most interesting part is that the pipelined design of the boo compiler allows this, to have it targeting different virtual machines and class libraries.
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).
http://support.castleproject.org//browse/MR-270 is my first contribution to Castle Project.
The Jira Issue Tracking system for Castle looks to be experiencing some problems now.
Basically I'm wrapping an exception in an outer scope and throwing the new exception that captures more information for easing debug (the resourceName for the template NVelocity is trying to process).
Today I went to a robotics fair, here in São Paulo, as my 6 years old son just LOVES robots.
For him, even seeing an enormous soldering robot (a big mechanical red arm) drawing a Betty Boop character on a sheet of paper clamped to a flip chart, is something really marvelous.
Obviously, the Lego NXT robot kit was the thing that made he throw a "Can you help me buy that (finance), daddy?" look, which I have to counter with some fast math on how it would take him nearly two years without any money just to pay me the cost of such a 'toy' (I give him US$ 5,00/week, and with import taxes such kit would cost over US$ 550,00, here).
Anyway, after walking all around the booths, seeing the competitions, and son on, we were walking back to where I parked my car (half-a-mile away, under a torrid sun), and I remembered the other high cost 'toy' he wanted to buy, just yesterday, and iPod (or at least some mp3 player), and I was foolish to propose him why we wouldn't project an hybrid walking-robot/mp3-player, so that it would follow him around the house (or at least walk-around) playing some tunes.
Yeah, I really have a BIG mouth... Only because lately, I've been programming PICs, ARMs and such other embeddedable things...
Nevertheless, coming back home I researched a bit (Google, of course) and found some robot projects, but none really in the way may son would like. Yet I've found some interesting pieces:
First, I found the OpenServo project, what could make for cheaper servos to give precise movement capabilities to the robot (http://www.openservo.com/).
Then I've stumbled on the always interesting Make Magazine, what do I find there? An open-source mp3-player hardware module, the Daisy MP3 Player. But as someone commented in the associated Step-By-Step Tutorial (in another site) for this kit, it is a little too bulky and costs too much just to play mp3 files.
Warning: the 'open-sourcedness' of such projects is acquired by the fact that they have the decoder in hardware (some specialized DSP-based chip) and you are already paying the royalties for the MP3 patents, when you buy the chip.
This is a truly interesting project, and hast come to plug some curious extras like an FM transmitter, to allow to play on your car stereo...
Well to put some limit on this babbling, all of that is nice, and ok, but hey, I'm a Linux user/dev and all my music is in the Ogg format (and I want to keep it that way), so I needed to find if such chips could help play ogg files, instead of mp3. Some of them, specially some more recent ones (the ones used in those projects are some 3 to 5 years old), are Multiformat, but that really means MultiProprietaryFormats (MP3/WMA/AAC), some chips in the Micronas line even come with builtin DRM features (argh!!!).
But at the end I've found something really, really interesting and recent. From Finland (again) comes a full Ogg Player on a chip, courtesy of the fine engineers at VLSI Solutions (http://www.vlsi.fi/vs1000/vs1000.shtml).
The VS1000, is a complete solution, you just add the Oscillator Crystal, some NAND-Flash memory, an AAA battery, some buttons and connectors (USB/earphones) and voilá, you have fully working very small Ogg Player.
In truth it does a bit too much for my needs, but you can hook into the DSP code to change bits a little (for example, the default ROM behaves as a Storage Device [stop playing musics] when connect in and USB port, and I would like to be able to control things with the robot microcontroller (possibly an ATMEL ARM, like in the Lego NXT, or maybe some of the bigger PICs).
Well lots of things to play with... in my mind at least.
After viewing Wade's post on OpenSuse, I decided to try it on my Fedora Core 6, and it also works. Thanks Wade.
The good question, that naturally comes from it, is:
Why there isn't a checkbox for this on the screensaver preferences dialog?
UPDATE:
Because, for Fedora at least, it doesn't quite work the way you expect it to (the WinXP Home way):
1 - It only gives me the opportunity to switch to a different user when asking the password to come back from the screen saver (No 'System' menu entry for switching instead of logging-out is available) 2 - In that screen saver dialog, you can click a button show another one where you can choose another user, but the user id gets asked again as it falls down to the same session manager screen as you would have after a logout.
Even my, then, 5 year-old boy could switch to his account on my WinXP machine, nearly two years ago, but he can't still deal with switching/logging-in in my Fedora machine.
I hope all distros will get user-friendly user switching (and I hope some freedesktop standard will make all of them work the same way) in the near future, but so far Fedora is truly lagging behind.
I'll start Commons.GetOptions outside of Mono, and just keep Mono.GetOptions 1.0 stable (only security fixes) inside Mono svn. That would help with stability requirements for Mono colliding with the desire for innovation/improvements on GetOptions.
I'll post details as I progress with it. But some of the ideas I already have are:
to make it I18n-friendly (either gettext and resources, by defining/using localization providers and matching tools)
drop the multiple constructor overloads for the attributes, in favor of the supported syntax for field initialization by name
refactoring into a layered design, that should allow for imperative definition of option sets, besides the declarative form currently supported
subcommands support
easier runtime addition of options
a tool to compile a DSL (Domain Specific Language) to binary optionsets classes and/or generate (cia codedom) partial classes sources in any language that have correct codedom support installed.
a GTK# GUI tool (also wrapped as a MD plugin) to write the above DSL (some call it a graphical DSL)
A WinForms component/editor to define/generate/use the DSL
