Archive for the ‘Open Source’ Category

Getting closer… Castle Windsor 3 RC 1

Sunday, November 20th, 2011

Few weeks later than orig­i­nally expected but here it is – Cas­tle Wind­sor 3.0 (along with its facil­i­ties and Castle.Core) achieved release can­di­date status.

There is one major new fea­ture in this release: reg­is­tra­tion API gained abil­ity to spec­ify prop­er­ties to ignore/require. There are some sce­nar­ios where that’s use­ful, for exam­ple where inte­grat­ing with some 3rd party frame­work that forces you to inherit from a base class which exposes its depen­den­cies as prop­er­ties. Cre­at­ing pass-through con­struc­tors for each inher­ited class can be mun­dane. In those cases you can sim­ply mark those base class prop­er­ties as required, in which case Wind­sor will not allow them to be resolved unless all base prop­erty depen­den­cies are sat­is­fied. Prop­er­ty­Fil­ter enum sup­ports sev­eral other most com­mon sce­nar­ios, and for advanced cases there’s an over­load that gives you more control.

Container.Register(
    Classes.FromThisAssembly()
        .BasedOn<ICommon>()
        .Configure(c => c.Properties(PropertyFilter.RequireBase)));

To address per­for­mance hit at startup Wind­sor no longer enables per­for­mance coun­ters by default. Now, you have to do it explicitly:

var container = new WindsorContainer();
var diagnostic = LifecycledComponentsReleasePolicy.GetTrackedComponentsDiagnostic(container.Kernel);
var counter = LifecycledComponentsReleasePolicy.GetTrackedComponentsPerformanceCounter(new PerformanceMetricsFactory());
container.Kernel.ReleasePolicy = new LifecycledComponentsReleasePolicy(diagnostic, counter);

Full changelog is included in the pack­ages. Please, if pos­si­ble, take the time to upgrade to this ver­sion and if you find any issues report them so that the final release is rock solid. If no major issues are found, the final release will be pub­lished in two weeks.

The bina­ries are avail­able on Nuget right now, and soon on our web­site.

Posted in Castle, Open Source, Windsor | 5 Comments »

Simple guide to running Git server on Windows, in local network (kind of)

Saturday, August 20th, 2011

Last year I found myself in a sud­den and quick need to set up work­ing envi­ron­ment for a team of four, and as I like Git very much, I wanted to use it as our VCS. The prob­lem was, we weren’t allowed to use any third party provider, so GitHub was off the table. As I searched the Inter­net there were a few guides to set up team Git envi­ron­ment on Win­dows, but they all seemed very com­pli­cated and time con­sum­ing. For our mod­est needs we exper­i­mented a lit­tle and came up with a solu­tion that was very sim­ple, didn’t require any addi­tional soft­ware to be installed any­where and worked like a charm.

Recently I used it again on my cur­rent engage­ment, and one of my col­leagues sug­gested I should blog it, so here goes.

Ready, steady, go

The guide assumes you already have your local Git set up. For that, there are plenty of resources on the Inter­net, includ­ing my own blog­post about Win­dows Git tool­ing.

The entire tricks works like this – expose folder con­tain­ing your shared Git repos­i­tory as Win­dows net­work share.

Step one – bare git repository

There are two twists to the entire solu­tion – one of them is – your shared repos­i­tory needs to be ini­tial­ized with –bare flag.

git_bare_repository

Step two – Win­dows share

Sec­ond step is to expose the folder with our newly cre­ated repos­i­tory on the Win­dows share. You also use your stan­dard Win­dows mech­a­nisms to con­trol and limit access to the folder (make sure you give the devel­op­ers write access!).

Step three – Map the share as net­work drive

This step is per­haps not exactly nec­es­sary but I couldn’t get it to work oth­er­wise, so here comes the sec­ond twist. In order for your devel­op­ers to be able to access the shared folder via Git they need to map it as net­work drive.

sshot-10

Step four – Add remote repos­i­tory in Git and code away

Last step is the stan­dard Git pro­ce­dure – every devel­oper on your team needs to add the repos­i­tory sit­ting under their newly cre­ated net­work drive as remote. Notice the use of “file:///” pre­fix in front of the mapped drive name.

sshot-11

Step five

That’s all. I hope you find it use­ful, and if you know a way to elim­i­nate step three, let me know in the comments.

Tags:
Posted in Git, Open Source, Tools | 2 Comments »

Git tooling for .NET developers

Wednesday, January 26th, 2011

Many devel­op­ers work­ing on Win­dows stay away from Git. There are many rea­sons for this but from my obser­va­tions and dis­cus­sions I’ve had, the most com­mon can be sum­ma­rized by this tweet by my friend Paul Stovell:

 

can everyone please stop using Git? Mercurial has a better UI (TortoiseHG), I'm sick of Git UI's

I’m not get­ting into holy wars, and I’m not try­ing to con­vince any­one that Git is bet­ter than any other VCS. Instead I’ll walk you through the tool­ing I use to inter­act with Git on Win­dows, with Visual Studio.

Git Exten­sions

First thing you should be get­ting is Git Exten­sions.

Git Extensions context menu

With that, sim­i­lar to Tor­toi­seX fam­ily of tools you get nice con­text menu that gives you access to most com­mon oper­a­tions quickly, via GUI, and with no need to mem­o­rize com­mand line options if you want to avoid it. You can also launch Git com­mand line in the selected folder and then all power of git is at your disposal.

Visual Stu­dio

If you’re a .NET devel­oper, you’ll want to work from within Visual Stu­dio. I’m sure you’ll be happy to learn that Git Exten­sions has a really nice Visual Stu­dio inte­gra­tion as well.

git_extensions_visual_studio

You get two things – a menu with all the options that Explorer con­text menu gives you and more, includ­ing abil­ity to edit .git­ig­nore file (also the tool will gen­er­ate a new .git­ig­nore file for you with Visual Stu­dio spe­cific rules!) and to launch a Git bash. Also you get a Git tool­bar with most com­monly used com­mands: Com­mit, browse, push, pull, stash and access to settings.

The way I usu­ally work with it, is I use Git bash for most oper­a­tions. There’s one excep­tion to that rule though – committing.

git_extensions_commit_window

I think Git Extensions’s Com­mit win­dow is the best of all VCS I’ve worked with. It clearly sep­a­rates files you want to com­mit (in your Index) and files you leave out for now. It clearly shows you sta­tus of each file (new, deleted, mod­i­fied) with dis­tinc­tive, large icons, also it shows you an on-the-fly diff of what changed in any given file, and it’s blaz­ing fast. Mostly the read­abil­ity ben­e­fits are why I stick to the UI for this operation.

Visual Stu­dio Git Source Con­trol Provider

In addi­tion to Git Exten­sions I use another tool called Git Source Con­trol Provider which plugs into stan­dard Visual Stu­dio VCS provider mech­a­nism to give me some addi­tional func­tion­al­ity (you can get the tool via Visual Stu­dio exten­sion manager).

git_source_control_provider

There are a few use­ful capa­bil­i­ties pro­vided by this tool that I tend to rely on quite often (there are more than that as you can read on the tool’s page):

  1. Over­lay icons show­ing you sta­tus of each file in Solu­tion Explorer.
  2. It shows you name of the cur­rent branch in the Solu­tion Explorer bar at the top (see “(mas­ter)” on the screen­shot below), and you will work a lot with branches in Git.
  3. It gives some addi­tional options in the con­text menu.

git_source_control_provider_screenshot

This (plus com­mand line) makes the job very, very sim­ple and quick, and that’s what I stick to on my machine.

There’s one more thing that makes work­ing with Git a plea­sure (espe­cially if you’re work­ing on a team that’s not com­pletely co-located).

Github

I love Github. It has a very clean, sim­ple inter­face that makes going through project his­tory, diff­ing com­mits and code reviews a very sim­ple and fric­tion­less process.

 

Sum­mary

Yes, per­haps those tools lack some eye candy that other tools have but frankly – I don’t care, and nei­ther should you. They are more than enough to let you quickly do what­ever you need to do with your code and don’t stand in your way. And that’s what a good VCS and tool­ing around it should be – some­thing you don’t really have to think about and you can rely on to keep track of what is hap­pen­ing with your code with con­fi­dence. And that’s pre­cisely what Git is – so if you’ve been held back, go ahead, install those tools and give Git a shot – you won’t look back.

Tags: , , ,
Posted in .NET, Free, Open Source, Tools | 6 Comments »

Point point one release for Windsor and Castle.Core

Tuesday, September 21st, 2010

Exactly one month after release 2.5.0 we released first minor update to this release for Wind­sor and Castle.Core. It con­tains some minor improve­ments and fixes for issues that were iden­ti­fied after the 2.5 release. Com­plete changelog for Wind­sor con­tains 20 items, and 9 for Castle.Core, includ­ing sin­gle break­ing change, which is dele­tion of web log­ger so that Castle.Core has no depen­dency on System.Web and we no longer need to pro­vide two ver­sions for .NET 4 (one with Client pro­file sup­port, and one with full profile).

There’s one rel­a­tively major fea­ture in the release that you should be aware of – debug­ger views in Wind­sor were extended with detec­tion of poten­tial lifestyle mis­matches. When you step over your con­fig­ured con­tainer in the debug­ger the fol­low­ing item may now appear in the list:

mismatches

This lets you detect sit­u­a­tions where you have a sin­gle­ton com­po­nent that depends on a tran­sient or per-web-request com­po­nent, which is usu­ally a bug (although there are rare cases when sin­gle­ton depend­ing on tran­sient is a valid solution).

In addi­tion to the list, the Descrip­tion will give you… well – descrip­tion of the situation:

mismatches_text

Notice that this is only a helper and due to dynamic nature of Wind­sor it can only detect a sta­t­i­cally known sub­set of pos­si­ble depen­den­cies. As such you should not assume that if the fea­ture does not detect any issues there aren’t any.

You can down­load the projects from Source­forge as usual:

Posted in Castle, DynamicProxy, Open Source, Windsor | 2 Comments »

Semi final release – Windsor 2.5 beta 2 (now with Silverlight support)

Wednesday, July 21st, 2010

A bit later than expected (ah, work) I pub­lished beta 2 of Wind­sor 2.5 today. The release has the fol­low­ing changes as com­pared to beta 1.

  • Sil­verlight ver­sion (for Sil­verlight 3 and Sil­verlight 4) is now included in the package.
  • Syn­chro­nize Facil­ity is now included in the pack­age (.NET only)
  • The fol­low­ing code changes and fixes were made (incl. one break­ing change)

    • - added sup­port for select­ing com­po­nents based on cus­tom attrib­utes and their prop­er­ties. See Component.HasAttribute<T>() methods

    - added WithService.DefaultInterface() to flu­ent API. It matches Foo to IFoo, Super­FooEx­tended to IFoo and IFooEx­tended etc. If you know how Default­Con­ven­tion works in Struc­tureMap, this is pretty similar

    - added sup­port for Castle­Com­po­nen­tAt­tribute in flu­ent API. Also added helper fil­ter method Component.IsCastleComponent

    - added abil­ity to spec­ify inter­cep­tors selec­tor as a ser­vice, not just as instance

    - added abil­ity to spec­ify proxy hook in flu­ent API

    - index­ers on IKer­nel are now obsolete.

    - added With­Ap­p­Con­fig() method to log­ging facil­ity to point to log­ging con­fig­u­ra­tion in AppDomain's con­fig file (web.config or app.config)

    - BREAKING CHANGE: Restruc­tured life­cy­cle con­cerns — intro­duced ICom­mis­sion­Con­cern and IDe­com­mis­sion­Con­cern and favors them over old enum dri­ven style.

    - Fixed how con­tex­tual argu­ments are han­dled. Null is no longer con­sid­ered a valid value (That would cause an excep­tion later on, now it's ignored).

    - Changed method Deferred­Start on Startable­Fa­cil­ity. It now does not take a bool para­me­ter. A DeferredTryS­tart() method was intro­duced instead.

     

This is prob­a­bly the last pre-release for 2.5 and if no crit­i­cal issues are found, we’ll release final release in 2, 3 weeks. Go grab the bits, see if it works for you and if it does not report back. I’m also look­ing for peo­ple who want to con­tribute sam­ple appli­ca­tions for the final release. Ping me if you’d like to con­tribute to that.

Posted in Castle, Open Source, Windsor | 3 Comments »

.NET OSS dependency hell

Thursday, February 25th, 2010

Paul, whom some of you may know as the main­tainer of Horn project, left a com­ment on my blog, that was (or to be more pre­cise – I think it was) a con­tin­u­a­tion of series of his tweets about his dis­sat­is­fac­tion with the state of affairs when it comes to depen­den­cies between var­i­ous OSS projects in .NET space, and within Cas­tle Project in particular.

paul_twitter

I must say I under­stand Paul, and he’s got some valid points there, so let’s see what can be done about it.

Prob­lems

One of the goals of Cas­tle Project from the very begin­ning has been mod­u­lar­ity of its ele­ments. As cas­tle main page says:

Offer­ing a set of tools (work­ing together or inde­pen­dently) and inte­gra­tion with oth­ers open source projects, Cas­tle helps you get more done with less code and in less time.

How do you achieve mod­u­lar­ity. Say you have two projects, Foo and Bar that you want to inte­grate. You could just ref­er­ence one from the other.

eb1c2cc[1]

This how­ever means that when­ever you use Foo, you have to drag Bar with you. For exam­ple, when­ever you want to use Mono­Rail, you’d need to drag ActiveRe­cord with it, along with entire set of its depen­den­cies, and their depen­den­cies, etc.

Instead you employ Depen­dency Inver­sion (do not con­fuse with Depen­dency Injec­tion). You make your com­po­nents depend on abstrac­tions, not the imple­men­ta­tion. This how­ever means, that in .NET assem­bly model, you need to intro­duce third assem­bly to keep the abstrac­tions in.

51067fb6[1]

Now we have 3 assem­blies instead of 2 to inte­grate two projects. Within Cas­tle itself com­mon abstrac­tions are being kept in Castle.Core.dll. But what if we want to take more direct advan­tage of one project in another project still main­tain­ing the decou­pled struc­ture? We need to extract the func­tion­al­ity bridg­ing the two projects to yet another assem­bly. Tick – now we have 4 of them.

607f68d4[1]

In this case the Foo­Bar project would be some­thing like ActiveRe­cord inte­gra­tion facil­ity, which inte­grates ActiveRe­cord with Wind­sor.

When you mix mul­ti­ple projects together you enter another prob­lem – versioning.

Say you want to inte­grate few projects together, some of which are inter­de­pen­dent (via bridg­ing assem­blies, not shown here for brevity)

69f20a13[1]

Now, once a new ver­sion of one of the projects is released, you either have to wait for all the other projects to update their depen­dency to the lat­est ver­sion, do it your­self (pos­si­bly with some help from Horn), or stick to the old ver­sion. The sit­u­a­tion gets even more com­pli­cated when there were some break­ing changes intro­duced, in which case plain recom­pi­la­tion will not do – some actual code would need to be writ­ten to com­pen­sate for that.

These are the main issues with this model, let’s now look at pos­si­ble solutions.

Solu­tions

First thing that comes to mind – if hav­ing some assem­blies means you’ll need even more assem­blies, per­haps you should try to min­i­mize that num­ber? This has already come to our minds. With last wave of releases we per­formed some inte­gra­tion of projects. EmailSender got inte­grated into Core, one less assem­bly. Log­ging adapters for log4net and nlog were merged into core project, which means they still are sep­a­rate assem­blies (as they bridge Cas­tle with 3rd party projects) but they’re now synced with Core and are released with it, which means this is one less ele­ment in your ver­sion­ing matrix for you to worry about. Sim­i­lar thing hap­pened with Log­ging Facil­ity, which now is ver­sioned and released with Wind­sor itself.

For the next major ver­sion, there are sug­ges­tions to take this one step fur­ther. Merge Dynam­icProxy with Dic­tio­naryAdapter and (parts of) Core into a sin­gle assem­bly; Merge Wind­sor and Micro­Ker­nel (and other parts of Core) into an other assem­bly. With that you get from 5 assem­blies to 2.

That reduces Castle’s inter­nal depen­den­cies, but what about other projects that depend on it? After the recent release, we started a log of break­ing changes, along with brief expla­na­tion and sug­gested upgrade paths, to make it eas­ier for appli­ca­tions and frame­works to upgrade. We have yet to see how this plays out.

What else can be done?

This is the actual ques­tion to you? What do you think can be done, for Cas­tle specif­i­cally, but more broadly – for entire .NET OSS ecosys­tems to make prob­lems Paul men­tioned go away, or at least make them eas­ier to sort out?

Posted in Castle, Design, Open Source, Tools | 6 Comments »

How to contribute to open source

Sunday, September 6th, 2009

Once in a while I talk to some­one who sais some­thing like this: “I love open source, espe­cially project X – I would love to con­tribute back, but I don’t know how”. There are dif­fer­ent vari­a­tions. “I am not a pro­gram­mer”, “I don’t under­stand the code – it’s so vast”, “I wouldn’t know how to sub­mit these patch-things they ask for” etc.

To help these peo­ple I decided to cre­ate a small (seri­ously – 3 posts, exclud­ing this one) series about con­tribut­ing to open source projects. I hope this will help more peo­ple get involved as they real­ize how much they can help with lit­tle effort.

I intend to do the following:

  • How to con­tribute to open source with­out writ­ing a sin­gle line of code
  • How to con­tribute code to open source project with­out know­ing its inner workings
  • How to con­tribute code to open source – report­ing bugs and cre­at­ing patches

This should cover most of the ground to get peo­ple started. The topic itself is cer­tainly much broader, and one could write a whole book about it, but why waste time for that, when there’s some great open source wait­ing for your contribution!

Posted in General, Open Source | 1 Comment »