This project is read-only.


Apr 15, 2010 at 2:49 PM


Have you guys have any thoughts on supporting Silverlight in the future?


Asger Hallas

Apr 19, 2010 at 3:18 PM


Thank you for writing

Personally, I have given this absolutely no thought until you asked ;)

However, this is not due to any kind of aversion on my part, but simply because so far, I have been too busy with other things to even start playing with Silverlight at all.

I can definitely see the attraction in supporting AutoFixture on Silverlight as well, but my priorities are currently elsewhere. However, if you or someone else feel like driving this work forward, it would be a great contribution. I have just created [workitem:4196] to keep track of it.

Tharnk you

Mark Seemann

Apr 22, 2010 at 10:05 PM
Edited Apr 22, 2010 at 10:07 PM
Hi Mark I thought so, not seeing it mentioned anywhere. I can see pretty good use for it in some of our current projects. I suddenly feel very limited without it :) I have no idea, what so ever, what kind effort it will take, but I will look into it and follow up! // Asger Hallas EDIT: Line breaks does not seem to work when posting from Chrome :)
Apr 23, 2010 at 3:36 PM

My initial, totally uninformed, assumption is that this might not be particularly difficult.

At a high level, it ought to simply be a question of compiling the source with the SL compiler. If there are any BCL types in use that are not available in SL, we need to figure out if there are alternatives, or if we can leave something out from the SL distribution.

I recently took a brief look at the Castle Windsor source, and it has some conditional compilation symbols defined to leave out certain things when compiling for SL, and I presume we would be able to do the same for AutoFixture if need be.

Apr 27, 2010 at 2:03 PM

Sorry for the late reply.

I guess that will be the way to go. I believe it will be a good idea to set up a build script to switch between compilers. It doesn't look like, there's such a thing at the moment?

Doing a quick test points towards "only" two problems: 

1. The SerializableAttribute is not available

2. MemberInfo has an internal constructor, strangely enough

Number one should be pretty easy to change conditionally.

As for number two, I don't know exactly what the purpose of UnexpectedInfo is. And how bad it would be, not to use it? :)



May 1, 2010 at 8:45 AM

There's no build script at the moment, but I'm considering moving the file structure around a bit. Adding a build script would be a small addition to that.

Concerning the two issues you reported:

The SerializableAttribute just sits on the custom Exception because it's good practice to make exceptions serializable to support cross-AppDomain scenarios. No part of AutoFixture explicitly relies on it, so we can just surround it with conditional compilation directives.

UnexpectedInfo was always a hack, and something we've more or less already moved away from. AFAIR, it's only really being used in Fixture and Fixture<T>, and both of these classes are marked as Obsolete. We ought to exclude those from any Silverlight release we might do, so I think we can get rid of UnexpectedInfo as well in that case.

It looks like AutoFixture for SilverLight would be quite possible :)