That is a lot easier than I thought


For a while now, people have been asking me how to create Satellite DLLs for their Add-ins. My response was always to create your .resx file for each culture, run resgen from a command prompt to create the .resources file, then run al to create the DLL. Finally you need to create directories to contain the Satellite DLLs.


Yesterday the topic of how to create Satellite DLLs for WinForm apps was mentioned, and after finding out a few details and a quick test, there is a much easier way to create Satellite DLLs for an Add-in. First, start the Add-in wizard. Choose all the options you wish, but on the 3rd page, enter @Name as the name of the Add-in and @Description as the description of the Add-in. When you have finished the wizard, right click the project and select Add | New Item, select Resources File, and then enter Resources.culture.resx as the name of your resource file, where culture is the culture name you wish to localize for (for example, en-US for US English). Next, add strings named Name and Description to the resx string editor with any value you wish. When you compile the project, it will automatically create the Satellite DLL, put them in the correct place, and when you run the Add-in and open the Add-in Manager the localized strings should automatically appear.


This exercise also inspired me to create a new sample Add-in to help you create your localized resources. If you select a resx file in the Solution Explorer and select a menu item, a dialog will appear listing all the available cultures. Select a few checkboxes, and the source file will be copied to that new, selected, cultures. You can then open the resource file copy, and localize to the new culture. I should be posting this tool to the automation tools GDN workspace soon.


Comments (4)

  1. Troels Gram says:

    Hi Craig,

    I have satellite assemblies working for addin, but I’ve noticed that VS2005 only loads them properly if the path in the <assembly> element in the .addin file is rooted. Is this intentional? Loading of the actual addin seem to work if I specifiy the assembly location relative to the .addin file location, but VS2005 can’t resolve the satellite dlls (my own resource manager in the addin code resolves the satellite assemblies just fine). It would be really nice to be able to specify the assembly path relative to the .addin location as it simplifies deployment greatly (xcopy style). Alternatively I have to provide an msi with custom actions that replace the assembly path in the .addin file with the absolute installation path.. .

  2. CraigSkibo says:

    No, it should not work that way. I will have somebody look into it to see if there is a workaround.

  3. Troels Gram says:

    Any success on finding a work around for this yet?

  4. Mark says:

    Wow, that really is a lot easier – thanks very much for the tip!