Implicit references

Elements EBuild
1

I have a lot of implicit references in a project.

It looks to me as though they are coming from another referenced project in the solution. That is marked as copy local, shouldnt the build also treat the implicit references as copy local ?

28%20PM

SailingLog.Modules is my project reference. Its also appearing as an implicit reference. Serilog.Sinks.MsSqlServer is a reference of SailingLog.Modules which is copy local. When I run the console app it complains about the sinks file because its not there.

Also if I added nuget myself shouldnt that automatically be copy local ?

Thanks,
John

2

this sounds like an IDE bug, failing to map reference entries in the project to the actual resolved references, thus showing the resolved ones as dupes. can i see a testcase?

Background: after asking EBuild to resolve references, Fire compares the list, looking for ay references that EBuild added that do not match up with one in the project. This should normally only ever happen for stuff like mscorlib or System.Core, which (on .NET) always get added, whether your project specifies them or not.

In your case, at least some of the ones sowing (SailingLog.Data, eg) clearly are in the project, but apparently for some reason they don’t get matched up, I need two find out why. The serilog.exceptions one probably fails because of the case mismatch, but the rest I cannot explain w/o having a look at the concrete thing.

3

Hmm, maybe the CopyLocal flag should be set by default when adding them, yeah. I’ll make it do that.

1 Like
4

I worked it out.

  1. Create a echoes consoleapplication
  2. Add a echoes class library to the solution.
  3. By dragging add the class library as a reference to the console app
  4. In the settings of the console app set the target framework. ie 4.6.2 It now shows 2 references, one implicit.

31%20PM
Screen Shot 2018-05-14 at 9.40.31 PM.png1217Ă—654 103 KB

Close the solution and reopen and its back to normal.

26%20PM
Screen Shot 2018-05-14 at 9.42.26 PM.png415Ă—603 47.7 KB

5

Nope :frowning:

41%20PM
41%20PM2490Ă—1600 552 KB

from your steps (setting the framework version) I would have assumed it’s the reload of references triggered by that that causes it. doesn’t happen here though — there must be more to it…

6

Wait, does repo after it was build. not consistently, but there seems to be more fishy with the project ref resolving. will investigate…

7

Got it!

this was a nasty one. it wasn’t actually a bug in the reference matching; it was a race condition that only happened if you changed the (legacy) TargetFrameworkVersion setting, not TargetFramework. The problem was that changing the former updates the latter, which translates to two settings changes and triggered two reloads of the references in quick succession (which in turn messed up the match of there first resolve as the second changed stuff under its foot ;).

fixed

  • the actual race condition
  • that changing the property triggers two reloads

and also

  • that changing this setting, while doing a re-resolve, did not actually use the new settings to re-resolve, thus ended op giving you the same-version refs as you had before :wink:
  • that selecting a version that doesnt exist locally (eg “4.8”) would pick a random version rather than the closest matching one (eg “4.5” instead of “4.7.1”).
  • that setting TargetFramework now not only sets TargetFrameworkVersion, but also clears TargetFramework again, avoiding dupe (and potentially later contradictory) settings to persist in there project file.
1 Like
8

Thanks. This is fixed.

1 Like