0

I'm working on a C# application which requires integrating with another company's software. I have isolated all of the code that is tightly coupled to this integration in a single C# project. This way, if the company changes something with their integration, I only have to change code in this one project. The project is a non-executable class library (Project A).

One weird/annoying part of this integration though is that it involves manually copying compiled .dll files from the company's SDK into the bin directory of the project after the project is built. I can't just use a nuget package or something similar. While annoying, I have automated it with a post-build script and it works well enough for that specific project.

I then reference this project/class library from an executable class library, such as a .NET Framework Console project (Project B).

Now I have a problem:

Build Project A
Runs post-build script XCopy C:\CompanyIntegration\Autofac.dll "${TargetDir}".
Compiles without any issues.

Build Project B
Compiles Project A, copies .dlls from Project A bin to Project B bin.
The copied Autofac.dll from Project A overwrites one installed via a nuget package.
The build throws an exception because it expected a different Autofac.dll.

How can I tell the build process to differentiate between these two different Autofac versions/dlls?
Why are the company integration .dll files copied from the bin folder of Project A to the bin folder of Project B in the first place?

  • 1
    Have you determined if there is a single of version of `Autofac.dll` that will work with your code and the other company's code? Usually this is possible with some assembly binding redirects. I would get this part resolved/understood completely before deciding what to do about managing the details of the build process. I believe that if you do that first you will have a better sense of what you should be trying to change about the build. – David Tansey Jul 27 '19 at 18:17
  • I probably could find a version that could work for both, but I don't want to be dependent on their versions. When I build Project B, I want to be able to just reference Project A. That is, the only thing I want in Project B's `bin` directory is something like `ProjectA.dll`. Not `ProjectA.dll` and all of the dlls required by Project A. I'm looking into disabling copy-local now to see if that gives me any leads –  Jul 27 '19 at 18:23
  • If you find that are able to use the version of `Autofac.dll` that the other company's code depends on, why not "pin" that version in `packages.config` as the version that your code depends on? Then your code expects / depends on the same binary that will get copied from the other company's bin? – David Tansey Jul 27 '19 at 18:30
  • One option is to never copy anything named Autofac.dll. But maybe the solution is simpler? You said you need to copy the files manually, but do you really? Why are you not just using the option to link the .dll's into the project files and order "copy on build"? You can just tell VS "this file is part of the programm. Please allways keep a copy in the output directory. https://stackoverflow.com/questions/4596508/vs2010-how-to-include-files-in-project-to-copy-them-to-build-output-directory-a – Christopher Jul 27 '19 at 18:31
  • I can't count on the company keeping their integration constant. Basically, they ship a batch file and a folder full of dlls. The batch file takes one argument, and that is the path of the `bin` folder of Project A –  Jul 27 '19 at 18:34
  • 1
    I think I've found a decent solution. By right-clicking the reference to `Project B` within `Project A` and setting `Copy Local` to false, dlls from `Project A` are no longer copied to the `bin` directory of `Project B`, so the nuget `Autofac` dll is never overwritten –  Jul 27 '19 at 18:36

0 Answers0