Extension Properties? (DotNet)

I was just wondering...

Its been allready a while since extension methods have been introduced. Hence, many of us hardly actively remember not having those methods available to us.

But I was wondering:

• Where are the extension properties?
• Do extension methods go against the Object Orentation principles?

What do you think?

Quote about success and failure

Success is failure turned inside out....

For me, true success is about failing, failing, failing and yet sticking to it. Making? No demanding success. Its oke to rest but not to quit....

Stay focused, in the end you will succeed...

Microsoft WCF Tools (Test, Configure, UI)

With SOA and Web v2.0 everything is about services.

As you know for Microsoft the current strategic tool of choice for services is WCF. However, testing / configuring with WCF, among things can be tricky. Knowing what tool to use in what situation is essential. As it turns out still not everybody knows about the currently available tools from Microsoft, so just as a reminer below a list:

• ServiceModel Metadata Utility Tool (Svcutil.exe): Generates service model code from metadata documents and metadata documents from service model code;
• Find Private Key Tool (FindPrivateKey.exe): Retrieves the private key from a specified store.
• ServiceModel Registration Tool (ServiceModelReg.exe): Manages the registration and un-registration of ServiceModel on a single machine. COM+
• Service Model Configuration Tool (ComSvcConfig.exe): Configures COM+ interfaces to be exposed as Web services.
• Configuration Editor Tool (SvcConfigEditor.exe): Creates and modifies configuration settings for WCF services.
• Service Trace Viewer Tool (SvcTraceViewer.exe): Helps you view, group, and filter trace messages so that you can diagnose, repair, and verify issues with WCF services.
• WS-AtomicTransaction Configuration Utility (wsatConfig.exe): Configures basic WS-AtomicTransaction support settings using a command line tool.
• WS-AtomicTransaction Configuration MMC Snap-in: Configures basic WS-AtomicTransaction support settings using a MMC snap-in.
• WorkFlow Service Registration Tool (WFServicesReg.exe): Registers a Windows Workflow service.
• WCF Service Auto Host: Hosts WCF services contained in libraries (*.dll) files
• WCF Test Client: GUI tool that allows you to input parameters of arbitrary types, submit that input to the service, and view the response the service sends back.

You can find all information about there tools here.

There are also a few Debugger Visualizers for WCF available aswell:
http://codeplex.com/WCFVisualizer

Be aware though, Oslo is coming up about to change this big time!

Happy Serviceing!

The Business-IT-Gap has a face

With all the current hypes, just think about the Architecture, SOA and SaaS hype, you might think that agility, stability and interoperability are goals in itself. That they are specific magical ingredients recently discovered about to solve all IT related problems. This would not be an unlogical conclusion. After all, that's what is being promised you will need and get an agile business because that is what everybody needs.


Is it not? No, not at all!

In fact you just met the "Business-IT-Gap" in person. It might be the manager asking a developer for an application that should (obviously) be flexible and stable. Or it might be a sales person or consultant explaining a client that they really need to go for a SOA-solution for agility reasons. Either way you are actually physically facing a (e.g.: talking/listening to) person embodying the Business-IT-Gap.


Really? Explain!

The whole reason why the Business-IT-Gap exists is because managers have lacked to provide enough guidance about what kind of flexibility and interopability and the dagree of stability is that was needed (a responsibility now being hijacked by people calling themselves Architects).


Lacking this guidance resulted in systems lacking flexibility or the wrong kind of flexibility (thus maintainability) and interoperability. Moreover, because every developer has its own personal view on the type of flexibility needed, changes are that what is flexible in one application is fixed in another. Thus in fact lacking this guidance cannibalized the overall investments in flexibility. Believe me this is not theoretically speaking, this is what I see day in and out! I can't believe nobody else notices this...


So what should I do?

Of course, it's not only you. It's the whole branch! Developers should demand more guidance. Sales people and consultants should not propagate agility, interoperability and stability etc. "pur sang". They should explain that it is about Just Enough and about Just Right and that divers from situation to situation and company to company. You just can't and don't want to be totally agile either given a solution or given an total enterprise. It's about finding the right balance between what can be fixed and what should be flexible. Because flexibility comes with a big cost that can only be returned (roi) if it will be used sooner or later. Just think about architecting a house. Realizing all your dreams and whishes (read: requirements) in a totally agile structure would have you end up with something crazy like a hyper expensive stretchable balloon!

But now that you know, you can and should close the gap by asking the right questions and demanding a reasonable answer!


Happy closing the gap!

Compare Assemblies (ALM)

To get your build and release procedures right you need to know and inform about what has been changed in this release compared to the last (major)release.

As far as I know there are three tools that can be used to compare assembly versions:

• Microsoft's LibCheck which might be incorporated into your build server to have a document generated with your release that lists all the differences; This application outputs a xml-file with the differences;
• For ad-hoc investigation you should you ndepend;
• For simplicity you might use the free opensource Framework Design Studio; Which can also be incorperated into your build server using the "fxdiff.exe" found in the install folder. This application gives you a visual SourceSafe-like comparison.

I recommend using nDepend today! If you are not using it allready.

Happy comparing!

P.S. If you can't find the download for the Framework Design Studio click here.

Welcome.doc (Project Management)

Every now and then a new person will join the project. It maybe because somebody got sick or will go on a holiday, because a specialist is hired for a specific task or because we want to speed up things. What ever the reason the same questions are asked over and over again:

• What database do we use and where is it?
• What servers are do we use?
• What does the develop / test / production environment look like?
• Do we use SourceSafe?
• What version of Visual Studio do we use?
• Etc. etc

Its my experience, that the first time someone joins the project is the perfect moment to write a "Welcome.doc" - document. Next time somebody joins the project you are more then prepared. I always ask the new person to write them down which I then review.

A typicle "Welcome.doc" document for me looks like this:


Brief introduction (1 page)

• Vision: it is mission ciritical and why?
• Basic description of the functionality;
• Logical position of the application;
• Main technologies used;

Meet the application (Chapter 1)

• Size and complexity;
• Basic architecture;

Meet the users (Chapter 2)

• Grapphical context diagram (users versus elementary use cases);
• Main usescases and a brief description;

Logical System Description (Chapter 3)

• Logical parts;
• Logical main process (value chain);

How we develop (Chapter 4)

• Tooling;
• Enviroment;
• Known shortages;
• Proces (preperation, execution, finilization);

How we test (Chapter 5)

• Tooling;
• Enviroment;
• Known shortages;
• Proces (preperation, execution, finilization);

How we release (Chapter 6)

• Tooling;
• Enviroment;
• Known shortages;
• Proces (preperation, execution, finilization);

Daily activities (Chapter 7)

Many projects come with daily activities. This might be to check a log file, build server or to check a dashboard.

First Aid for Production Problems (Chapter 8)

If you join the team its just a matter of time before somebody runs into your office to ask you for your help with something that is thought of a high priority production problem. This chapter describes the basic checks.

Plan to get up and running (Chapter 9)

This chapter describes what to do after reading the "welcome.doc" - document to get you up and running as fast as possible. This might be to make a few "fake" changes and go throught different applications layers, the test procedure and release procedure.

Settings and Locations (Chapter 10)

This chapter describes the main settings (for example a flag in a config file to set debug on or off) and the locations of the main parts like the dashboard, the intranet, certain folders on the network where tooling can be found.

Relevant documents and applications (Chapter 11)

Any other, more in depth, documentation about the current system or referenced applications should be referenced here.

Frequently Asked Questions (Chapter 12)

Frequently asked questions and their answers of course, about this document can be listed in this chapter.

Happy Welcoming!