SyncOrchestrator.Synchronize() Throws COMException When Unit Testing

Thursday, 21 May 2009 18:54:01 UTC

This post describes a particular problem I ran into when working with the Microsoft Sync Framework. Since I found a solution, I'm sharing it here to help others. If you are not having this particular problem, it's quite safe to skip reading the rest of the post :)

While developing a SyncProvider, I wanted to create and execute a series of Integration Tests to drive my development effort. In order to do that, I wrote a simple test that simply created a SyncOrchestrator instance and invoked its Synchronize method.

Running this test gave me this error message:

“Microsoft.Synchronization.SyncException: Retrieving the COM class factory for component with CLSID {A7B3B4EE-925C-4D6C-B007-A4A6A0B09143} failed due to the following error: 80040154. --->  System.Runtime.InteropServices.COMException: Retrieving the COM class factory for component with CLSID {A7B3B4EE-925C-4D6C-B007-A4A6A0B09143} failed due to the following error: 80040154.”

It's not often I see a COMException these days, so I was initially baffled. Since the Sync Framework also has an unmanaged API, this is really not surprising, but that didn't help me solve my problem.

What was even weirder was that when I tried running the same code in my application, this exception was not being thrown.

It took me a couple of hours to figure out what the problem was.

Here's a little hint: I'm running Windows Vista x64.

No: The issue is not that I'm running Vista :)

Even on x64, Visual Studio runs as a 32-bit process, and so does MSTest. Since my code was compiled to Any CPU, the application itself was running in a 64-bit process, whereas my unit test was running in a 32-bit process.

I tried changing my build output to x86, and now the application started throwing the same exception as the unit test did.

In other words: When running in a 64-bit process, everything worked as intended. When running in a 32-bit process, a COMException was thrown.

As it turned out, I had only installed the 64-bit version of the Sync Framework, and even though the SDK seems to contain builds for the other architectures as well, the COM Server wasn't properly registered for 32-bit use.

To resolve this issue, I downloaded and installed the x86 version of the Sync Framework as well, and the problem went away.

If you are having the same problem, I hope this post helps you resolve it.


Comments

Reginald Henderson
PERFECT. This is exactly what I needed!!! Thanks dude.
2009-07-10 12:46 UTC
Hi Reginal

Thank you for your message - I am happy that my post was helpful to you.
2009-07-10 19:23 UTC
Thanks for this, I stumbled on this one today. My issue was simply that it was still compiling for "Any CPU". I simply changed it to x86, and there were no problems.
2010-03-07 02:45 UTC
Bernhard
Thanks, that did the job!
2011-09-09 07:49 UTC
Michael N
Thank you for the information; this worked for me!

I was trying to find out why SharePoint Workspace did not work on my workstation. It was failing with the "Class not found" 80040154 error, and I found your article with a Google search on the CLSID. Installing Microsoft Sync Framework 1.0 SP1 fixed the problem, and I would never have known where to look without your article.
2011-09-14 11:25 UTC

AutoFixture .8.1 Released

Sunday, 17 May 2009 07:48:36 UTC

Today I've created a new release (.8.1 for lack of a better version number) of AutoFixture. While it contains some breaking changes, they all relate to features that I have yet to cover here on the blog - in other words: All the examples that I've posted so far are still valid.


AutoFixture As Fixture Object

Friday, 15 May 2009 05:34:00 UTC

Dear reader, I hope you are still with me!

After eight posts of AutoFixture feature walkthroughs, I can't blame you for wondering why this tool might even be relevant to you. In this post, we'll finally begin to look at how AutoFixture can help you towards Zero-Friction TDD!

In an earlier post, I described how the Fixture Object pattern can help you greatly reduce the amount of test code that you have to write. Since AutoFixture was designed to act as a general-purpose Fixture Object, it can help you reduce the amount of test code even further, letting you focus on specifying the behavior of your SUT.

In that former post, the original example was this complex test that I will repeat in it's entirety for your benefit (or horror):

[TestMethod] public void NumberSumIsCorrect_Naïve() {     // Fixture setup     Thing thing1 = new Thing()     {         Number = 3,         Text = "Anonymous text 1"     };     Thing thing2 = new Thing()     {         Number = 6,         Text = "Anonymous text 2"     };     Thing thing3 = new Thing()     {         Number = 1,         Text = "Anonymous text 3"     };       int expectedSum = new[] { thing1, thing2, thing3 }.         Select(t => t.Number).Sum();       IMyInterface fake = new FakeMyInterface();     fake.AddThing(thing1);     fake.AddThing(thing2);     fake.AddThing(thing3);       MyClass sut = new MyClass(fake);     // Exercise system     int result = sut.CalculateSumOfThings();     // Verify outcome     Assert.AreEqual<int>(expectedSum, result,         "Sum of things");     // Teardown }

This test consists of 18 lines of code.

Using the Fixture Object pattern, I was able to cut that down to 7 lines of code, which is a 61% improvement (however, the downside was an additional 19 lines of (reusable) code for MyClassFixture, so the benefit can only be reaped when you have multiple tests leveraged by the same Fixture Object. This was all covered in the former post, to which I will refer you).

With AutoFixture, we can do much better. Here's a one-off rewrite of the unit test using AutoFixture:

[TestMethod] public void NumberSumIsCorrect_AutoFixture() {     // Fixture setup     Fixture fixture = new Fixture();     IMyInterface fake = new FakeMyInterface();     fixture.Register<IMyInterface>(() => fake);       var things = fixture.CreateMany<Thing>().ToList();     things.ForEach(t => fake.AddThing(t));     int expectedSum = things.Select(t => t.Number).Sum();       MyClass sut = fixture.CreateAnonymous<MyClass>();     // Exercise system     int result = sut.CalculateSumOfThings();     // Verify outcome     Assert.AreEqual<int>(expectedSum, result,         "Sum of things");     // Teardown }

In this test, I map the concrete fake instance to the IMyInterface type in the fixture object, and then use its ability to create many anonymous instances with one method call. Before exercising the SUT, I also use the fixture instance as a SUT Factory.

Apart from AutoFixture (and FakeMyInterface, which is invariant for all variations, and thus kept out of the comparison), this test stands alone, but still manages to reduce the number of code lines to 10 lines - a 44% improvement! In my book, that's already a significant gain in productivity and maintainability, but we can do better!

If we need to test MyClass repeatedly in similar ways, we can move the common code to a Fixture Object based on AutoFixture, and the test can be refactored to this:

[TestMethod] public void NumberSumIsCorrect_DerivedFixture() {     // Fixture setup     MyClassFixture fixture = new MyClassFixture();     fixture.AddManyTo(fixture.Things);       int expectedSum =         fixture.Things.Select(t => t.Number).Sum();     MyClass sut = fixture.CreateAnonymous<MyClass>();     // Exercise system     int result = sut.CalculateSumOfThings();     // Verify outcome     Assert.AreEqual<int>(expectedSum, result,         "Sum of things");     // Teardown }

Now we are back at 7 lines of code, which is on par with the original Fixture Object-based test, but now MyClassFixture is reduced to 8 lines of code:

internal class MyClassFixture : Fixture {     internal MyClassFixture()     {         this.Things = new List<Thing>();         this.Register<IMyInterface>(() =>             {                 var fake = new FakeMyInterface();                 this.Things.ToList().ForEach(t =>                     fake.AddThing(t));                 return fake;             });     }       internal IList<Thing> Things { get; private set; } }

Notice how I've moved the IMyInterface-to-FakeMyInterface mapping to MyClassFixture. Whenever it's asked to create a new instance of IMyInterface, MyClassFixture makes sure to add all the Thing instances to the fake before returning it.

Compared to the former Fixture Object of 19 lines, that's another 58% improvement. Considering some of the APIs I encounter in my daily work, the above example is even rather simple. The more complex and demanding your SUT's API is, the greater the gain from using AutoFixture will be, since it's going to figure out much of the routine stuff for you.

With this post, I hope I have given you a taste of the power that AutoFixture provides. It allows you to focus on specifying the behavior of your SUT, while taking care of all the infrastructure tedium that tends to get in the way.


Anonymous Sequences With AutoFixture

Monday, 11 May 2009 20:25:42 UTC

When writing unit tests you often need to deal with sequences and collections, populating lists with anonymous data as part of setting up a Fixture.

This is easy to do with AutoFixture. While you can obviously create a simple loop and call CreateAnonymous from within the loop, AutoFixture provides some convenient methods for working with sequences.

Equivalent to the CreateAnonymous method, the Fixture class also includes the CreateMany method that creates a sequence of anonymous variables. CreateManyAnonymous might have been a more concise and consistent name for the method, but I felt that this was a bit too verbose.

This will create an IEnumerable<string>:

Fixture fixture = new Fixture();
var strings = fixture.CreateMany<string>();

Obvously, you can create sequences of whatever type you want, as long as AutoFixture can figure out how to create instances of the type:

var myInstances = fixture.CreateMany<MyClass>();

Being able to create sequences of anonymous data is nice, but sometimes you need to add multiple anonymous items to an existing list (particularly if that list is a read-only property of your SUT).

To support that scenario, the Fixture class also has the AddManyTo method that can be used like this:

var list = new List<MyClass>();
fixture.AddManyTo(list);

This simply creates many anonymous MyClass instances and adds them all to the list. Once more, AddManyAnonymousTo might have been a more precise name, but again I chose a less verbose alternative.

If you want more control over how the instances are created, a more explicit overload of AddManyTo gives you that.

var list = new List<int>();
var r = new Random();
fixture.AddManyTo(list, () => r.Next());

The above examples adds many random numbers to the list of integers, since the second parameters is a Func<T> used to create the instances.

By default, these methods all create 3 anonymous variables when called, since 3 is a good equivalent for many. If you want a different number of instances to be created, you can modify the RepeatCount property.

fixture.RepeatCount = 10;
var sequence = fixture.CreateMany<MyClass>();

The above example will create an IEnumerable<MyClass> with 10 anonymous MyClass instances, while this will add 7 anonymous instances to the list variable:

var list = new List<MyClass>();
fixture.RepeatCount = 7;
fixture.AddManyTo(list);

AutoFixture provides some convenient methods for creating and managing collections of anonymous data. While it may seem simple (and it is), in a future post I will demonstrate how it can save you quit a bit of infrastructure code, and enable you to write unit tests that are shorter, more concise and more maintainable.


Managing Loosely Coupled Projects

Tuesday, 05 May 2009 18:54:11 UTC

Udi recently posted an article on managing loose coupling in Visual Studio. While I completely agree, this is a topic that deserves more detailed treatment. In particular, I'd like to expand on this statement:

"In fact, each component could theoretically have its own solution"

This is really the crux of the matter, although in practical terms, you'd typically need at least a couple of projects per component. In special cases, a component may truly be a stand-alone component, requiring no other dependencies than what is already in the BCL (in fact, AutoFixture is just such a component), but most components of more complex software have dependencies.

Even when you are programming against interfaces (which you should be), these interfaces will normally be defined in other projects.

PragmaticMinimalSolution

A component may even use multiple interfaces, since it may be implementing some, but consuming others, and these interfaces may be defined in different projects. This is particularly the case with Adapters.

Finally, you should have at least one unit test project that targets your component.

In essence, while the exact number of projects you need will vary, it should stay small. In the figure above, we end up with five projects, but there's also quite a few abstractions being pulled in.

As a rule of thumb I'd say that if you can't create an .sln file that contains less than ten projects to work on any component, you should seriously consider your decoupling strategy.

You may choose to work with more than ten projects in a solution, but it should always be possible to create a solution to work with a single component, and it should drag only few dependencies along.


Dealing With Constrained Input

Friday, 01 May 2009 03:56:00 UTC

As a response to my description of how AutoFixture creates objects, Klaus asked:

“[What] if the constructor of ComplexChild imposes some kind of restriction on its parameter? If, for example, instead of the "name" parameter, it would take a "phoneNumber" parameter (as a string), and do some format checking?”

Now that we have covered some of the basic features of AutoFixture, it's time to properly answer this excellent question.

For simplicity's sake, let's assume that the phone number in question is a Danish phone number: This is pretty good for example code, since a Danish phone number is essentially just an 8-digit number. It can have white space and an optional country code (+45), but strip that away, and it's just an 8-digit number. However, there are exceptions, since the emergency number is 112 (equivalent to the American 911), and other 3-digit special numbers exist as well.

With that in mind, let's look at a simple Contact class that contains a contact's name and Danish phone number. The constructor might look like this:

public Contact(string name, string phoneNumber) {     this.Name = name;     this.PhoneNumber =         Contact.ParsePhoneNumber(phoneNumber); }

The static ParsePhoneNumber method strips away white space and optional country code and parses the normalized string to a number. This fits the scenario laid out in Klaus' question.

So what happens when we ask AutoFixture to create an instance of Contact? It will Reflect over Contact's constructor and create two new anonymous string instances - one for name, and one for phoneNumber. As previously described, each string will be created as a Guid prepended with a named hint - in this case the argument name. Thus, the phoneNumber argument will get a value like "phoneNumberfa432351-1563-4769-842c-7588af32a056", which will cause the ParsePhoneNumber method to throw an exception.

How do we deal with that?

The most obvious fix is to modify AutoFixture's algorithm for generating strings. Here an initial attempt:

fixture.Register<string>(() => "112");

This will simply cause all generated strings to be "112", including the Contact instance's Name property. In unit testing, this may not be a problem in itself, since, from an API perspective, the name could in principle be any string.

However, if the Contact class also had an Email property that was parsed and verified from a string argument, we'd be in trouble, since "112" is not a valid email address.

We can't easily modify the string generation algorithm to fit the requirements for both a Danish telephone number and an email address.

Should we then conclude that AutoFixture isn't really useful after all?

On the contrary, this is a hint to us that the Contact class' API could be better. If an automated tool can't figure out how to generate correct input, how can we expect other developers to do it?

Although humans can make leaps of intuition, an API should still go to great lengths to protect its users from making mistakes. Asking for an unbounded string and then expecting it to be in a particular format may not always be the best option available.

In our particular case, the Value Object pattern offers a better alternative. Our first version of the DanishPhoneNumber class simply takes an integer as a constructor argument:

public DanishPhoneNumber(int number) {     this.number = number; }

If we still need to parse strings (e.g. from user input), we could add a static Parse, or even a TryParse, method and test that method in isolation without involving the Contact class.

This neatly solves our original issue with AutoFixture, since it will now create a new instance of DanishPhoneNumber as part of the creation process when we ask for an anonymous Contact instance.

The only remaining issue is that by default, the number fed into the DanishPhoneNumber instance is likely to be considerably less than 112 - actually, if no other Int32 instances are created, it will be 1.

This will be a problem if we modify the DanishPhoneNumber constructor to look like this:

public DanishPhoneNumber(int number) {     if ((number < 112) ||         (number > 99999999))     {         throw new ArgumentOutOfRangeException("number");     }     this.number = number; }

Unless a unit test has already caused AutFixture to previously create 111 other integers (highly unlikely), CreateAnonymous<Contact> is going to throw an exception.

This is easy to fix. Once again, the most obvious fix is to modify the creation algorithm for integers.

fixture.Register<int>(() => 12345678);

However, this will cause that particular instance of Fixture to return 12345678 every time you ask it to create an anonymous integer. Depending on the scenario, this may or may not be a problem.

A more targeted solution is to specifically address the algorithm for generating DanishPhoneNumber instances:

fixture.Register<int, DanishPhoneNumber>(i =>     new DanishPhoneNumber(i + 112));

Here, I've even used the Register overload that automatically provides an anonymous integer to feed into the DanishPhoneNumber constructor, so all I have to do is ensure that the number falls into the proper range. Adding 112 (the minimum) neatly does the trick.

If you don't like the hard-coded value of 112 in the test, you can use that to further drive the design. In this case, we can add a MinValue to DanishPhoneNumber:

fixture.Register<int, DanishPhoneNumber>(i =>     new DanishPhoneNumber(i +         DanishPhoneNumber.MinValue));

Obvously, MinValue will also be used in DanishPhoneNumber's constructor to define the lower limit of the Guard Clause.

In my opinion, a good API should guide the user and make it difficult to make mistakes. In many ways, you can view AutoFixture as an exceptionally dim user of your API. This is the reason I really enjoyed receiving Klaus' original question: Like other TDD practices, AutoFixture drives better design.


Speaking at 7N IT Conference 2009

Tuesday, 28 April 2009 21:02:32 UTC

At May 12 2009 I'll be speaking at 7N's IT Konference 2009 (in Danish, so that's no spelling error). You can read the program here.

The topic of my talk will be TDD patterns and terminology, so I'll discuss Fixtures, Stubs, Mocks and the like. As always, xUnit Test Patterns will form the basis of my vocabulary.

Of the other speakers, I'm particularly looking forward to hear my good friend Martin Gildenpfennig from Ative speak!


Replacing AutoFixture's Default Algorithms

Monday, 27 April 2009 17:42:07 UTC

Several times in my previous AutoFixture posts, I've insinuated that you can change the algorithms used for creating strings, numbers and so on, if you don't like the defaults.

One way you can do this is by simply using the Register method that I introduced in my previous post. Let's say that you want to replace the string algorithm to simply return a specific string:

fixture.Register<string>(() => "ploeh");

No matter how many times you'll call CreateAnonymous<string> on that particular fixture object, it will always return ploeh.

The Register method is really only a type-safe convenience method that wraps access to the TypeMappings property. TypeMappings is just a Dictionary of types mapped to functions. By default, the Fixture class has a set of pre-defined TypeMappings for primitive types such as strings, numbers and booleans, so you could access the function used to generate strings by indexing into this Dictionary with the System.String type.

Equivalent to the above example, you could alternatively replace the string algorithm like this:

fixture.TypeMappings[typeof(string)] = s => "fnaah";

Instead of using the Register method, I here assign a lambda expression directly to the key identified by the System.String type. This is what the Register method does, so the result is exactly the same.

However, you may have noticed that by accessing TypeMappings directly, the signature of the function is different. The Register method takes a Func<T>, whereas the TypeMappings Dictionary expects a Func<object, object>. As you can see, the Register method is more type-safe, but the TypeMappings Dictionary gives you a chance to utilize the optional seed that one of the CreateAnonymous overloads takes.

You could, for example, do this:

fixture.TypeMappings[typeof(string)] = s =>     string.Format((string)s, new Random().Next(100));

Although this particular algorithm has a built-in weakness (can you spot it?), we can now use the seed to provide a format string, like this:

string result = fixture.CreateAnonymous("Risk: {0}%");

which will yield a result like Risk: 32%.

When I designed the extensibility mechanism for AutoFixture, I seriously considered defining an interface that all TypeMappings had to implement, but I ended up preferring a Func<object, object> instead, since this allows you to redefine a particular algorithm inline in a test by using an anonymous delegate or lambda expression, and you can also reuse an existing algorithm, as long as it fits the signature.


Comments

Paul
Hello, I am looking at Autofixture now, but cannot find TypeMappings. They were removed from the library?
2012-07-25 07:05 UTC
Yes, TypeMappings were removed in AutoFixture 2.0, which has a much more flexible extensibility model. Ultimately, a custom ISpecimenBuilder can do everything you may want to do.
2012-07-25 08:37 UTC

Dealing With Types Without Public Constructors

Thursday, 23 April 2009 19:51:42 UTC

Now that I've described how AutoFixture creates objects, it's time to look at a bit more advanced scenario. As you may recall, AutoFixture creates an object graph based on the public constructors of the types contained in that object graph.

That's all well and good when all involved types have public constructors, but what happens when this is not the case?

Imagine that the MyClass constructor has this signature:

public MyClass(IMyInterface mi)

Since IMyInterface is an interface it has no public constructors, so this will not work:

Fixture fixture = new Fixture(); MyClass sut = fixture.CreateAnonymous<MyClass>();

The second line of code will throw an ArgumentException ObjectCreationException* stating that “AutoFixture was unable to create an instance of type Ploeh.QualityTools.AutoFixtureDocumentationTest.Intermediate.IMyInterface, since it has no public constructor.” Not terribly surprising, actually.

To resolve this issue, the Register method allows you to specify a custom function that creates an object of the requested type. In the case of IMyInterface, that would be a Func<IMyInterface>:

Fixture fixture = new Fixture(); fixture.Register<IMyInterface>(() =>     new FakeMyInterface()); MyClass sut = fixture.CreateAnonymous<MyClass>();

Here, I use a lambda expression to register the FakeMyInterface type, so that every time that particular Fixture instance is asked to create an instance of IMyInterface, it will invoke the lambda expression, and thus return an instance of FakeMyInterface (which obviously implements IMyInterface).

The Register method simply lets you map types without public constructors to concrete types created by a function you specify.

A more advanced scenario arises if you wish to use a specific text with this FakeMyInterface constructor overload:

public FakeMyInterface(int number, string text)

Obviously, you can do it manually like this:

Fixture fixture = new Fixture(); int anonymousNumber = fixture.CreateAnonymous<int>(); string knownText = "This text is not anonymous"; fixture.Register<IMyInterface>(() =>     new FakeMyInterface(anonymousNumber, knownText));

Here, I simply use the fixture object to create an anonymous number, while the knownText variable is explicitly assigned a value, and then both are used as outer variables in the Register function.

This is, however, a common scenario, so the Register method has some convenience overloads that will supply anonymous input parameters for you to use or throw away as you like. This means that I can rewrite the above example to this:

Fixture fixture = new Fixture(); string knownText = "This text is not anonymous"; fixture.Register<int, string, IMyInterface>((i, s) =>     new FakeMyInterface(i, knownText));

Compared to the previous example, I save a line of code. The drawback is that I have to explicitly specify the type parameters to the Register method. In my book, that's a pretty good tradeoff, as it removes a line of irrelevant code, and allows the test to focus on the relevant parts.

Notice that this Register overload creates both an anonymous integer and an anonymous string, but since I don't want to use the anonymous string (s), I just ignore it and use the knownText variable instead.

*Edit (2009-09-02): Changed the name of the Exception type to correctly reflect a breaking change introduced in AutoFixture .8.5.


Creating Booleans With AutoFixture

Sunday, 19 April 2009 17:40:36 UTC

(Just back after 14 days in Morocco, I'll pick up where I left…)

The last group of built-in special creation algorithms for AutoFixture, besides strings and numbers, concerns Booleans.

The default algorithm is to alternate between true and false, starting with true; i.e. the first time you invoke

fixture.CreateAnonymous<bool>();

it will return true, the next time false, then true again, etc.

The reason I chose this algorithm was because I wanted to ensure that the first time AutoFixture creates an anonymous Boolean, it will return true, which is different than the default (false, in case you were in doubt). This gives us better assurance that a given constructor argument or property is being assigned a real value instead of the default.

Like with numbers, using the overload that takes a seed has no effect, and the seed is simply ignored.

fixture.CreateAnonymous(true);

In other words, the above method is still going to return false every second time, so it doesn't really make sense to use this overload at all for Booleans (or numbers).


Page 34 of 36

"Our team wholeheartedly endorses Mark. His expert service provides tremendous value."
Hire me!