search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.13k stars 4.7k forks source link

F5 Debug issue: An assembly specified in the application dependencies manifest was not found #9738

Closed LazerFX closed 4 years ago

LazerFX commented 6 years ago

I have spent a few days trying to figure out why F5 debugging doesn't work. I believe I have an idea, however I don't know how to fix it, hence posting here for assistance.

I have a .NET Core 2.0 application that has a UI project, a Service project and several DLL projects. The UI project has been created by doing a dotnet new aurelia. I'm using ReSharper, so have added the JetBrains.Annotations version 11.1.0 NuGet project to the package.

When I attempt to F5 run, I get the message:

IDAMock.UI> Error:
IDAMock.UI>   An assembly specified in the application dependencies manifest (IDAMock.UI.deps.json) was not found:
IDAMock.UI>     package: 'JetBrains.Annotations', version: '11.1.0'
IDAMock.UI>     path: 'lib/netstandard1.0/JetBrains.Annotations.dll'
IDAMock.UI>

I've tested, and this happens whether I am launching Project, IIS or IIS Express. If I do a dotnet run from the command prompt, it launches http://localhost:5000 and correctly runs. If I publish to IIS, it runs. It appears to be only the IIS Debugging handler that is triggering this issue. Of course, if I remove the JetBrains.Annotations reference, then it works - but that's not a long term solution, as there will be other NuGet packages that I'll want to reference.

I've tried changing the value of <PublishWithAspNetCoreTargetManifest> in the .csproj, which doesn't appear to change the results.

I found that the DLL was being output to ./Debug/netcoreapp2.0/PubTmp/Out, and copied from there to the ./bin/Debug/netcoreapp2.0 folder, which temporarily resolved the issue.

For now, I'm going to add a post-build task to do this copy manually, but this isn't a permanent solution. How can I resolve this in a non-hacky manner? It only affects debugging, not deployment, but it's proving quite debilitating.

LazerFX commented 6 years ago

As an update, so far this is affecting:

So far, the common theme I'm referencing is these are all debug- and compile-time DLLs, not normally deployed with the application (Although, the NSwag Swagger UI is deployed, I'm primarily using it to auto-generate TypeScript client classes).

jkotas commented 6 years ago

This issue was moved to dotnet/cli#8622