XAML Comments in Attributes.

Sometimes I wish that XML supported comments in attributes instead of just <!—style.

Almost always this is a XAML file that I wish had this.

Today I realized just how silly I was being.

xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"  xmlns:d="http://schemas.microsoft.com/expression/blend/2008"  mc:Ignorable="d"

And now I can just d:Anything=”any comment”.

Sure, I can’t nest my quotes there, but this is good enough for a lot of things.

<Grid d:Purpose=”this is the grid that contains the other grid that contains the things”>…

CodeRush test runner for NUnit25 without NUnit installed.

What path is the Unit Testing\Test Runner options page expecting?
I have NUnit 2.5.9 downloaded from zip file, not installed from MSI and I try these paths and none of them work.
C:\Users\jrwren\Downloads\NUnit-2.5.9.10348
C:\Users\jrwren\Downloads\NUnit-2.5.9.10348\bin
C:\Users\jrwren\Downloads\NUnit-2.5.9.10348\bin\net-2.0
C:\Users\jrwren\Downloads\NUnit-2.5.9.10348\bin\net-2.0\framework

 

I get an error that says
—————————
Error
—————————
Test Provider ‘NUnit25′ can’t find required assemblies in this path
—————————
OK  
—————————
I finally tried C:\Users\jrwren\Downloads\NUnit-2.5.9.10348\bin\net-2.0\lib and it worked.

I didn’t see this documented anywhere. It is now. (here)

Collection Encapsulation is Bunk

I heard someone ask a question about encapsulated collections today and pointed to this blog post http://www.lostechies.com/blogs/jimmy_bogard/archive/2010/03/10/strengthening-your-domain-encapsulated-collections.aspx

I don’t want to comment on the blog post exactly, but I do want to comment on encapsulating collections in general. I’ve struggled with it. For some reason the OO purist in me wants to strong type everything and when it comes down to collections a Collection<T> or List<T> just isn’t good enough. I want to go full FDGL and make MyTypeCollection that extends Collection<T> or implements IList<T> or something of the sort and have all sorts of nice checking and expose only what is needed on MyOtherTypeThatHasACollectionOfMyType.

But what value does this add?

None.

Zero.

Zilch.

Nada.

My years of PHP and Perl before finding the joys of strong and static types taught me that you just use what is at your disposal and you don’t worry about bugs that don’t exist yet. No one (that I ever saw) ever wrote collection types in these languages. We always just used the built in lists and arrays. If an API didn’t support you adding to a list at the wrong time, then things didn’t work and you would read the docs and/or source and find out just what was supported and what was not. I’m guessing things are this way in the Ruby and Python world too.

The idea that encapsulation is good came about because programmers were creating the same bugs over and over again and running into the same problems again and again. These were the bugs and problems that encapsulation could solve. Do you really think a django or rails programmer is going to go make sure that a controller or other consumer of a model cannot accidentally clear a collection of values on that model? Or add to it when the model thinks that it should not be added to? No. Its a waste of time to do these things before it becomes an issue. Its premature optimization to fix a bug that doesn’t exist yet. If you try, you are just writing code for no reason.

Its probably not important to spend hours or days writing it when you can just as easily document it and say "don’t do that." If you have team members who don’t read documentation, you have bigger problems. Better yet, make everyone on the team aware of the code. Work in a shared ownership environment. Solve problems of unintended use by working with people rather than creating extra work to prevent unintended use.

I’m tempted to make some "the state of this collection can never be invalid" types too. Lets promise each other that we won’t spend time on this. Lets solve better problems.

WCF Async Without Changing The Contract

Someone asked a group of people recently about how to prevent overloading a WCF service that gets blocked. It sounded like the WCF service was getting called a lot and this was causing many threads to get created to service all of the requests, but nearly all of those threads were blocked handling some IO requests.

I vaguely recalled something about WCF async and I suggested this person look into that. I even looked up the AsyncPattern=true property and value for the OperationContract attribute, but the person didn’t want to break the contract. I was pretty sure that this change was only a server side change and that it wouldn’t break any contract, but I wasn’t 100% sure.

Today I confirmed that I was right. The generated WSDL does not change when you change your contract from something like this:

[ServiceContract]

public interface IOrderService

{

[OperationContract]

Order[] GetOrders(int numOrders);

}

To something like this:

[ServiceContract]

public interface IOrderService

{

[OperationContract(AsyncPattern=true)]

IAsyncResult BeginGetOrders(int numOrders, AsyncCallback callback, object state);

Order[] EndGetOrders(IAsyncResult result);

}

If you want to convert existing WCF services to server-side async style, you can do so without your clients ever knowing. (There may be a caveat when using a ChannelFactory, see the docs.)

The MSDN docs are pretty good. An overview here http://msdn.microsoft.com/en-us/library/ms730059.aspx some better details here http://msdn.microsoft.com/en-us/library/ms731177.aspx

Dan Rigsby had some blog posts from when these features were rolled out, but beware his examples, he keeps a sync version and an async version, which is not strictly required. http://www.danrigsby.com/blog/index.php/2008/03/26/async-operations-in-wcf-iasyncresult-model-server-side/

Finally, Wenlong Dong’s blog gives great reasons why you would want this and even goes as far as suggesting using the async version of the datareader for async database access. http://blogs.msdn.com/b/wenlong/archive/2009/02/09/scale-wcf-application-better-with-asynchronous-programming.aspx