77

I upgraded Microsoft.AspNetCore from 2.0.3 to 2.0.5 and my WebAPI project, although running successfully locally, fails to start in production (IIS). Everything was fine in production until this upgrade. The error message produced in the log directory is as follows:

Error:
  An assembly specified in the application dependencies manifest (MyProject.WebAPI.deps.json) was not found:
    package: 'Microsoft.AspNetCore.Mvc.Abstractions', version: '2.0.2'
    path: 'lib/netstandard2.0/Microsoft.AspNetCore.Mvc.Abstractions.dll'

  This assembly was expected to be in the local runtime store as the application was published using the following target manifest files:
    aspnetcore-store-2.0.5.xml

Could someone explain to me the details of exactly what this means? I assume it's a version mismatch of sorts, but why is this occurring? I thought the latest stable releases of NuGet packages weren't supposed to have such issues.

I was able to resolve the issue by downgrading Microsoft.AspNetCore.All from 2.0.5 to 2.0.3, but would like to find a better solution to the issue so I can use the most up-to-date version of this package.

KSwift87
  • 1,843
  • 5
  • 23
  • 40

13 Answers13

106

Development machines usually have the SDK installed but on production the runtime only.

Add the following to your .csproj file and publish again.

<PropertyGroup>               
    <PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>
Steve Tolba
  • 1,417
  • 1
  • 10
  • 11
  • 4
    What exactly does adding that property do? Does it make the SDK install on the target machine? How does it make my packages use the latest version or what-have-you? – KSwift87 Feb 21 '18 at 20:34
  • 13
    It will export the DLLs required to run if the SDK is not installed. You will notice that your published folder size has increased and more files in it. – Steve Tolba Feb 22 '18 at 03:05
  • 1
    Related: https://github.com/dotnet/cli/issues/6516#issuecomment-299313448 – NightOwl888 Feb 22 '18 at 13:20
  • 4
    an interesting alternative https://www.benday.com/2018/02/23/force-dotnet-publish-to-publish-dependencies-using-publishwithaspnetcoretargetmanifest/ – tony09uk Aug 13 '18 at 13:13
  • I was getting this in my local machine but adding this fixed it. Thanks. – Sachin Parashar Mar 27 '19 at 14:09
  • 1
    FYI after upgrading to .net core 2.2 I no longer need the PublishWithAspNetCoreTargetManifest tag. – Endy Tjahjono Aug 18 '19 at 09:20
  • This does not have any effect on the output files in my published folder. I am publishing via `MSBuild.exe /p:DeployOnBuild=true /p:PublishProfile=FolderProfile /p:Configuration=Release` and relevant FolderProfile settings: `SelfContained=true`, `PublishSingleFile=false`, `PublishReadyToRun=false`. – Martin Schneider Oct 05 '21 at 16:31
13

Sometimes this is related to the Startup Project, For example if the migration is a class library in Azure Functions project. You have to make sure when you run Add-Migration while the EF Library project is selected as Startup Project.

Jirapong
  • 24,074
  • 10
  • 54
  • 72
  • 1
    This was the problem for me, setting the startup project to the project in which I tried running the command resolved it. – Nicklas Møller Jepsen Jan 20 '20 at 05:17
  • This worked for me - it needs more upvotes! – ilikeprogramming Jun 18 '22 at 12:02
  • Worked for me too. I had 2 projects: Main app and Web API. Main app was a MAUI app and the DLL it complained about was Maui, which didn't make sense because I wanted the migrations in my Web API project. As soon as I made the Web API project the startup project, it worked perfectly. Selecting the project in Package Manage Console was not sufficient. – Joe Mayo Aug 12 '23 at 04:52
13

I know this may be old, but just in case it can help some one else, this one worked for me:

Adding: <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>

To the PropertyGroup in the .csproj file.

Leibniz
  • 184
  • 1
  • 5
  • 4
    I am in love with you! Saved my day. – Teddy Oct 16 '22 at 06:33
  • 2
    This error was coming up for me when i used `dotnet test`. I added this to the csproj files of my tests projects it fixed it – DLeh Mar 27 '23 at 21:11
  • This worked for me as well. Here is MS documentation on this config https://learn.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#copylocallockfileassemblies – AGDevX Jun 07 '23 at 12:44
  • 1
    Worked for me too. I also set false for my .net5.0 daemon process which builds to a console app that does load System.Drawing.Common 6.0.0. runtimeconfig.json and deps.json needed copying into my distro bin dir, along with the rumtimes/win/lib subtree created when CopyLocalLockFileAssemblies is in play. – osullivj Jun 28 '23 at 14:13
7

For me, the marked answer didn't solve the issue. My issue was when trying to Add-Migration

Add-Migration -Name initial-migration -Context Mysln.Data.MyDbContext -StartupProject Mysln -Project Mysln.Core

And the error was like this: enter image description here

I solved it by downgrading all my Entityframework packages to 2.0.0 instead of the latest 2.2.0-preview one.

dev.e.loper
  • 35,446
  • 76
  • 161
  • 247
Marzouk
  • 2,650
  • 3
  • 25
  • 56
  • What was the error you got? Same as the one in question? – Ensar Turkoglu Nov 26 '18 at 20:16
  • 1
    As shown in the image, it's same as in the question – Marzouk Nov 27 '18 at 09:41
  • @nsarchar Sorry till now i can't understand your comment and your point of view ? – Marzouk Nov 27 '18 at 17:39
  • 1
    I had the same error as Marzouk, however it was solved by stating the project as one of the options when running add-migration (or dotnet ef migrations add in my case) – John_ Mar 12 '19 at 21:05
  • 4
    @Marzouk I was trying with the latest dependencies I followed this post and it worked https://dev.to/azure/using-entity-framework-with-azure-functions-50aa .Quoting from the original post"When you build an Azure Functions project, Microsoft.NET.Sdk.Functions does some organizing of the build artifacts to create a valid function project structure. One of the .dlls it moves to a sub-folder is the project .dll. Unfortunately, for the design-time tools like entity framework migration, it expects the .dll to be at the root of the build target" – Charanraj Golla Mar 14 '20 at 04:27
6

If you have more than one project in your solution like me:

enter image description here

and if you want to scaffold dbcontext in your "non startup" project (InstantOrder.Functions.Data in my case) then you should add the -StartupProject parameter of the Scaffold-DbContext command like this - 

Scaffold-DbContext "Server=..." -Project InstantOrder.Functions.Data -StartupProject InstantOrder.Functions.Data
MegaMilivoje
  • 1,675
  • 2
  • 14
  • 15
5

To solve the first half of the error message, An assembly specified in the application dependencies manifest (…) was not found be sure to always use the publish output when deploying to a target sever.

For a self-contained application it can be found in

bin\Release\netcoreapp2.0\win81-x64\publish

or for framework-dependent deployments in

bin\Release\netcoreapp2.0\publish

The output in the directories above are meant to be used in development only, since they are specific to machine and user configuration built with.

Taken from a related answer.

Sean Saleh
  • 460
  • 5
  • 17
3

2 cents: If you just take from the build folder, the dlls for the dependency aren't provided. If you publish the folder, they are. This was the fix for me.

mattylantz
  • 312
  • 4
  • 10
2

I had this error however my solution was somewhat different from what was posted above. My problem was that I was deploying via a zip file and while building the zip file I wasn't including sub directories therefore required files were not being included.

So if you are publishing via a zip file make sure to include all sub folders while building the zip.

zgirod
  • 4,189
  • 3
  • 28
  • 36
2

I got this error while running Scaffold-DbContext command on the Library project.

Solution:

  1. Remove the Azure Function project from the solution, and then run this command.
  2. After that, use add an existing project feature to add the Azure Function project again in the solution.
Ankush Jain
  • 5,654
  • 4
  • 32
  • 57
  • I had a similar issue in WinUI project while running 'add-migration'. I used your approach, like removing the WinUI app from the solution and running the 'add-migration' and 'update-database'. Then add back the WinUI projects to the solution. – Shiva N Mar 08 '22 at 11:51
1

The correct .NET Core runtime was not installed on my PC. I had NETCore.App 2.1 and 2.2, but the project was targeted to 2.0.

dotnet --list-runtimes

I installed the correct runtime from the dot.net site and it resolved the issue.

Der_Meister
  • 4,771
  • 2
  • 46
  • 53
1

I changed filters in Yaml.

Had projects called TestHelper etc... Testrunner tried to run projects without tests, and the build was flagged as failed.

Added:

 !**\*Helper*.*

To:

- task: DotNetCoreCLI@2
  inputs:
    command: 'test'
    projects: |
      **\*test*.dll
      !**\*TestAdapter.dll
      !**\obj\**
      !**\*TestPlatform*.dll
      !**\*Testing*.*
      !**\*TestHost*.*
      !**\*Helper*.*
Per G
  • 375
  • 1
  • 4
  • 18
0

In most case you get that error because there's misalignment of versions.

I changed the Microsoft.VisualStudio.Web.CodeGeneration.Design version, an it worked.

Before

<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="3.1.0" />

After

<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="2.2.4" />
H. Pauwelyn
  • 13,575
  • 26
  • 81
  • 144
Sydney_dev
  • 1,448
  • 2
  • 17
  • 24
0

This happened to me when I published my Lambda to AWS after renaming the project. I deleted both the obj and bin folders, rebuilt, republished and that fixed it.

C.M.
  • 1,474
  • 13
  • 16