Dependency listed in deps.json not found


(JohnMoshakis) #1

Hi,
I get this error

Error:
An assembly specified in the application dependencies manifest (DependencyConsoleApplication.deps.json) was not found:
package: ‘Newtonsoft.Json’, version: ‘12.0.1’
path: ‘lib/netstandard2.0/Newtonsoft.Json.dll’

When I try and run the attached program

DependencyConsoleApplication.zip (134.2 KB)

Cheers,
John


(marc hoffman) #2

Thats the exact same scenario that you ha din the other thread, where you add to add the package reference explicitly (and reported that it didn’t rebuild), no?


(JohnMoshakis) #3

Yes. You had told me to start a new thread.


(marc hoffman) #4

Yes, but I thought adding the reference fixed the issue — so what’s the remaining problem?


(JohnMoshakis) #5

Well yes adding the reference will fix it but its a bit annoying if I have to do that all the time.

For example Im doing a console app that connects to a postgres db server. Ive added dapper and npsql and Im now getting

john-moshakiss-macbook-pro:debug JohnMoshakis$ dotnet PostgresConsoleApplication.exe
Error:
An assembly specified in the application dependencies manifest (PostgresConsoleApplication.deps.json) was not found:
package: ‘System.Security.Principal.Windows’, version: ‘4.5.1’
path: ‘runtimes/unix/lib/netcoreapp2.0/System.Security.Principal.Windows.dll’


(JohnMoshakis) #6

I think this might relate to https://talk.remobjects.com/t/rebuild-required-when-adding-dependency/18545

So after adding the reference I built a few more times and run from the console and I get the same error.

I then remove the reference, rebuild and run. It’s fixed.

I then modify the code and build a few times, running and the error pops up.

I then rebuild again and it runs fine.


(marc hoffman) #7

So you’re saying that without any (relevant) changes made to the project it its references, this error comes back after a few builds, even though adding the reference originally fixed it? That doesn’t make a lot of sense. does the .deps.json change between when it works and when it starts failing again?


(JohnMoshakis) #8

TwoBuilds.zip (3.3 MB)

Yes

PostgresConsoleApplicationWorking is the starting point. I added Boat.pas to the project and tried to debug. The debugger hung so I restarted and tried to debug again.

I cant dotnet run PostgresConsoleApplication without this error

Error:
An assembly specified in the application dependencies manifest (PostgresConsoleApplication.deps.json) was not found:
package: ‘System.Security.Principal.Windows’, version: ‘4.5.1’
path: ‘runtimes/unix/lib/netcoreapp2.0/System.Security.Principal.Windows.dll’

I cant see any differences apart from the extra file.

The working one should run with an exception because you dont have the file with my database connections.


(JohnMoshakis) #9

Will this be looked into at some point ?

At the moment its impacting my debug sessions. A good number of attempts to launch the debugger end up failing because of this.


(marc hoffman) #10

Probably?


(marc hoffman) #11

Emphasis added:


(JohnMoshakis) #12

No. I compared the 2 in the zip and couldnt see any differences


(marc hoffman) #13

Ok, but if the output is the same, how can some builds work and some fail? That makes no sense. Something else must be changing between builds.


(JohnMoshakis) #14

I compared the bin folders directly in diffview and there is a difference.

I guess it doesnt show differences in sub folders.

The additionalProbingPaths is different

not working

{
“runtimeOptions”: {
“additionalProbingPaths”: [
“/usr/local/share/dotnet/sdk/NuGetFallbackFolder”
]
}
}

and then working

{
“runtimeOptions”: {
“additionalProbingPaths”: [
“/Users/JohnMoshakis/Library/Application Support/RemObjects Software/EBuild/Packages/NuGet”,
“/usr/local/share/dotnet/sdk/NuGetFallbackFolder”
]
}
}

And thats the issue.


(marc hoffman) #15

Ah, oops. that makes sense, it seems the NuGet cache folder path did not get initialized when the reference resolving was skipped, and as such, it wasn’t written into the additionalProbingPaths. Fixed!

The problem was, the issue would only reproduce for packages the didn’t also happen to be in dotnet’s own cache in /usr/local/share/dotnet/sdk/NuGetFallbackFolder.

thanx!
marc


(JohnMoshakis) #16

Will this be in todays build ?


(marc hoffman) #17

Yes. Thank me for accidentally setting the wrong version # and having to trigger a new build, which gave me a chance to merge this in :wink: