0

My dev team has an uncommon method for deploying (desktop) apps: since our enterprise uses a network storage server, we deploy our exe's and dll's to that server, and map our end users to the same location. So when an end user double clicks an exe, the exe consumes all resources from the network server. This is great because we don't have to use the GAC for deployment (deployment is merely a copy-paste for us). You can think of it as if we are managing our own GAC for all users altogether.

Now we came across a problem- we have an exe (lets call it exe1) which consumes a dll (dll1), which consumes another dll (dll2). We added a reference to dll1 in exe1 and a reference to dll2 in dll1. We also signed the assemblies, and added proper dependentAssembly nodes in exe1.config and dll1.config. Still, the moment dll2 is needed- a FileNotFoundException is thrown for dll2. I guess that if we deployed to the GAC this wouldn't happen, because the JIT would then look and find dll2 there.

We can fix that by either:

  1. Adding a reference to dll2 in exe1 (very bad practice)
  2. dynamically load dll2 when needed

option 2. is fine, only it will complicate our code and I have a feeling there's an other way. well- is there??

EDIT 1: Each dll (and exe) is located in its own folder. We do this so we can share dll's across unrelated exe's.

Nir Smadar
  • 357
  • 2
  • 5
  • 15
  • If your dll's are signed are you sure the version that is being looked for is the same as the one you have deployed? Do you only have this problem in your deployed environment? – David McLean Jan 30 '14 at 09:17
  • Pretty unclear, there's no obvious reason this should fail as long as you made sure that dll2 is copied to the same directory as exe1. You'll need to post the trace you get out of Fuslogvw.exe to get help. – Hans Passant Jan 30 '14 at 13:33
  • @David McLean: Versioning is not an issue, and all assemblies are signed. I do have this problem in deployed env – Nir Smadar Feb 02 '14 at 09:57
  • @ Hans Passant: I edited my question- all dll's are **necessarily** in different folders. This is a way to share dll's across many exe's. – Nir Smadar Feb 02 '14 at 09:59
  • Do I have it right that your app.config lists all referenced assemblies and sets the to the networked folder? https://support.microsoft.com/kb/837908 – Lars Truijens Feb 02 '14 at 21:29
  • @Lars Truijens: exe1 app.config lists dll1 and the element is set to dll1's location. Respectively dll1 app.config lists dll2, and the element is set to dll2's location. Listing dll1 and dll2 in exe1 app.config would be a bad prcatice because if something is changed with dll2, I'll have to potentially update all the app.config files that use dll2 as a 3rd party to dll1. Basically if .NET would search for 3rd party references in the referenced assembly's app.config, it would have been great, but that's not the way things work... – Nir Smadar Feb 03 '14 at 13:17

0 Answers0