Include satellite assemblies of referenced DLLs in VS.NET deployment editor

[Koji Ishii]

Hello,

I'm using VS.NET setup/deployment project and have a problem to produce an
MSI for a product with satellite assemblies.

When I add primary project's primary output, all referenced DLLs are added
to dependencies. However, as far as I tried, I couldn't find a way to
include satellite assemblies for these referenced files.

They are properly copied to the primary proejct's bin folder, so running
from VS.NET is okay. However, even if I add "localized resources" of the
primary project, resources for referenced DLLs do not appear.

Is there a switch to make this happen, anyone happen to know?

Thank you in advance.
Koji Ishii

[Phil Wilson]

I think this is one of the times where you have to switch from specifying
"Primary output" to actually naming the specific files.

"Koji Ishii" <koji...@hotmail.com> wrote in message
news:%23WCAF6$ODHA...@TK2MSFTNGP10.phx.gbl...

[Koji Ishii]

Thank you for your suggestion, but it does not make sense.

Let's say you built a.exe, which links to b.dll. Regardless you add a.exe or
project a's primary output, a.Resources.dll IS included in the setup. That's
good part.

However, satellite assembly for b.dll is not included. The built MSI
includes:
* a.exe
* a.Resources.dll
* b.dll
I'd like this setup project to include b.Resources.dll as well, and your
solution does not solve this problem.

Any other suggestions? Isn't such feature built into VS.NET?

Thanks,
Koji Ishii

"Phil Wilson" <pdjw...@nospam.cox.net> wrote in message
news:OYqUMqaP...@TK2MSFTNGP11.phx.gbl...

[Phil Wilson]

I must be misunderstanding something. I just build the resource Dll with the assembly linker and add
it to the application folder under the localized folder name (such as ja). I just browse to it in VS
and add it like I add any other file to ther setup. In general, I don't see how Visual Studio could
automatically figure out what external satellite assemblies to include because they're determined
dynamically when the application actually runs with a particular culture value on a client machine,
and the runtime starts searching paths for the resource Dlls, falling back on the resources embedded
in the code file. There's no direct reference in the codefile's manifest to any satellites.
--
Phil Wilson [MVP Windows Installer]
----
"Koji Ishii" <koji...@hotmail.com> wrote in message news:eme5Zd5P...@TK2MSFTNGP10.phx.gbl...

[Koji Ishii]

Sorry that my explanation wasn't good enough to repro from scratch. Here's
better one.

1. In Solution A, create a DLL project "COMMON", add a.resx and a.ja.resx.
This will create ja folder and a sattelite DLL under ja folder.
2. In Solution B, create an EXE project "MAIN", add reference to the
COMMON.DLL in solution A. I also created b.resx and b.ja.resx in this
project.
3. Build. I see two satellite DLLs under bin\Debug\ja folder; one from
solution A "COMMON.resources.dll" and the other from current solution
"MAIN.resources.dll". This is superb.
4. Now, create a setup project in solution B
5 Add project's primary output
6. Add project's localized resources
7. Build the MSI and look into File table by Orca.

You will find 3 files in the MSI:

MAIN.exe
ja\MAIN.resources.dll
COMMON.dll

But ja\COMMON.resources.dll is missing. This is pretty inconsistent, isn't
this?

* VS.NET build command copies ja\COMMON.resources.dll to the bin directory,
so F5 gives me fully localized build.
* MSI does include ja\MAIN.resources.dll, so resources for MAIN.exe are
localized.
With this design, I think including ja\COMMON.resources.dll is the
consistent design.

I guess I can work around by adding ja\COMMON.resources.dll into the setup
project and it must work. But isn't that a starnge operation? I even didn't
add COMMON.dll to the setup project. I added it to project MAIN's reference,
and VS.NET automatically pulled in the COMMON.dll. That is a great feature
as you pointed out, but it should also bring its satellite assemblies since
I asked to include MAIN's localized resources in step 6.

Localizing into 10 languages must require building separate process to build
satellite assemblies using assembly linker so that we can outsource. But for
a non-English developers like us, it is preferable to support our own
language and English. If it's two languages, and if both can be done
in-house, doing that within VS.NET helps managing costs.

It sounds like a bug I can't expect MS to fix?

Thanks,
Koji Ishii

"Phil Wilson" <phil....@unisys.spamcom> wrote in message
news:%23Tg8TZA...@TK2MSFTNGP11.phx.gbl...