+1. Probably we should have a castle.project.targets file with most of this customizations, so that adding a few properties and including that targets file would convert a project to the new build scheme (DRY).
I think all the tools we need (git, nuget, etc..) have command-line interfaces that can achieve what we need from msbuild. Having refreshed a task wrapper project for NUnit myself ( https://github.com/monoman/MSBuild.NUnit), I think it normally doesn't "pay the costs" to create specific msbuild tasks, as csproj/msbuild tweaking is normally left to more hardcore guys which feel fine just 'exec'ing a command line tool, thus having full-control of the tool features. Just some ramblings from my experience on some other large .NET projects. Rafael "Monoman" Teixeira --------------------------------------- "The most exciting phrase to hear in science, the one that heralds new discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...'" Isaac Asimov US science fiction novelist & scholar (1920 - 1992) 2011/4/25 Krzysztof Koźmic <[email protected]> > I haven't looked beyond putting Nuget package for Windsor 2.5.3 out, > something that was frequently requested. > > I would *love* to have the release process automated (to a point where I > git push to a new tag and our TeamCity recognizes that, and runs a release > build that does everything, including release packaging, releasing to SF, > nuget and OW, branching (if new branch is needed, that is it's not a point > point release and few other things I forgot, like updating the website in > all 3 places.)) > > I *strongly* prefer giving MsBuild a fair shot before trying any other > build solution, mostly because MsBuild is out of the box, it's .NET and many > developers will flat refuse to install Ruby in order to build a .NET > project. > > I think the scripts we have are really well and cleanly written and while > I'm nowhere near as proficient at working with them as Roelof is, I've been > able to tweak them on several occasions, same as I'm sure everyone else on > the team would be. > > This however reminds me of another problem I've had, and we'll continue > having, that is keeping consistency in build scripts among projects. > I've mostly worked with Core and Windsor and all changes and tweaks > introduced in one project had to be manually copied to the other one. As we > have many more projects I'm sure trying to deploy changes to build process > all across the board would be nothing short of a nightmare. > > Can we please consider some options for automated sharing the build files > among all of our projects so that we only change things once and that change > gets propagated to every project? > > I think it might also be beneficial to have a wiki page that > a) documents how our build works and how it should be used > b) documents customizations we've made to .csproj files so that it's easy > to add a new project and get it to work with the build > > Krzysztof > > > On 25/04/2011 7:49 PM, John Simons wrote: > > I would much rather use rake then msbulid. > No offence to Roelof but currently I think the only person that can > maintain those scripts is him and I don't believe this is a good situation. > I think Krzysztof is trying to hook up nuget and ow to our build + > automate most of it, how is that going? Is msbuild working for this? > > Cheers, John > > On 25/04/2011, at 5:36, Henry Conceição <[email protected]> wrote: > > About the build: I don't like the ideia of obligating everyone to have > ruby + rake in order to build the tx stuff. Probably we will restore > the msbuild and get rid of the rake scripts when we merge the changes > on the master repo. > > On the 3.5 matter: At least for me, we can drop de support for it. > > > > Cheers, > Henry Conceição > > > > On Sat, Apr 23, 2011 at 12:44 PM, Henrik Feldt <[email protected]> wrote: > > Yup, a merge it is. They are merged in my repository now. > > > > > The rest in this letter is about the upcoming alpha. > > > > > Docs: > > > I have added docs to the wiki as well on my repo. > > > > > Building: > > > Both projects have been rewritten, based on the previous ideas. This > > includes using rake for the build – using it makes me about 10 times as > > productive when writing the scripts. > > > > > Versioning: > > > In the rake scripts I have set up build-number versioning like that > > NHibernate uses, so that > > > 100x is alpha > > > 200x is beta > > > 300x is rc > > > 4000 is ga. > > > > > So e.g., currently I’m building 2.9.9.11215 at 3 pm, or 2.9.9.1001 for > the > > first alpha. > > > > > The versioning for private builds uses the day of the year and the hour > as > > the build number. > > > > > Sadly: > > > Right now I’m just working against .Net v4.0. There’s no real problem > > re-targeting 3.5. > > > > > Code contracts: > > > I’ve done both with MS code contracts for good or bad, but only debug > builds > > have the contracts. In my opinion it’s nice for showing intent around > > interfaces. The most prominently used part is that of the static > > verification, the part which doesn’t compile into the assembly. I believe > > they work very well with unit tests as well, as one only tests allowed > > functionality as opposed to disallowed functionality that throws exception. > > > > > People use the debug build with contract assertions or the release build > > without any alterations. > > > > > Alpha TODO: > > > Finish build script for building nuspecs with lib and tools. Perhaps a > > transform file for adding AutoTx and the new NHibernate Facility to a web > > site. Test this out and release 2.9.9 (perhaps). Set up a build server for > > the new rake scripts. Does castle have one that I can use for testing – > > TeamCity? I can create its configs. > > > > > Release 3.0 TODO File Transactions: > > > I’m aiming to spend a few hours on the file transactions before release > to > > fully integrate it with ITxManager, but the non-file transaction parts seem > > OK. > > > > > Release 3.0 TODO Forking: > > > There is also a bit of problems related to continuation passing when > forking > > dependent transactions through the new [Transaction(Fork=true)] > > functionality as tasks are awaited on the finalizer thread if exceptions > are > > not observed on the main thread. > > > > > Release 3.1 TODO Retry policies etc: > > > This idea is something I’d like to investigate: possibly retrying failed > > transactions through the transaction interceptor. Also, creating a > > IHandlerSelector for choosing transient lifestyle components if in no > > ambient transaction. > > > > > Cheers > > > Henrik > > > > > From: [email protected] > > [mailto:[email protected]<[email protected]>] > On Behalf Of Krzysztof Kozmic > > Sent: den 15 november 2010 02:30 > > To: [email protected] > > Subject: Re: Castle.Services.Transaction + Castle.Windsor? > > > > > Henrik, > > > What's the status of this? Did you go ahead with the merge? Do you still > > plan to? > > > From another department - would you care to have a look at the > documentation > > and expand it to fully cover all functionality of the facility? > > http://stw.castleproject.org/Windsor.ATM-Facility.ashx > > > Krzysztof > > > On 23/09/2010 8:52 PM, Henrik Feldt wrote: > > > Hello everyone, > > > > > I’m considering merging the code of Castle.Services.Transaction with > > Castle.Facilities.AutomaticTransactionManagement/AutoTX. This would > > introduce a dependency on Castle.Windsor for Castle.Services.Transaction. > > (Another way of saying it is that the IoC-container would be required for > > using the transactions project, which it is not now. However, it could > > simplify versioning/dll-management slightly). > > > > > As of now it is merely a thought: please tell me what your opinions are > on > > whether to merge them or not! > > > > > Kind regards, > > > Henrik > > > -- > > You received this message because you are subscribed to the Google Groups > > "Castle Project Users" group. > > To post to this group, send email to [email protected] > . > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > > http://groups.google.com/group/castle-project-users?hl=en. > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Castle Project Users" group. > > To post to this group, send email to [email protected] > . > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > > http://groups.google.com/group/castle-project-users?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Castle Project Development List" group. > > To post to this group, send email to [email protected] > . > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > > http://groups.google.com/group/castle-project-devel?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Development List" group. > To post to this group, send email to [email protected] > . > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/castle-project-devel?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Development List" group. > To post to this group, send email to [email protected] > . > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/castle-project-devel?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Development List" group. > To post to this group, send email to [email protected] > . > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/castle-project-devel?hl=en. > -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
