Copy local not being respected

(JohnMoshakis) #1

I’m not sure if this is Fire or not but copy local isn’t being respected.

I have an Echoes project which references Rabbitmq.Client from nuget

42 PM

And this is all I see in the Debug folder.

57 PM


(marc hoffman) #2

Yeah. CopyLocal and NuGet is a bit in flux, I wasn’t sure how to best handle that (before, all NuGet-gathered references were copy-located, but that created a mess on, say, .NET Standard, so I disabled that (btw, .NET Standard should work a lot better in .2235). I didn’t think of tis before, but yeah, I think the best option will be to let you set/unset Coy Local on the NuGet reference itself, and have the “real” references inherit that. I’ll fix that Monday.


(marc hoffman) #3

One question remains: (how) should dependency packages inherit CopyLocal? Say you reference “Foo:1.0”, and you set it to copy local. it pulls in “Bar:1.5” and System.IO:4.3", say. Surely the latter should not be come copy local. What about the former? Ok if it does not become copy local unless you add an explicit reference?

(JohnMoshakis) #4

I think it should inherit.

I create a mono console app targeting 4.6.1 and referenced that. Its pulled in its dependency Microsoft.Diagnostics.Tracing.EventSource.Redist and put in in the debug folder with the rabbit assembly.

Why do you think dependencies shouldnt be copy local as well ?

(marc hoffman) #5

But even if they are system APIs? Your example package pulls in all of these:

NETStandard.Library (>= 1.6.1)
System.Collections.Concurrent (>= 4.3.0)
System.Console (>= 4.3.0)
System.Diagnostics.Debug (>= 4.3.0)
System.Diagnostics.Tracing (>= 4.3.0)
System.IO (>= 4.3.0)
System.Linq (>= 4.3.0)
System.Net.NameResolution (>= 4.3.0)
System.Net.Security (>= 4.3.0)
System.Net.Sockets (>= 4.3.0)
System.Reflection.Extensions (>= 4.3.0)
System.Reflection.TypeExtensions (>= 4.3.0)
System.Runtime (>= 4.3.0)
System.Runtime.Extensions (>= 4.3.0)
System.Text.RegularExpressions (>= 4.3.0)
System.Threading (>= 4.3.0)
System.Threading.Thread (>= 4.3.0)
System.Threading.Timer (>= 4.3.0)

should they ALL be copy-localed?

(JohnMoshakis) #6

It doesnt if you target 4.6.1 with mono.

58 PM

(marc hoffman) #7

Right, but ti does for .NET Standard, according to the dependency list on the page…

(marc hoffman) #8

in any case, 20171225-174117-elements-develop has the first part of the fix, honoring the Private flag on the root for any dlls added by it. (next Fire will let you toggle it in the UI, too).

Update: 20171225-200638-elements-develop will also inherit Copy Local for dependencies. Lets see how it plays out.

(JohnMoshakis) #9 (483.8 KB)

This is what I have been working on.

Should Fire be showing the


reference ?

Im also using the latest develop, should the Rabbit assembly be copied to the debug folder ?

(marc hoffman) #10

not sure what you’re asking. are you seeing one that should not be there, or missing one that should be? I only see rabbitmq.client:[5.0.1], resolved to a single .dll shoes below it. But I also don’t see Microsoft.Diagnostics.Tracing.EventSource.Redist being referenced explicitly. So (without digging deep into the nuspec to check), all looks fine to me.

it’s not marked as Copy Local (Private) in the project, so no. if you change it to

    <NuGetReference Include="rabbitmq.client:[5.0.1]" >

then it should, and does for me:

               Final Output:
                 Elements.dll (/Users/mh/Downloads/Rabbit/Receive/bin/Debug/Elements.dll)
                 RabbitMQ.Client.dll (/Users/mh/Downloads/Rabbit/Receive/bin/Debug/RabbitMQ.Client.dll)
                 Receive.deps.json (/Users/mh/Downloads/Rabbit/Receive/bin/Debug/Receive.deps.json)
                 Receive.exe (/Users/mh/Downloads/Rabbit/Receive/bin/Debug/Receive.exe)
                 Receive.exe.mdb (/Users/mh/Downloads/Rabbit/Receive/bin/Debug/Receive.exe.mdb)

(JohnMoshakis) #11

I’m missing one that should be.

In vs for mac I see this. Also if you attempt to uninstall it says Rabbit depends on it.

(marc hoffman) #12

hmm, I see whats going on. Last week, I changed dependencies to be tried to strict versions, because otherwise building for .NET Standard 2.0 would pull in all sorts of dupe dependencies for older .NET Standard versions, and everyone was sad.

the Rabbit package has tis dependency:

      <group targetFramework=".NETFramework4.5.1">
        <dependency id="Microsoft.Diagnostics.Tracing.EventSource.Redist" version="1.1.28" exclude="Build,Analyzers" />

and since your project is set to 4.6.2, this now does not get matched up, “as expected” by the above change.

I’ll need to rethink/review the exact logic for deciding how to match the targetFramework version in the dependencies section against the projects’. :(.

workaround for now: add the package as direct NuGet reference, manually.

(marc hoffman) #13

Fixed for 20171226-173538-elements-develop.

(JohnMoshakis) #14

Is the 173538 a timestamp ?

I see 161128, so would that mean Im waiting for this one to arrive ?

(JohnMoshakis) #15

That didnt go so well. I now have this

It looks like its pulling in .net standard

(marc hoffman) #16

yeah, UTC,

(marc hoffman) #17

hmm. with your project as you sent it to me earlier? i used that as a testcase and it was fine…

(JohnMoshakis) #18


I used 20171226-191117-elements-develop-removeoldcg is that ok ? What does removeoldcg mean ? (12.9 KB)

Thats the build output.

(marc hoffman) #19

Oh. That’s a different branch, probably a bit behind the main one. You want a pure “develop” branch build. But it looks there isn’t one coz it seems that I broke something… :wink: … fixed, I hope, for 20171227-022056-elements-develop thats started to build now.

(JohnMoshakis) #20

Thanks. Its building now.