Could not load file or assembly or one of its dependencies. Reference assemblies should not be loaded for execution

Elements EBuild
21

Fixed, I believe, can you retest with the next build?

22

The solution I posted a link too looks good.

23

DataFlowConsoleApplication.zip (36.3 KB)

I get Package ā€˜System.Threading.Tasks.Dataflow:4.9.0ā€™ has no deliverable for platform ā€˜net 4.7ā€™. with the attached project.

It worked before.

24

I also get

Package ā€˜NLog:4.6.3ā€™ has no deliverable for platform ā€˜netcoreapp 3.0ā€™.

Im not sure it its related.

25

Probably. Iā€™ll check what those two do, in a bit (out of office for the first few hours, this morning).

26

I canā€™t win here :frowning:

that package as only a lib folder, and only for

netstandard1.0
netstandard1.1
netstandard2.0

I dont fall back to netstandard2.0 for lib, when building net4x anymore. if I change that, the original issue is broklen again, because System.Buffer has a lib folder for netstandard2.0, and weā€™ll be deploying that version of the System.Buffer.dll again.

Not sure what to do here! :(.

The current behavior comes as close to ā€œas designedā€ as I can think of.

Does this package bundle in VC#? does it reference and copy the .dll version from netstandard2.0? If so, then why doesnā€™t System.Buffers also do that?

27

One last idea I have, would be ti allow fallback on lib if and only iof there was no ref folder at all. With that, both projects work (but iā€™m sure weā€™ll find a new one that fails). Iā€™ll go ahead and commit that change and weā€™ll see what goes.

But seriously, what drugs did the people who designed this package format take, and where do I get them?

28

It looks like it. The debug folder has 97 dlls.

29

New build is up.

30

97, just from the one package?

I get just

D: DataFlowConsoleApplication.exe (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Obj/DataFlowConsoleApplication-63944B0BC324E38B664110122178A5C089F4E7F5/Release/Echoes/DataFlowConsoleApplication.exe)
D: System.Threading.Tasks.Dataflow.dll (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/system.threading.tasks.dataflow/4.9.0/lib/netstandard2.0/System.Threading.Tasks.Dataflow.dll)
D: System.Threading.Tasks.Dataflow.xml (/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet/system.threading.tasks.dataflow/4.9.0/lib/netstandard2.0/System.Threading.Tasks.Dataflow.xml)

and the package has no other dependencies (for full .NET) that should be pulled in, from looking at itā€¦

31

I meant in visual studio. With 4.7 it pulls in .net standard. Anything less than 4.6.1 just pulls in System.Threading.Tasks.Dataflow.dll

32

:exploding_head:

33 
  <dependencies>
      <group targetFramework=".NETFramework4.5" />
      <group targetFramework=".NETStandard1.0">
        <dependency id="NETStandard.Library" version="1.6.1" />
        <dependency id="System.Dynamic.Runtime" version="4.3.0" />
      </group>
      <group targetFramework=".NETStandard1.1">
        <dependency id="NETStandard.Library" version="1.6.1" />
        <dependency id="System.Dynamic.Runtime" version="4.3.0" />
      </group>
      <group targetFramework=".NETStandard2.0" />
      <group targetFramework=".NETPortable4.5-Profile259" />
      <group targetFramework="Windows8.0" />
      <group targetFramework="WindowsPhone8.0" />
      <group targetFramework="WindowsPhoneApp8.1" />
    </dependencies>

thereā€™s literally nothing here thatā€™d say to pull in .NET Standard dlls, when building for 4.7 (and not lower). Plus, that would/should break everything.

34

Yes its weird.

If you look at this

Is is because from 4.6.1 which supports .net standard 2 so it goes down that path instead ?

35

well

<group targetFramework=".NETStandard2.0" />

if anything I could see why itā€™d pull in .NET Standard 1.1 when below 4.6.1, because

<group targetFramework=".NETStandard1.1">
    <dependency id="NETStandard.Library" version="1.6.1" />
    <dependency id="System.Dynamic.Runtime" version="4.3.0" />
  </group>

but literally even for .NET Standard 2,.0 this package has no dependencies

(that said, only ONE dependency group should be applied, and thats .NETFramework4.5 here. which also has no dependencies:

<group targetFramework=".NETFramework4.5" />
36

In any case, Iā€™m happy to just ignore what VS does here, as long as the original issue is fixed in the new build, in my tests, all three scenarios should be covered now. (until we find a new project that has yet. different constellation of whats in ref and lib, tomorrow :wink:

37

The SailingLog solution I keep sending you builds now. I think thatā€™s a good test case :slight_smile:

1 Like
38

Why did you think this ?

It does look as though thats what visual studio is doing.

39

Sorry, this thread has devolved in so many bits that I canā€™t really answer this. Can you make a new post with a clean test case that shows the remainng/new problem? thanx!

40

Sorry. I was just going back over previous problems. The ā€œChild referencesā€ post is my latest, is the test case ok ?