While debugging a managed code batch process today I ran into VS throwing a 'ContextSwitchDeadlock MDA' error. The debugger was attached to several long running process's and towards the end of the cycle VS was reporting this issue. As Mike Stall reports it seems to be caused by the thread running the managed code I am debugging timing out but the unmanaged thread seeing not seeing it as dead. Why the managed code I am running times out in the debugger thread I am not clear about. It seems like that the debugger has a fixed response to all break points that starts at execution time, as each step I am debugging goes off to the database, waits a while and then comes back, it eats into this time. Eventually the debugger thread times out and the ContextSwitchDeadlock error occurs. You can't stop this kind of error (although I do wonder if the time out value on the debugger thread could be adjusted) but you can disable the warning.
Two tips I extracted from this thread is
-
First you don't already have it (Debug - Exceptions) obtain the debug exceptions window (right click tool bar - customize - debug and drag exceptions into the debug menu).
-
Select from Debug - Exceptions - Managed Debugging Assistants and disable ContextSwitchDeadlock.
I had no luck with trying to disable this via reg keys and config files but that is suggested in the MDA help files.
I tried lots of Google time to find the answer to this and failed (my google searching may also suck :) so in trying to tie a Where and GroupBy together in a Linq query I used the following.
var values = from p in tbl_data
where
p.some_other_value == 'hello world'
select p;
var group_values = values.GroupBy(p => p.a_value).ToList();
I've seen lots of queries that place the groupby in the from and but never with a Where, there may be a nicer way of doing it but the above works for me :)
If you have not already done so, check out Jeff's post on changes to make TestFixture optional. As Jeff notes, Jim and Brad took this line in XUnit and after consultation it was decided for MbUnit to support this. Note, it's optional so your existing tests won't break but if refactoring it out makes sense then it is available for you to do so. If you do have any thought's and feelings on this do let us know.
Jeff announced the release of Gallio alpha 3 yesterday, my time constriants at the moment meant I missed blogging Alpha 2 back in March but that release was a massive release in terms of features and the work that Jeff, Julian, Graham, Mark, Ben and the rest of the team have put in.
I have talked about Gallio before but as a re-cap, Gallio is described best on the website "The Gallio Automation Platform is an open, extensible, and neutral system for .NET that provides a common object model, runtime services and tools (such as test runners) that may be leveraged by any number of test frameworks", What does that mean, well unit test frameworks such as xUnit.net, NUnit, Pex and MSTest can plugin into the framework (and Gallio supports them all) or frameworks like MbUnit v3 use it directly. It's runners then use that framework and Gallio has the largest set of runners of any unit test framework to date.
-
GUI (Icarus)
-
Console (Echo)
-
TD.NET
-
R#
-
VSTS
-
CCNet
-
Powershell
-
MSBuild
-
NAnt
The runners them selfs are very rich, those who remember the ZaneBug framework will remember how rich it's GUI was and that is something we have aimed for in Icarus with great use of layouts and display information. So now you can take your framework of choice and reuse them across the Gallio platform.
Related directly to MbUnit is the change to the parameterized testing, this has had some heavy work done in make things a little simpler and far more flexible. With this kind of testing now added to Xunit.net, NUnit and csUnit there are lots of different ways you can go about it, the following is a reprint from Jeff's announcement.
A test can now be parameterized in any of the following ways:
- Adding a method parameter to a test method.
- Adding a generic method parameter to a test method.
- Adding a constructor parameter to a test fixture.
- Adding a field to a test fixture.
- Adding a writable property to a test fixture.
- Adding a generic type parameter to a test fixture.
Correspondingly data-source attributes can be specified on any of the following code elements:
- Test methods.
- Test method parameters.
- Test method generic parameters.
- Test fixture types.
- Test fixture constructors.
- Test fixture constructor parameters.
- Test fixture fields.
- Test fixture properties.
- Test fixture generic parameters.
So there are many choices, but each choice is quite simple.
Here are a few interesting combinations.
A basic "Row"-test.
CHANGE !! - : The [RowTest] attribute is not needed anymore and has been eliminated.
[TestFixture]
public class Fixture
{
[Test]
[Row(3, 4, 5, true)]
[Row(1, 2, 3, false)]
public void Test(int a, int b, int c, bool expectedResult)
{
Assert.AreEqual(expectedResult, Math.IsPythagoreanTriple(a, b, c));
}
}
CHANGE !! - A generic "Type"-test.
Note: The [TypeFixture] attribute is not needed anymore and has been eliminated.
[TestFixture]
[Row(typeof(List<int>))]
[Row(typeof(LinkedList<int>))]
public class Fixture<T> where T : IList<int>, new()
{
[Test]
public void Test()
{
T list = new T();
list.Add(123);
Assert.AreEqual(1, list.Count);
}
}
CHANGE !! - A combinatorial test.
Note: The [CombinatorialTest] attribute is not needed anymore and has been eliminated.
[Test]
public void Test([Column(0, 1)] int a, [Column("a", "b")] string b, [Column(false, true)] bool c)
{
// Test something with the specified combination.
// Will be executed 8 times total.
}
CHANGE!! - A pairwise test.
Only tests all combinations of pairs of values. Can yield a significant reduction in test cases compared to ordinary combinatorial tests while still obtaining great coverage. See also: www.pairwise.org.
[Test, PairwiseJoin]
public void Test([Column(0, 1)] int a, [Column("a", "b")] string b, [Column(false, true)] bool c)
{
// Test something with the specified combination.
// Will be executed only 4 times instead of 8.
}
NEW ! - A CSV data source.
Just one of many external data sources to be implemented.
[Test]
[CsvData(ResourcePath="CsvDataTest.csv", HasHeader=true)]
public void ImplicitlyScopedResourceWithHeader(decimal price, string item)
{
Log.WriteLine("{0}: {1}", item, price);
}
The data itself should be stored in an embedded resource called "CsvDataTest.csv". We just create a file with that name in the same folder as the test class and then set its Build Action property to Embedded Resource in Visual Studio.
Item, Price
Apples, 1.00
Bananas, 1.50
Cookies, 2.00
Note the changes to TypeFixture and CombinatorialTest, also note Factory is not included, if you use this with combinatorial tests I'd like to hear from you. The Pairwise testing is something new to v3 and I'll cover in more detail in a future post. If you have further questions, things you want to see them also let me know.
Please also note that Jeff sat down with Scott Hansleman, Brad Wilson (XUnit.net), Charlie Poole (NUnit) and Roy Osherove to talk about the past and future of unit test frameworks in .NET at the recent ALT.NET event, Jeff does talk about Gallio and it is well worth a listen. I do hope that in the future the discussion thrown open wider to other folks that are central to the topic, such as Jim Newkirk, Peli de Halleux, Manfred Lange and others.
This question seems to get asked a lot, this recent article on codeproject does a decent job of explanation as well as this article from Infragistics Guidisan Todd Snyder.
If I was sum it up very simply, the different is entry point into the pattern.
In MVC the entry point is the controller, if you look at the Microsoft MVC framework for example the controller class is where you bind your view and everything else (model) together.
In MVP mean while the entry point is the view, webforms lends it's self very well to this pattern as you can bind the aspx and your view and use the normal aspx entry point to get at the rest of your patttern (in fact winforms works well on this pattern as well).
Going a bit further
You can break down your view into two, a view and View-extender. The temptation in webforms land in a passive sense of the pattern is hold all sorts of view centric items on the presenter. If you have lots going on in your presenter for your view and you want to keep your view ultra light and passive then use a view extender as a layer between the presenter and view, remember keep your concerns focused and light.
In Presenter-First (a variant of MVP) you can take your first MVP pattern and extend it's presenter to multiple views that also follow the MVP pattern. If there is a degree of data transform needed between the language of the view and the model then this pattern can be useful.
Crazy thought of the day
I wonder if the Microsoft MVC view engine (or MonoRails for that matter) could be readapted to act as entry point. More likely you could redefine aspx files as your own http handler, writing a class to act as the aspx which then appends the view and obtains actions from it.