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]
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]
<mailto:[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
-~----------~----~----~----~------~----~------~--~---
