2

That's the structure of our solution:

Solution.sln
  WebApp.csproj
    references ClassLibrary
  ClassLibrary.csproj
    references System.Net.Http.Formatting.dll with Copy local = false

When I build the Solution with source code of both WebApp and ClassLibrary, copy local works as expected and System.Net.Http.Formatting.dll is not copied to the WebApp/bin directory.

However, when we distribute our project to the end clients, we give them only the WebApp source code which reference compiled class libraries (.dll). In that case the Solution looks like this:

Solution.sln
  WebApp.csproj
    references ClassLibrary.dll which uses System.Net.Http.Formatting.dll

When this partially compiled Solution is compiled, the System.Net.Http.Formatting.dll is copied to the WebApp/bin folder which is causing us some troubles.

I've examined the detailed build output and dll is copied by the Copy task and the source location for this dll is 

C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 4\Assemblies\System.Net.Http.Formatting.dll

There are some other mentions of the System.Net.Http.Formatting.dll assembly which I don't quite understand.

How to ensure that System.Net.Http.Formatting.dll isn't copied to the bin folder?

Thanks!

jakubka
  • 706
  • 1
  • 9
  • 23
  • One thing you can do is in your **post build** event put something like `del $(TargetDir)System.Net.Http.Formatting.dll /Q /F` – T.S. Dec 03 '14 at 21:03
  • You should first figure out what step in the process is copying the file. – JDługosz Dec 04 '14 at 08:30
  • @T.S. We do not want the dlls in the bin/ folder to allow our customers to put their own dlls in there. Let's suppose we are using System.Net.Http.Formatting.dll in version 2, but our customer wants to use System.Net.Http.Formatting.dll in version 4. That's why we keep bin/ clean and load our versions of dlls from other location. Deleting the file from the bin/ folder would delete also the customer's version. But thanks anyway! – jakubka Dec 04 '14 at 10:55
  • @jdlugosz From the build detailed output, I suppose its this one:Target "_CopyFilesMarkedCopyLocal" in file "C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets". Task "Copy". Does this information help? Thanks – jakubka Dec 04 '14 at 10:57
  • From what you said, sound as you having horrible build and distribution logic – T.S. Dec 04 '14 at 15:14
  • @T.S. I would love to learn how to make it better from somebody more experienced! We run into most issues, because we need the ability to run multiple versions of the same assembly in one web application. We use Web API 1 in our framework, but some of our clients want to use Web API 2 and that's why we move Web API 1 away from bin. Do you know of an easier way to achieve what we need? Thanks! – jakubka Dec 04 '14 at 15:43
  • I am sure 100% that your problem is easy to solve. All you need is to separate your build and distribution process. You can create multiple configurations and in **pre-build**, you can do something like `if thisConfig XCOPY...` - copy version that you want for that build configuration. When you said "Deleting the file from the bin/ folder would delete also the customer's version" I am wondering how can you delete customer version? You only deleting a copied file. You can delete and then copy as many times as needed to bring your package to desired state. You can use compilation variables to... – T.S. Dec 04 '14 at 17:09
  • have code compile differently depending on the version of referenced assemblies you build. – T.S. Dec 04 '14 at 17:10
  • So the files appear during the `Target "_CopyFilesMarkedCopyLocal`? So now we know it's not something else deciding to copy them for other reasons. If you're using the MSBuild command line, you can run the `Copy` task directly, and use flags such as `/v:d` (or even `/v:diag`) and redirect the spew to a file. That can probe what the metadata *really* is, and what decisions were being made. However... – JDługosz Dec 04 '14 at 19:05

1 Answers1

1

It looks like the copylocal notation is in a project file that's not being read by the customer, so how would it know? You could add the references directly to the project file they do have, rather than letting them be discovered through transitive dependencies. Then you can mark them as no-copy-local. I think adding them as refs to WebApp.csproj should do the trick completely within the GUI. Start with that, and then fiddle with the XML if it's not quite good.

JDługosz
  • 5,592
  • 3
  • 24
  • 45
  • Exactly.. I have the same feeling that "copy local" is not being transferred through transitive references.. I am going to try the trick with referencing those dlls directly and see what happens. Thanks – jakubka Dec 05 '14 at 11:43
  • Not *transferred*, as there is no indication anywhere to find. It's not incorporated into the dll. How about accepting the answer; or is there still some issue? – JDługosz Dec 05 '14 at 19:32
  • Yep.. Tomorrow, I am going to try adding references directly to the web application project as you suggested and if its gonna help, I will mark the answer as correct. Otherwise, we will have to think about some other solution. :) One more time: thanks a lot for your help! – jakubka Dec 07 '14 at 21:53