2006.04.07 03:21 PM

Outlook, Lookout, and a .NET 2.0 Breaking Change

This morning I asked Lookout (predecessor to the MSN Toolbar) to find all the Outlook messages I sent in March using this query:

from:bachtal date:[3/1/2006 TO 3/31/2006]

However, instead of coming back with a list of matches, it came back with an error message: "incorrect date syntax in range".

After double- and triple-checking the syntax, and remembering that I'd successfully used a query like this just last month, I concluded that something must have changed. The only thing I could think of that had changed on this machine was that I had recently installed version 2.0 of the .NET Framework. I knew Lookout was written with .NET version 1.1, and I knew that it was registered as a COM component and loaded itself into Outlook without the benefit of a shim, and I knew that this meant that it was being loaded into the same AppDomain as all other managed add-ins using the latest version of MSCorEE.dll, which was now 2.0. So, I figured there must be something in .NET 2.0 that didn't like something in Lookout's 1.1 code.

The Lookout log file, Log.txt, which is stored in the Log Files folder beneath the configured Lookout data directory, showed these details about the error:

(00.02s) Error: ***** for query 'from:bachtal date:[3/1/2006 TO 3/31/2006]':
Lucene.Net.QueryParsers.ParseException: incorrect date syntax in range
   at Chrome.Index.ParserEx.MakeDateFilter(String field, String range)
   at Chrome.Index.ParserEx.ReplaceDates(String query, Filter& datefilter)
   at Chrome.Index.ParserEx.ParseEx(String input, Filter& datefilter)
   at Chrome.Search.SearchForm.Search() [Chrome.Search.SearchForm.ParseError()]

I pointed Reflector at Lookout.dll, which contains the Chrome.Index namespace, and checked out the MakeDateFilter method in the ParseEx class:

 1 int num1 = range.IndexOf(" TO ");
 2 if ((num1 <= 0) || (num1 >= (range.Length - 1)))
 3 {
 4   throw new ParseException("missing or incorrect 'TO' in range");
 5 }
 6 
 7 string text1 = range.Substring(0, num1);
 8 string text2 = range.Substring(num1 + 4, range.Length - (num1 + 4));
 9 try
10 {
11   DateTime time3 = DateTime.Parse(text1);
12   time1 = time3.Date;
13   DateTime time4 = DateTime.Parse(text2);
14   time2 = (time4.Date + TimeSpan.FromDays(1)) - TimeSpan.FromSeconds(1);
15 }
16 catch (FormatException)
17 {
18   throw new ParseException("incorrect date syntax in range");
19 }

This was definitely the code throwing the ParseException, but the logic seemed fine, so I backed up a level to the ParseEx.ReplaceDates method to see what range string it was passing to MakeDateFilter:

 1 int num3 = query.IndexOf("date:");
 2 if (num3 >= 0)
 3 {
 4   int num4 = num3 + 5;
 5   if ((num4 >= query.Length) || (query[num4] != '['))
 6   {
 7     throw new ParseException("missing or misplaced '[' in date range");
 8   }
 9   int num5 = query.IndexOf("]", num4);
10   if (num5 <= num4)
11   {
12     throw new ParseException("range is malformed");
13   }
14   string text1 = query.Substring(num4 + 1, num5 - num4);
15   if (datefilter != null)
16   {
17     throw new ParseException("only one date range/keyword allowed");
18   }
19   datefilter = this.MakeDateFilter("date", text1);
20   query = query.Remove(num3, (num5 - num3) + 1).Trim();
21 }

Ahh, look close. There's a subtle off-by-one bug in line #14. As a result, instead of reducing the query above to this:

"3/1/2006 TO 3/31/2006"

It leaves a dangling bracket like this:

"3/1/2006 to 3/31/2006]"

That little dingleberry is subsequently included in MakeDateFilter's text2 string and passed to the DateTime.Parse method, where (I confirmed) in .NET 1.1 it is ignored, but in .NET 2.0 it causes DateTime.Parse to throw an exception.

To their credit, Microsoft did document this breaking change:

We try to make DateTime.Parse accept a lot of input and make a reaosnable [sic] interpretation. However there are scenarios where it was interpreting data which was simply not reasonable. For example, the string "01-01-10/10/2001" would previously be successfully parsed, however this is clearly not a valid form for a DateTime. The scope of this change is limited, and will not affect any valid formats.

The solution? Make Outlook load version 1.1.4332 of the .NET framework. To do this, create a file in the same directory as Outlook.exe named Outlook.exe.config and put the following in it:

<configuration>
   <startup>
      <supportedRuntime version="v1.1.4322"/>
      <supportedRuntime version="v1.0.3705"/>
   </startup>
</configuration>

Restart Outlook and you should be good to go. Of course, this solution assumes that you don't also want to load any shim-less .NET 2.0 managed add-ins. I suppose it might be possible get Lookout loaded into Outlook using a shim that would isolate its CLR version, but I haven't time to figure it out. I have to start going through all those emails.


Comments

Here are some other folks having what I believe is the same problem:

http://www.lookoutsoft.com/Forums/topic.asp?TOPIC_ID=1008

ewbi.develops | 2006.04.07 04:16 PM

Thank you for identifying the cause of the problem so well and for providing the workaround. Whose job is it to correct the "ParseEx.ReplaceDates method", which would address the underlying problem?

Grant | 2006.05.10 07:29 PM

You're welcome, Grant. Unfortunately, I think Microsoft considers Lookout a dead product, so I don't think there will be an update.

ewbi.develops | 2006.05.10 08:23 PM

Hey! Great work. You solved a problem which was driving me crazy. Warmest greetings from Austria!

Willy

Wilhelm Klenner | 2006.05.24 01:53 AM

Willy, glad to hear it! Thanks for the comment.

ewbi.develops | 2006.05.24 12:15 PM

Unfortunately, these kinds of workarounds will kill other add ins written using VSTO or any other Outlook add ins that need CLR 2.0. Shimming doesn't help because only one CLR version can be loaded per-process (not per-appdomain).

I am in the process of trying to get Microsoft to implement a fix in Outlook 2007 that will prevent add-ins from forcing a particular framework version because loading lower than what is available is far worse than loading a newer framework than an add in was designed for.

Josh Einstein | 2006.06.18 01:51 PM

Hi Josh,

Thanks for the comment and clarification. I thought it was perhaps possible to load a COM out-of-process add-in shim that could host a specific .NET version.

Beyond that, I'm not sure I agree with you that "loading lower ... is far worse", particularly in this case where 1) lower allows the add-in to operate correctly, and 2) it's the only .NET-based add-in I load. Others may not be so lucky, but like I said in the last paragraph (with new consideration for the "shim-less" part based on your input): "this solution assumes that you don't also want to load any [shim-less] .NET 2.0 managed add-ins".

Good luck getting Microsoft to change the way their Office products load .NET add-ins.

ewbi.develops | 2006.06.19 10:36 AM

I thought it was easier to fix it - so I used ILDASM to create an IL file, patched the file and then re-assembled with ILASM under .Net 2.0.

So far, seems to work fine.

Pete Wilson | 2006.06.19 05:33 PM

There you go, Pete! I was wondering if that might be the way to go. Thanks for confirming that it's possible.

ewbi.develops | 2006.06.19 07:16 PM

For those that want detailed instructions, or to download the (untested) patched dll, I put up a web page:
http://www.scw.us/win/FixingLookout

Pete Wilson | 2006.07.16 08:45 AM

I patched Lookout with the fixed DLL from the above URL and it worked for me like a dream.

I wish to say "Thank You" to the guy who made the fix.

Ori | 2006.07.24 08:37 AM

Pete - Thanks for the patch. As Ori's comment confirms, it seems to work. Your post about using ildasm and patching the code is also an interesting read.

ewbi.develops | 2006.07.24 09:53 AM

Dear Pete,
Thanks for the patch -it appears to solve the problem and was painless to implement, thanks to your lucid instructions.
Unlike you, I can't write toolbars for MSN Search so I'm stuck with Lookout for the time being.
I hope all Lookout users find out about your excellent patch.
Regards,

David McMurray | 2006.11.18 11:51 PM

Thanks for setting up the download for the new dll. Lookout is used a lot in our office. Even the non tech people love it. Thanks for keeping the product working after installing ie7!!

Grateful lookout user | 2006.12.08 10:28 AM

Thanks so much for this fix! IT's been driving me nutty for months.

LB | 2006.12.12 09:34 AM

Anyone know if this patched Lookout.dll is for v1.2 (as is still available on Microsoft's website) or for the v1.3 that was available from LookoutSoft.com when it was still around? Perhaps this DLL didn't change between 1.2 and 1.3 and it doesn't matter, but I haven't checked.

Gerald | 2007.01.16 08:57 AM

Hi Gerald,

I don't actually use the patch (it was easier to pin my Outlook to 1.1), so I don't know firsthand. I'm also not sure whether the patch author, Pete Wilson, monitors this page. However, I noticed on his page (linked in his comment above) there's a 'comments or questions' email link at the bottom. Might want to try that.

ewbi.develops | 2007.01.16 10:12 AM

Thanks for the reply. I saw the email link but figured I'd try a quick test first (we have various versions of Lookout installed all over the place). From a very crude test of just placing the Lookout.dll from v1.2 in the install directory of my v1.3 Lookout install, I see that the version info and such reported under "Help/About Lookout..." is provided by this DLL. i.e. with v1.2 of this DLL in place Lookout says it is v1.2, and with Pete's patched DLL in place Lookout says it is v1.3 sooo that would seem to answer my question. And it seems to work fine thus far with v1.3... I may shoot him an email anyway and suggest he post the version he patched to avoid confusion.

Gerald | 2007.01.16 12:36 PM

I really HATE how Microsoft bought and subsequently killed this product. Their built-in search for Outlook 2007 stinks. It's slow, and misses items sometimes. I really wish LookOut was still being actively developed.

Frustrated | 2007.04.04 05:48 PM

Lookout WAS great, I tried it so often to get it fixed, but I gave it up, because it never really worked! It isn´t developed and so I think it makes no sense to use this tool anymore...I work with another tool now, which is very similar to Lookout and so you can call it the follower! http://www.lookeen.com
Its great and developed! ;)

Craig | 2009.05.13 04:00 AM

As an early adopter of Windows 7 at my company (we skipped Vista), I was devastated to find out Lookout no longer works on either of these OSes. Outlook bombs out right as Indexing begins. I've scoured the internet hoping for a fix, but have found nothing. I've seen Lookeen mentioned on several other forums, but I refuse to pay 40 dollars for search functionality.

Chris | 2009.08.26 12:00 PM

I'm so glad I found this page! Reverting to an earlier version of the .NET framework fixes another problem that's been bugging me for months: namely, broken flyover message previews in Lookout's search results. Went back to version 1.1 and my previews are back. Yahoo! Thanks for the fix.

Mark F | 2009.11.01 10:26 PM

thanks for the trick... it works fine to me after a week of struggling!!!!!
YOU'RE GREAT

ale marini | 2009.11.24 05:36 AM

Thanks a lot ! create a file Outlook.exe.config works very well, even in 2011 with Outlook 2003 !

sebmarley | 2011.07.12 01:37 AM

The solution in the below link worked for me using Lookout 1.20 Outlook 2007 on all my XP/Vista/Win 7 machines, Thanx to Vlad/Leon.

http://vlad.bailescu.ro/articles/2008/07/01/outlook-2007-vista-spam-protection-and-lightning-fast-search/#comment-166040

Prashant Soni | 2013.01.02 05:01 AM



Post a Comment

 
  (optional)
  (no html)
 
   


TrackBack

TrackBack URL:  http://www.typepad.com/services/trackback/6a00d8341c7bd453ef00d834b6887169e2

Listed below are links to weblogs that reference Outlook, Lookout, and a .NET 2.0 Breaking Change: