News bits: Microsoft Empower for ISV, Autofac article and some WPF patterns.

Bit 1: I've recently stumbled upon Microsoft Empower for ISV program. Now, that's a deal - if you are an ISV developing for Microsoft technologies (or commit to deliver such a solution in 2 years) then for $400 per year you can get one MSDN Premium Subscription and for user licenses, up to five licenses to Vista, XP, Office 2003/2007, one server and up to for CALs to servers. The goodness lasts for up to 2 years. I wonder, what's the catch?

Bit 2: Nicholas Blumhardt has published extremely thorough article on Dependency Injection with Autofac. The article is worth checking even if you think yourself to be familiar with this wonderful tool.

Bit 3: This blog post by Bryant Likes is an interesting collection of references to WPF-specific development patterns.

Red Gate and Seeding problems

Red Gate tools are the best for the database management routines (update schema, update data etc).

• 
• 
• 

However they are not flawless (version 6) as I thought before. For some reason after a number of syncs identity seed got messed up in a couple of tables. Fortunately this has been one of the development databases. To fix the issue I had to resort to writing queries by hand:

declare @P1 int
set @P1 = (select max (Oid) from FormValue_Date)
DBCC CHECKIDENT(FormValue_Date, RESEED, @p1)

So, if you using DevExpress XPO and suddenly start getting "Violation of PRIMARY KEY constraint 'PK_Name'. Cannot insert duplicate key in object 'Name'", do not rush to the Support Center. Check identity information first with:

DBCC CHECKIDENT(TableName)

TODOs

• Write about xLim Console UI concept (usable for scripting) that is based on extremely simple (yet powerful) interactive Autofac explorer and reuses modular structure along with ICommand encapsulation
• Review delivered research projects and write series about platform-independent Form layout that could be designed with XtraLayout control and rendered with .NET (Xtra Forms and Win Forms), WCF and Web (basically just the logical extension of the xLim 2 UI approach).
• Check out NServiceBus (could be useful for efficient development of complex distributed systems with the xLim approach).
• Write about painful limitations of XPO-2-Linq.

Just do not leave R# 4.0 EAP home alone.

R# 4.0 EAP is the best thing that we can have right now, but you've got to be really careful about it. Especially, if you have habit of keeping your Visual Studio instances running for days, like I do.

Just today my R# finally ate all free space on his hard drive with logs (7 GBs) then threw an exception in all 3 VS 2008 instances. As if it was not enough, all VS instances crashed after that.

Development seems to evolve quickly when the D.R.Y. principle is enforced

One starts his development career with simple WinForms applications, then gets to the web applications.

80% of projects' functionality is being delivered with controls and code here.

All is well.

But then the project complexity keeps on growing along with the experience. And in order to be able to develop and maintain solutions while having only limited resources at hand, one has to learn patterns, start using IoC and different efficient development techniques, get rid of the repetitive code.

80% of projects' functionality is being delivered with components, services and their configuration here. Coding, obviously, remains, since one still needs to cover 20% with custom code.

All is well.

But then project complexity keeps on growing along with the experience. And in order to be able to develop and maintain complex systems while having only limited resources at hand, one has to learn common business patterns, start using multi-scoped IoCs, do even more efficient stuff, start encapsulating complex inter-component logics into modules to avoid doing repetitive coding and configuration. It all leads to doing more development by configuration instead of development by coding.

80% of projects' functionality is being delivered with modules and packages here. Working with raw components, services and configs, obviously, remains - since one still needs to cover remaining 20%. And 20% of these 20% still require actual coding.

All is well.

But then the project complexity keeps on growing...

Efficient way to deal with the install packages

Do you need a convenient way to extract files from install packages (i.e.: Inno Setup, MSI, Nullsoft etc) without running them (and polluting your system) or resorting to command-line extraction?

Here's the nice tool that I've been using for a couple of years already: Universal Extractor.

What do you do when the IoC container grows big?

Nicholas Blumhardt has just released version 1.1 of his wonderful Autofac IoC container. The details are available at autofac community forum. You can download both .NET 2.0 version and .NET 3.5 version. Note, that .NET 3.5 version is much more powerful because of extension methods and lambda expressions.

And after this milestone there’s some logical transformation of the project on the way.

Autofac users have expressed their concerns of the core IoC growing too heavy because of all the extensions and integrations being developed. Additionally, there’s always some tendency for the core to be tweaked in order to accomplish something with some extensions.

I believe that’s what has happened with the Castle project. It got heavy.

Nick has agreed to isolate the core from the non-BCL integrations and extras and move them to a separate autofac-contrib project. This separate project will have the same continuous integration support and openness to the contributions.

Additionally there is some consideration to streamline and solidify the framework experience around autofac-contrib while keeping up with the principles of efficient development and D.R.Y.

Think of solution structure that has been designed with the framework extensibility in mind. For example, with the ability to get single integration library by just firing of the build script with the required switches. Something like:

go net2 –D:include=”nmock2,nhibernate,startable,coreutils” integrate distrib

Another opportunity being considered is to design integrations/extras with the replace-ability in mind (so that, for example, it would be much easier to replace one ORM with another, while keeping the interfaces the same).

What do you think?