Programming .NET Components

Juval Lowy

Mentioned 4

'Programming .NET Components', second edition, updated to cover .NET 2.0., introduces the Microsoft .NET Framework for building components on Windows platforms. From its many lessons, tips, and guidelines, readers will learn how to use the .NET Framework to program reusable, maintainable, and robust components.

More on

Mentioned in questions and answers.

My organization has begun slowly repurposing itself to a less product-oriented business model and more contract-oriented business model over the last year or two. During the past year, I was shifted into the new contracting business to help put out fires and fill orders. While the year as a whole was profitable (and therefore, by at least one measure, successful, we had a couple projects that really dinged our numbers for the year back around June.

I was talking with my manager before the Christmas holiday, and he mentioned that, while he doesn't like the term "post-mortem" (I have no idea what's wrong with the term, any business folks or managers out there know?), he did want to hold a meeting sometime mid-January where the entire contract group would review the year and try to figure out what went right, what went wrong, and what initiatives we can perform to try to improve profitability.

For various reasons (I'll go into more detail if it's requested), I believe that one thing our team, and indeed the organization as a whole, would benefit from is some form of organized code-sharing. The same things get done again and again by different people and they end up getting done (and broken) in different ways. I'd like to at least establish a repository where people can grab code that performs a certain task and include (or, realistically, copy/paste) that code in their own projects.

What should I propose as a workable common source repository for a team of at least 10-12 full-time devs, plus anywhere from 5-50 (very) part time developers who are temporarily loaned to the contract group for specialized work?

The answer required some cultural information for any chance at a reasonable answer, so I'll provide it here, along with some of my thoughts on the topic:

  1. Developers will not be forced to use this repository. The barrier to entry must be as low as possible to encourage participation, or it will be ignored. Sadly, this means that anything which requires an additional software client to be installed and run will likely fail. ClickOnce deployment's about as close as we can get, and that's awfully iffy.
  2. We are a risk-averse, Microsoft shop. I may be able to sell open-source solutions, but they'll be looked upon with suspicion. All devs have VSS, the corporate director has declared that VSTS is not viable going forward. If it isn't too difficult a setup and the license is liberal, I could still try to ninja a VSTS server into the lab.
  3. Some of my fellow devs care about writing quality, reliable software, some don't. I'd like to protect any shared code written by those who care from those who don't. Common configuration management practices (like checking out code while it's being worked on) are completely ignored by at least a fifth of my colleagues on the contract team.
  4. We're better at writing processes than following them. I will pretty much have to have some form of written process to be able to sell this to my manager. I believe it will have to be lightweight, flexible, and enforced by the tools to be remotely relevant because my manager is the only person who will ever read it.
  5. Don't assume best practices. I would very much like to include things like mandatory code reviews to enforce use of static analysis tools (FxCop, StyleCop) on common code. This raises the bar, however, because no such practices are currently performed in a consistent manner.

I will be happy to provide any additional requested information. :)

EDIT: (Responsing to questions)

Perhaps contracting isn't the correct term. We absolutely own our own code assets. A significant part of the business model on paper (though not, yet, in practice) is that we own the code/projects we write and we can re-sell them to other customers. Our projects typically take the form of adding some special functionality to one of the company's many existing software products.

From the sounds of it you have a opportunity during the "post-mortem"to present some solutions. I would create a presentation outlining your ideas and present them at this meeting. Before that I would recommend that you set up some solutions and demonstrate it during your presentation. Some things to do -

  1. Evangelize component based programming (A good read is Programming .NET Components - Jubal Lowy). Advocate the DRY (Don't Repeat Yourself) principle of coding.

  2. Set up a central common location in you repository for all your re-usable code libraries. This should have the reference implementation of your re-usable code library.

  3. Make it easy for people to use your code libraries by providing project templates for common scenarios with the code libraries already baked in. This way your colleagues will have a consistent template to work from. You can leverage the VS.NET project template capabilities to this - check out the following links VSX Project System (VS.Net 2008), Code Project article on creating Project Templates

  4. Use a build automation tool like MSBuild (which is bundled in VS2005 and up) to copy over just the components needed for a particular project. Make this part of your build setup in the IDE (VS.NET 2005 and up have nifty ways to set up pre-compile and post-compile tasks using MSBuild)

  5. I know there is resistance for open source solutions but I would still recommend setting up and using a continuous automation system like CruiseControl.NET so that you can leverage it to compile and test your projects on a regular basis from a central repository where the re-usable code library is maintained. This way any changes to the code library can be quickly checked to make sure it does not break anything, It also helps bring out version issues with the various projects.

If you can set this up on a machine and show it during your post-mortem as part of the steps that can be taken to improve, you should get better buy since you are showing something already working that can be scaled up easily.

Hope this helps and best of luck with your evangelism :-)

I came across this set of frameworks recently called the Chuck Norris Frameworks - They are available on NuGet at . You should definitely check them out, as they have some nice templates for your ASP.NET projects. Also definitely checkout Nuget.

Can anybody reccomend books or other online resources for MultiThreaded Windows Forms in C# ? I am mostly interested to learn more about this topic especially in the context of a GUI application that sends messages and listens in the background for responses from the server.

Many Thanks, MK

I'd second CLR via C#, but Concurrent Programming on Windows by Joe Duffy does multithreading and concurrency in much more depth if that's what you're looking for.

EDIT: Windows Forms 2.0 Programming by Chris Sells also has coverage of the topic and is a very good (and readable) general WinForms book if you dont already have one

Bill Wagner's More Effective C#: 50 Specific Ways to Improve Your C# addresses this topic, along with many other useful ones.

I don't know if there are any specific books on WinForms and multithreading. There are books which discuss the .NET Asynchronous Programming Model, which is used considerably in WinForms and WPF programming.

Try Programming .NET Components by Juval Louwy (OReilly Press) as well as CLR via C# by Jeffrey Richter (Microsoft Press). That ought to get you started.

We are working in a project where there will be a shared configuration which needs to be accessed by multiple parts of the solution.

The team responsible for the Config module implemented an interface which consists only of 2 classes. 2 classes that are responsible for getting, caching and providing the particular values (via properties).

I feel that this is a bad design, in my opinion, it would be better to define all the config values one may access via the interface, but not actual classes that implement this behaviour.

In my opinion, for something like getting config values, it would be more logical to give an interface that shows me what values I will be able to access, but not a class (which implementation e.g. the properties is not controlled by the interface).

-edit- The Interface looks like this:

public interface IConfigurationResolver
    GeneralConfiguration GetGeneralConfiguration(string Id);
    SpecificConfiguration GetSpecificConfiguration(string Id);

It is implemented by one class. What I meant is that this interfaces really just defines two classes that are each responsible for providing the configuration values, whereas I think it would be better if the interface did not care about such details and should provide the config values itself

These are very experienced developers, whereas I am not, so what is your stand on this?

There are quite a few things going on here…

The reference of non-abstract classes in the IConfigurationResolver interface is a code smell, violating the “program to an interface, not an implementation” principal (What does it mean to "program to an interface"?).

Your desire to explicitly reveal the configuration parameters through an interface is a good one, and is in accordance with the notion of an Intention Revealing Interface (as discussed in Eric Evans’ Domain Driven Design).

However, if you have a great many configuration values, this interface could end up having a great many methods on it. This is where knowledge of your domain comes in – the decomposition of the “universe of configurations” in to a set of cohesive interfaces, each of which are used to configure a separate aspect of your application is a skill in itself, and relates to the ‘I’ in SOLID. Lowy’s Programming .NET components discusses the issue of contract re-factoring, and as a rough guide suggests aiming for 3-5 methods per interface.

I’m guessing the desire to "re-factor the configurations" is the root of the existence of the two methods on the current interface.

We are working on standardizing our Bugzilla application across all projects. The default installation has bugs grouped into Products which have Components and Versions.

We are united in our definitions of Product and Version but there is still some confusion/discussion/argument about what constitutes a Component.

How would you define a Component as far as it relates to classifying bugs in a project?

A good definition that will serve your purpose.