Quick mail. If you want to use the rake-stuff that I've built, I created a project and a tutorial on how to integrate it into your projects at https://github.com/haf/Castle.Releases
On Apr 26, 2:49 pm, Roelof Blom <[email protected]> wrote: > IMHO MSBuild is not really suitable for creating nuget, packaging, releasing > to SF etc. > As these tasks are only executed by the TeamCity server and/or committers > rake with Albacore will make this a lot easier and workable. > > There are of course ways to get MSBuild to do this (like creating a nuget > package with > NuGet.MSBuild<http://biasecurities.com/blog/2010/creating-nuget-packages-with-teamc...>) > it's really throwing in more and more XML for no apparent benefit. > > A combination of "front-end" MSBuild scripts like we have now and a > "back-end" rake script looks best to me. > This way there's no barrier to open and build our projects locally like > they can now, and the rest can just script and automate anything that comes > to mind with a tool well suited for it. > > -- Roelof. > > 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" > > ... > > read more » -- 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.
