0

I have:

  1. A.dll - a third-party assembly
  2. B.dll - my own class library assembly
  3. C.exe - my own executable

I am using the Costura.Fody NuGet package to embed A.dll into B.dll, and C.exe has a binary reference to B.dll.

(A.dll embedded within B.dll) <-- C.exe

When I build C.exe, however, A.dll appears in the output folder, despite already being embedded into B.dll (which is also copied to the output folder). I would prefer not to distribute what is essentially two copies of A.dll with my executable, but I would like to distribute A & B as one.

In B.dll, the "Copy Local" property of A.dll is set to false, and is instead explicitly included in Costura's FodyWeavers.xml.

Is there any way I can configure Costura.Fody and/or my reference properties so that A.dll is not copied independently into C.exe's output folder, while B.dll (with the embedded reference to A.dll) is copied?

Ryan K.
  • 67
  • 1
  • 10
  • Take a look [here](https://stackoverflow.com/q/189549/767890). – InBetween Jan 04 '18 at 15:14
  • Copy Local = False should by itself be enough to prevent A.dll from getting copied to the B build directory. Which in turn prevents msbuild from finding A when it builds C. And it shouldn't be looking for it at all since A should no longer appear in the manifest of B. More than one thing went wrong here. You'll at least have to dig through the detailed msbuild trace to find out how it managed to find it anyway. Or just don't bother fighting the machine, the only thing that matters is what you deploy to the user's or production machine. – Hans Passant Jan 04 '18 at 15:23
  • Thanks Hans for referring me to the msbuild trace. Msbuild was finding A in Program Files because I'd copied it there long ago. – Ryan K. Jan 04 '18 at 16:05

2 Answers2

0

As far I know, the reference assembly that you want to avoid would be needed.

Ritwik Sen
  • 296
  • 1
  • 13
  • Yes, A.dll would be needed for C.exe to function properly. But my issue with the current situation is that A.dll is technically already included with the reference to B.dll, since it is embedded, but it still copies locally. C.exe is functional even when I remove A.dll from the output folder, so I'd like to keep it from appearing there in the first place. – Ryan K. Jan 04 '18 at 15:19
  • Consider B.dll being generated from a Visual Studio project. In that project if you had added a reference of C.dll, the bin folder for B would definitely have had C.dll in it. Thus if A.dll has a reference of B, it would automatically pull up C as default behavior. From what I;ve worked on, child parent level Dll's keep on adding up. You can use third party NuGets to avoid this, but again the build would have an added task to decompress the parent Dlls, and make build time slow. – Ritwik Sen Jan 04 '18 at 15:25
0

After referring to msbuild trace log, I found that C.exe was resolving a path to A.dll in Program Files. Removing A.dll from Program Files solved my issue.

Ryan K.
  • 67
  • 1
  • 10