In late July, we discovered a bug in our installation script that caused DevForce installations to always hang on certain Vista machines (such as Sony VAIO laptops). The fix for this bug turned out to have an unintended side effect that is now causing Object Mapper problems for customers who have installed a German version of Windows XP. The rest of this post documents the cause of this problem and how to correct it.
The side effect of the aforementioned bug fix is that it installs the ORM files in C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\Microsoft\MSEnvShared\Addins instead of in C:\Dokumente und Einstellungen\All Users\Application Data\Microsoft\MSEnvShared\Addins. From a registry standpoint, this is the correct location, but if you have read the previous posts in this thread, you will understand that this will break the operation of the Object Mapper.
I did research this matter and found that the reason that Visual Studio uses a hard coded "English name" for "Application Data" instead of an internationalized name is due to a bug in Visual Studio.
There is a known bug with the %ALLUSERSPROFILE% value, the next portion of the path, Application Data, is localized on some non-English locales, but we hard code to Application Data. The fix for this is to add your own value to the registry to point to the directory you install your Add-in into.
This bug will be fixed for the next release of Visual Studio.
The recommended fix for getting the Object Mapper working on machine with a German OS is to add an "Add-in File Path".
This is what it looks like using a German Visual Studio.
Open up “Extras” menu in Visual Studio 2005, and select “Optionen”.
In “Optionen” form. Select “Add-in/Makrosicherheit” from “Umgebung”.
Navigate to “All Users” directory, then “Anwendungsdaten”, then “Microsoft”.
then “MSEnvShared”, then “Addins”. Press “OK” button. This will add the correct search directory for the DevForce ORM Addin.
Edited by davidklitzke - 14-Oct-2007 at 6:39pm