Partial source is a good thing?

One of the things advertised in .Net 2 is partial code. In fact, when I tried the Visual Studio C# Express I couldn't figure out how to disable it. Maybe it is just me getting old (or I just don't get it), but I don't like the fact that I don't have access (from VS.Net) to parts of my application code. And I don't like the fact that I might be surprised by some functionality because I don't have one single view of my class. To think of it, I haven't found anywhere partial source is actually useful.

Hopefully it is possible to turn this feature of in the final release of VS.Net 2005.

I have just found the other part in visual studio... but how do I disable it?

Isn't checked Exceptions what we really want?

It has been decided to leave checked Exception out of the .Net framework.
The reason for doing this is that is that it should easier to change versions without recompiling. This to me sounds like late binding. I might as well go back to scripting.

I like checked exceptions because it forces you to design your code beforehand and ensures you that you have considered all error conditions.

More or less I want to keep track of less things in my head and let the compiler check my code for consistensy whereever it is possible.

Further more, when you talk about pluggable architecture, you want your plugins to follow certain rules. This is a perfect scenario where you really really benefit from checked exceptions.

Please put checked exception in .Net!

I have startet to implement Continous Integration on a project.

So far it seems like its going to save us a lot of time. We're using CruiseControl.Net and NAnt to do the actual task. Everytime we check source code in to our versioning tool, it will be compiled, analysed, testet and deployed. Everybody can see the status of the code.

We are now able to instantly know when a checkin courses our tests to fail. On top of that our solution is now automatically installed and our testers can now test how the current code behaves instead of old code. GREAT!

In the future a new release can hopefully be done by anybody because everything is compiled automatically.

Naming interfaces and classes.

When reading these blogs I started to think about the concept of prefixing interfaces with an I. The I is meant to make it clear to the programmer that it is in fact an interface he is using.

http://www.jnsk.se/weblog/posts/iprefix.htm
http://www.bloglines.com/blog/IngoLundberg?id=5

Prefixing interfaces has, as I see it, two disadvantages: First of all it gives the impression that the interface is a secondary thing, and that there must be a more important class behind it.
When you first see IList you wonder; is there a List as well? The fact is that IList is a List and the I only confuses the user. This leads me to my second point. The unexperiensed programmer might have heard that designing your code with interfaces is a good thing. I have seen programs constructed only using classes, and thereafter added interfaces to all classes with the I prefix. The fact is that interfaces do not make much sense if they are not suppossed to be implemented by more than one class.

Hello. This is going to be a technical blog about things in software development I feel like writing about.

I have originally been using Microsoft technology. Then I was using Java for a few years, and now I'm back where I begun.