locked
Forcing locale for Addin RRS feed

  • Question

  • I am creating an addin that has been localized for a few locales.  In my next release I would like to support running the addin in versions of VS that I have not produced localized resources for.  For example I would like to be able to have my users install on a version of VS that is chinese and have my plugin load all of my english strings.  If these strings were just hard coded I would be all set, but I am using a System.Resources.ResourceManager to deal with localized resources. Currently I am getting a wierd error when I try and get a localized string out of the resource manager - something along the lines of "index out of range" Is there any way to force the locale that the resource manager uses to look up strings when the resource manager is created?
    Friday, September 22, 2006 5:39 PM

Answers

  • I'm afraid that no, a resource dll is required to use custom images so if you have several resource dlls, all of them should include the images. Maybe the only workaround is to change the locale of the thread before add-in the commands, to use the English resource dll, and restore it after that, not sure. Another approach is to avoid resource dlls altogether for localized strings, which is what I did in my addin. I use my own XML file with localized strings and my own resource manager...

    I have complained to MS a lot of times about forcing add-in developers to use dlls to store custom images, which must be bitmaps and not icons to convolute the problem with transparency issues. Hopefully they provide a way to pass a managed icon in the next version of VS...

     

     

     

    Tuesday, September 26, 2006 9:18 AM

All replies

  • Check the docs here:

    http://msdn2.microsoft.com/en-us/library/system.resources.resourcemanager.aspx

    AFAIK, the resource manager should use fallback rules if the resources are not found for the running culture.

     

    Monday, September 25, 2006 8:30 AM
  • So after reading the docs and testing a little more it seems like I must have a configuration issue with the way I am building my plugin.  As of now I can not run the plugin in any locale unless I have a folder with a resources.dll under the locale name in my executing directory.(for example /en/Addin.resources.dll) This is true even for my english installations.  All of the resources for the english installations are included in the main assembly but unless I have that assembly installed the addin won't load.  When it fails it spits out a message

    Could not load file or assembly 'Addin.resources, Version=4.0.0.0, Culture=en, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

    I realize there must be some setting that is not properly set during build time that is forcing this search (and its subsequent failure).  Does anyone have any suggestions as to where to look?

    Monday, September 25, 2006 9:19 PM
  • I have spent more time hten I have wnated on this silly problem and finally tracked it down to a somewhat unrelated issue.  When I am adding my commands I am using a command like the following

    command =

    commands.AddNamedCommand2(

    addInInstance,

    "AddinCommand",

    Connect.ResourceMgr.GetString("EXECUTE_CMD"),

    Connect.ResourceMgr.GetString("EXECUTE_TOOLTIP"),

    false,

    1,

    ref contextGUIDS,

    (int)vsCommandStatus.vsCommandStatusSupported +

    (int)vsCommandStatus.vsCommandStatusEnabled,

    (int)vsCommandStyle.vsCommandStylePictAndText,

    vsCommandControlType.vsCommandControlTypeButton);

    In the documentation it states that if teh useMSOButton is "false" then it forces the lookup of the image in a localized resource file.  Is there any hack to get around this? As in is there any way to specify a culture neutral resource dll that only contains these images?

    Tuesday, September 26, 2006 12:09 AM
  • I'm afraid that no, a resource dll is required to use custom images so if you have several resource dlls, all of them should include the images. Maybe the only workaround is to change the locale of the thread before add-in the commands, to use the English resource dll, and restore it after that, not sure. Another approach is to avoid resource dlls altogether for localized strings, which is what I did in my addin. I use my own XML file with localized strings and my own resource manager...

    I have complained to MS a lot of times about forcing add-in developers to use dlls to store custom images, which must be bitmaps and not icons to convolute the problem with transparency issues. Hopefully they provide a way to pass a managed icon in the next version of VS...

     

     

     

    Tuesday, September 26, 2006 9:18 AM
  • Thanks for your help.
    Tuesday, September 26, 2006 6:14 PM