Hey Jeff, Thanks for the comments, maintaning 1.1 and 2.0 support is key but if you can see a better way then I am all for it. Assuming no one has objections on what Jeff is proposing then I'd like to work this in. If SVN is still playing up then can you send me your patches/changed files for this.
Andy On 12/27/06, Jeff Brown <[EMAIL PROTECTED]> wrote:
Yup, I'm aware of the compilation strategy and its reasons but I disagree. The crux of it is that it is highly unlikely for a person to be using both the 1.1 and 2.0 versions at the same time within the same projects. Thus distributing MbUnit binaries separately for 1.1 and 2.0would probably not cause much fuss in the end. It might even simplify matters as running config files would not need to be edited anymore. Moreover it would open up avenues for extension of the core framework that are currently barred due to the requirement that it be compiled for 1.1only. In effect, .Net 2.0 is not treated as a first class citizen and it shows plainly. Several other projects are distributed in that fashion including NUnit. In any case, it probably doesn't make much difference for the MbUnit 2.xline. The 3.x line may be another matter altogether. Jeff. ------------------------------ *From:* [email protected] [mailto:[EMAIL PROTECTED] *On Behalf Of *Andrew Stopford *Sent:* Saturday, December 23, 2006 5:08 AM *To:* [email protected] *Subject:* MbUnit Re: RollBack on .net 2.0 Hi Jeff, Everyone that uses MbUnit has variances in what their systems support and as such its important that MbUnit supports 1.1 and 2.0 for the majority of features. MbUnit runs on either 1.1 or 2.0 with only changes to runner config files required, no need to branch at for 1.1 or 2.0 it all runs the same. The reason for a 2.0 assembly is that it allows folks that are using 2.0 a chance to make use of .NET framework features that are related to that version, such as generics etc. The compile process compiles everything bar the 2.0 framework assembly and msbuild assembly in 1.1 using MSBee, those last two are compiled using 2.0. I do think that this model is pretty clean and allows for 1.1 and 2.0 support with very little user interferance and has no need to introduce further technical issues. Andy On 12/22/06, Jeff Brown <[EMAIL PROTECTED]> wrote: > > > Why not just use conditional compilation? Any reason someone would want > to use the .Net 1.1 version of RollBack with .Net 2.0? > > In fact, this goes for MbUnit in general. Maintaining completely > distinct .Net 1.x and 2.x (and 3.x) assemblies is going to be a pain for > developers and users. For instance, we end up having to fork Assertion > classes by version. Much easier to just conditionally compile the > framework. > > Jeff. > > -----Original Message----- > From: [email protected] [mailto: [EMAIL PROTECTED] > On Behalf Of Ben Hall > Sent: Thursday, December 21, 2006 5:05 AM > To: [email protected] > Subject: MbUnit Re: RollBack on .net 2.0 > > > I think (thinking back to the Framework Design Guidelines book) it > should be RollBack2Attribute as Attribute can get dropped.....i think > :) > > On 21/12/06, Andrew Stopford < [EMAIL PROTECTED]> wrote: > > The original was RollbackAttribute > > > > I think I prefer RollBack2Attribute now you mention it :) > > > > Andy > > > > On 12/21/06, Andrew Stopford <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > On 12/21/06, Jamie Cansdale < [EMAIL PROTECTED] > wrote: > > > > > > > > > [RollBackAttribute2] > > > > > > > > > Any reason why this isn't [RollBack2Attribute] or [RollBack2] ? > > > > > > > > Jamie. > > > > > > > > > > > > On 12/21/06, Andrew Stopford <[EMAIL PROTECTED]> wrote: > > > > > Hi Folks, > > > > > > > > > > As of MbUnit 2.4.112 the code from Cathal Connolly and Todd > > > > > Menier for > > a > > > > > rollback using .NET 2.0 has been included in the > > > > > MbUnit.Framework.2.0 assembly. > > > > > > > > > > As MbUnit.Framework.1.1 will be folded into MbUnit.Framework to > > > > > make > > use of > > > > > this you will need to referance the MbUnit.Framework.2.0 > > > > > assembly and > > use > > > > > > > > > > using MbUnit.Framework > > > > > > > > > > and then > > > > > > > > > > [RollBackAttribute2] > > > > > pivate void TestSomething() > > > > > > > > > > rather than > > > > > > > > > > [RollBackAttribute] > > > > > pivate void TestSomething() > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > On 12/1/06, toddm < [EMAIL PROTECTED] > wrote: > > > > > > > > > > > > Thanks cathal, this works great, and is a much-needed update! > > > > > > I took what you did and was able to reduce the code quite a > > > > > > bit, so I > > thought > > > > > > I'd share. This should be functionally equivalant: > > > > > > > > > > > > > > > > > > [AttributeUsage( AttributeTargets.Method , AllowMultiple = > > > > > > false, Inherited = true)] public sealed class > > > > > > RollBackAttribute : DecoratorPatternAttribute { > > > > > > public override IRunInvoker GetInvoker(IRunInvoker > invoker) > > > > > > { > > > > > > return new RollBackRunInvoker(invoker); > > > > > > } > > > > > > > > > > > > private class RollBackRunInvoker : DecoratorRunInvoker > > > > > > { > > > > > > public RollBackRunInvoker(IRunInvoker invoker) > : > > > > > base(invoker) {} > > > > > > > > > > > > public override object Execute(object o, IList > args) > > > > > > { > > > > > > using (TransactionScope scope = new > > > > > > > > TransactionScope(TransactionScopeOption.RequiresNew )) > > > > > > { > > > > > > return > > base.Invoker.Execute(o, args); > > > > > > } > > > > > > } > > > > > > } > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MbUnit.User" 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/MbUnitUser?hl=en -~----------~----~----~----~------~----~------~--~---
