I would agree that it would simplify things having separate binaries between
the two (along with the configs).   It is an easy statement for me being a
completely 2.0 shop.



Regards,

David Strickland



From: [email protected] [mailto:[EMAIL PROTECTED] On
Behalf Of Jeff Brown
Sent: Wednesday, December 27, 2006 2:23 PM
To: [email protected]
Subject: MbUnit Re: RollBack on .net 2.0



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.0 would 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.1 only.  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.x
line.  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] <mailto:[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 < <mailto:[EMAIL PROTECTED]>
[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);
> > > >                        }
> > > > } > > > > }
> > > > }
> > > >
> > > >
> > > > > >
> > > >
> > >
> > > > > > >
> >
>








<BR


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to