This project is read-only.

API Changes from version .1 to .8 release

Jun 14, 2007 at 7:23 PM

I just found your new release of your library. Sounds like a great effort.

When i repalce the Contacts.dll in my project i get errors because the methode "Load" of the class "ContactManager". What is the replacement for this methode? Are there other API changes?

Regards, Marsupi
Jun 18, 2007 at 4:37 PM
Oops. Renamed Load to GetContact.
There might have been a couple other changes to appease FxCop but I wasn't thoroughly documenting breaking changes for .8. I'll start a wiki page with breaking changes or functionality additions and just rev it as I check in.

Sorry about that. Please let me know if you run into any more issues.
Jun 23, 2007 at 5:25 AM
I adapted my functions to the changed API (Load to GetContact). I seams to work, but it is remarkable slower than with the previous version. Why is that? What can i do to get the performance from 0.1 Version back.
Jul 7, 2007 at 6:28 AM

Marsupi wrote:
I adapted my functions to the changed API (Load to GetContact). I seams to work, but it is remarkable slower than with the previous version. Why is that? What can i do to get the performance from 0.1 Version back.

Sorry for the belated response, for some reason I didn't see this thread.
The reason it's slower is because I stopped using the native IContactManager. There's a bug in Windows where if you load an IContact from the manager and keep it in memory for more than 4 minutes then attempting to save changes to the contact causes an access violation in WAB32. I was hitting it all the time in my address book UI. It's a known issue to Microsoft, but there haven't been any external complaints about it (it's a new library, not many people trying to use it yet) so it hasn't gotten enough traction to put the fix through Windows Update.* I was able to work around it by reimplementing the funtionality in C#, but one thing the contact manager did that I haven't been able to copy is it compiles and caches the schema, whereas when I CoCreateInstance the IContacts the compilation happens every time :(

So those are the technical reasons.

If this is impacting you I can offer a short term workaround or a longer term solution that I think is better.
  1. I can provide a temporary UnsafeContactManager that behaves the same as .1. Contacts that come from it will have the 4 minute timeout issue, but depending on how you're using them you may not see it. When I'm able to implement the longer term solution it would be removed. The functionality you'd lose with this "Unsafe" ContactManager (because it will have the same limitations as the native IContactManager) are 1. the ability to root the Manager in folders other than the user's Contacts folder, and 2. group functionality, as the native IContactManager is limited to loading .contact files.
  2. The better option I think is to implement Contact in C# and then I can compile and cache the XSD. If I completely remove the dependency on Vista's Wab32 then this library can be available on XP.

Option 2 is what I've been working on. I can give you 1 if the current behavior is unbearable. Unfortunately I don't have a good estimate how long 2 will take.

Let me know what works best for you.

  • There are actually a couple other bugs I know of that are impacting this project and internally I've been pushing to get fixed. I can post them as issues in this project if people are willing to vote them up. It would help to be able to quantify the customer impact of these bugs when trying to justify whether they should be fixed as a Windows patch.
Jul 9, 2007 at 1:44 PM
With the current version the synchronisation time in my application can be really long.

The bug you mentioned doesn't affect my application at all. I'm opening the contact, doing some changes and write the changes back to system. So i'm not affected by the bug directly.

The solution number 2 would be the better way for the future because it will be NOT affected by the things the microsoft library does. The solution 1 would be better because bugs fixed in the microsoft library are automaticly fixed without any work for you. I can go with both of your proposed solutions.

My project isn't time critical at all, so i can wait for the next realese of your library. If you are going for the solution 2 in the next release anyway i'm fine, otherwise it yould be nice to have the option of solution 1 until the soultion 2 is done.

Jul 9, 2007 at 8:21 PM
Thanks for voting :)

There are some other bugs in the underlying platform I'm working around. I think I'll backburner the current work and undo the bug hiding and polish the interfaces. I can release a minimal ContactsBridge (a la Jeff Chrisope's VistaBridge) library that thinly wraps the native IContact APIs but doesn't expose additional functionality like groups, and then continue working on a completely managed implementation. I'll doc the known issues. For some projects, like yours, the bridge implementation might be more appropriate. Especially in the short term.
Jul 22, 2007 at 12:33 AM
I just released the ContactsBridge project. Basically I just pasted back in parts of an older implementation of ContactManager and removed some of the stuff that the native version doesn't support (ContactTypes, alternate ContactManager roots, and alternate contact file extensions). Unfortunately it's also very much untested because my existing tests rely a lot on that functionality and I haven't gone through and forked them to work with this. If you get a chance can you try it and see if it works for you? I'll support fixing bugs in it but primarily I want to focus on the primary version of the library unless there's a real need to invest in this one.

namespaces were changed to Microsoft.ContactsBridge. Other than that it's basically just a fork of the current .8 library so less the removed functionality everything should behave and be named the same.
Aug 19, 2007 at 2:20 PM
Thanks for the ContactsBridge.
I switched my plugin implementation from Contacts.dll to ContactsBridge.dll without a problem. Everything works fine (and fast) so far.