Reputation: 95
I'm trying to build a data access service as a .NET Core 3.1 class library, then make it a nuget package that can be reused in different solutions without having to scaffold the database and build repository classes in every solution.
The class library code is tested and works fine, but then the nuget is installed in another solution, this error is thrown when methods in the data service are invoked:
System.IO.FileNotFoundException: 'Could not load file or assembly 'Microsoft.EntityFrameworkCore, Version=5.0.4.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified
Obviously, the solution using the nuget, or the nuget itself is missing a dependency to EntityFrameworkCore, but I'm not sure which, and why.
When lookin at the DataService.dll in solution explorer from the solution where I installed the nuget, it doesn't show any dependencies for that .dll, which it does with other installed nugets. I've made sure that nuget restore is run by the deploy pipeline (using Azure DevOps to release the nuget) and as far as I can see, it is fetching all EFCore dependencies.
Azure DevOps generates this in the .nuspec:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<id>SoRDataAccess</id>
<version>1.1.4</version>
<authors>VssAdministrator</authors>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Description</description>
<dependencies />
</metadata>
</package>
Has anyone done this successfully or know that it should be possible. I'm starting to worriy that this might not be possible to do with EFcore, but I haven't found anything to confirm that.
Upvotes: 0
Views: 664
Reputation: 21729
Often when using devops products such as Jenkins or Azure DevOps, when the build server and/or build agents aren't fully updated or are updated but not fully, you can get issues like this.
It looks like your pipeline needs to be reconfigured.
When this happens, take a look at the numbers -- specifically version numbers. When they seem amiss this is a sign that something is not right. In your case you stated you were doing a .NET Core 3.1 build, but EF 5.0.4.0 is being looked for. While versions don't have to match, pragmatically they tend to.
Anecdotally, this has happened to me many times throughout my software dev career. Most recently, this happened when we began supporting .NET Core 3.1 over .NET Core 2.2. It becomes apparent pretty quickly when the builds work on your machine but not on the build server!
Essentially, every part of your pipeline needs to correctly handle these aspects: pull from source control, pull from configuration repositories (e.g. NuGet), build in context, and publish.
Upvotes: 0
Reputation: 32703
You should be able to create your own .nuspec, and then package that up.
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
<metadata>
<id>MyPackageId</id>
<version>$version$</version>
<title>My Package Title</title>
<authors>My Company Name</authors>
<owners>My Company Name</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>A description of our package</description>
<copyright>Copyright 2021</copyright>
<dependencies>
<group targetFramework=".NETStandard2.0"> <!-- Libraries *should* target .NET Standard in most cases -->
<dependency id="SomeOtherNugetPackageInSameSolutionThatShouldHaveSameVersion" version="$version$" />
<dependency id="Microsoft.Azure.ServiceBus" version="4.1.1" /> <!-- Specify your external dependencies and their required version here -->
</group>
</dependencies>
</metadata>
<files>
<file src="bin\$configuration$\netstandard2.0\MyLibrary.dll" target="lib\netstandard2.0" />
</files>
</package>
When you build the package in Azure DevOps, you should be able to check a box to have it replace $version$ with the version. Otherwise you can hardcode it. Depends on how your team does versioning.
The important part is the <dependencies>
section.
Upvotes: 1