I stumbled across PostSharp, an open source project to provide aspect-oriented programming(AOP) to .NET developers.
Of interest too are some additions to PostSharp:
Yesterday the June 2008 CTP of Microsoft Parallel Extensions to .NET Framework 3.5 was released. There is also an MSDN developer centre. I watched a 20 minute video which walked through some of the samples - worth a look. The presenter (Daniel Moth - "the Moth") said that they are focused on the API surface at this stage in the lifecyle and not much has been done on performance. Look in the download at the chm doco for some good ideas about how software can start to take advantage of multi-cores.
So long since the last post :-(
Have come across quite a few interesting posts recently.
The VS/VSTS/TFS 2008 SP1 beta seems to signal a new direction for Microsoft. It hardly fits the criteria for a SP, and if they continue this approach, I think it will mean significant updates at least every year. It also explains why Rosario has been delayed.
A few posts in the unit testing / mock area:-
"Alachisoft has released NCache Express 3.2, a FREE in-memory distributed object cache for .NET. NCache Express lets you scale up your .NET application performance by caching frequently used application data close-by and reducing expensive database trips. NCache Express is totally FREE to use and is not a trial version." More
There are some WPF videos around SP1. I watched the David Teitlebaum one which showed some cool effects - but just got to work out where we could use them!
Some good ideas re the use of ReSharper.
Good to see that Unity (1.1) is now a part of EntLib 4.0, which indicates a good future for it when coupled with Krzysztof Cwalina's article on MEF (Managed Extensibility Framework) which implied that Unity will morph in the .NET framework after it's passed the test of time".
There's also been a good series on how Microsoft Dev Division uses Team System. Latest post is chapter 7 on risk.
Scott Guthrie has announced that Microsoft will be releasing commented source code for some .NET 3.5 framework libraries here.
Jezza is one of the thought leaders in Microsoft about Software Factories. I thoroughly recommend his blog to anyone interested.
His latest post is about Software Factory verticalisation, ie how can we leverage off the essentially horizontal (cross-cutting) software factories that Microsoft P&P are developing, to specialise them for our particular (and narrower focussed) domain?
His post raises some interesting related issues about the practical application of software factories.
The current crop of horizontal factories - SCSF(Smart Client Software Factory), WCSF(Web Client Software Factory), WSSF(Web Service Software Factory) - are all general purpose / cross cutting. They should provide a way of insulating / abstracting from the physical solution domain, eg .NET 2.0/3.0/3.5, etc.
The issue I'm raising is - how do we future proof our factory developed applications, to allow us to take advantage of ever changing technologies, and allow us to "easily" upgrade to the next version of our vertical or horizontal factories.
Without strategies to handle this, are we destined to have to rewrite / refresh our apps / products every few years ? If we accept this - then it's legacy / obsolescence by design, and we loose many / most of the gains we have made by using a software factory approach.
It seems to me that the answer lies with modelling (via DSLs) so that our IP assets are maximised in (DSL) models and other factory assests, and we "just" have to update the mappings to lower levels when they change.
But with the factory approach spanning vertical factories to horizontal factories to physical solutions, this introduces some interesting configuration management and upgrade challenges.
Also "interesting" is the choice of which horizontal factory (from Microsoft P&P) you should use. For our smart client product line, we were planning to use the SCSF, but depending on who you talk to - development of it has either stopped / slowed to a crawl, and the supposed replacement is Acropolis. I don't see any evidence with Acropolis that they are taking a software factory approach. This is indeed a challenge for those of us who would like to embark on a software factory / product line approach.
As part of the Extensibility implementation we have been looking into a bug in the last day or so, related to Icon images in a treeview. The bug is that in Windows XP the icon images didn't appear, in Vista they did, for the same EXE. The odd part? It was working in both until just recently.
So what happened?
As part of doing a review, and some related bug fixes, I noticed that the visual styles weren't enabled, so I 'fixed' them. Now I'm running Windows Vista, so simply putting Application.EnableVisualStyles before Application.Run worked beautifully. You might ask why this hadn't been done earlier, well it had, sort of. The application starts multiple threads, with a message loop and form on each, there are reasons for this that I won't go into here. The bug I fixed was when I notice we'd only called Application.EnableVisualStyles on the initial thread, and I added the call into each new thread.
As I said, this worked swimmingly for me, but a while later when the other Devs got the latest code (they're using Windows XP) things got interesting. There is a treeview on the form and it's icon had disappeared! But only on the Windows XP machines?? I tried running the EXE on my Vista machine and the images appeared, so it's obviously a runtime issue and not a compile time one.
The answer, a lesson learned long ago but unfortunately forgotten. Under Windows XP the Application.EnableVisualStyles exhibits some interesting behaviour. I'm not going to try to explain why, I'll defer to those more knowledgeable in this area. I found a Code Project article and an old but informative blog that I think do a good job of explaining the issue.
Note that as part of the fix for this you must call Application.EnableVisualStyles and Application.DoEvents BEFORE you call the constructor for the form. This is due to the message loop and is explained in the blog article referred to above.
Rico Mariani was recently appointed chief architect of Visual Studio. He's been blogging a lot about .NET performance over the last few years. His latest entry points to a talk he gave to Gamefest 2007 with the same title as this blog entry.
"This talk is for those who want to understand the inescapable performance consequences of the managed programming method: the things you cannot avoid and the things you can. The presentation explains those few characteristics of managed code, such as array bounds checking, application domain isolation, and write barriers, that profoundly affect the code generation at a primitive level. Comparing and contrasting the consequences for the .NET Compact Framework and the classic .NET runtime, the talk explains the reasons for these overheads, the benefits they provide, and what practices minimize the associated costs. Additionally, we discuss some commonly occurring costs, such as boxing, that aren't inherent to all managed code, and we offer some tips for minimizing those costs."
Also on his blog is a link to various articles on performance that he's written.
