add-migration causing a "Could not load assembly" error - entity-framework

Here's what I am looking at
PM> Add-Migration AddedSubdivion -StartUpProjectName Data -Verbose
Using StartUp project 'Data'.
Using NuGet project 'Registry'.
Could not load assembly 'Registry'. (If you are using Code First Migrations inside
Visual Studio this can happen if the startUp project for your solution does not
reference the project that contains your migrations. You can either change the startUp
project for your solution or use the -StartUpProjectName parameter.)
I have no idea why it's trying to reference the Registry project. Registry depends on Data, not the other way around. I am very new to this, so I'd appreciate any help.

This is embarrassing, but maybe this will help out a googler in the future.
At the top of the "Package Manager Console" my default project was set to the wrong project. Changing that to my models project fixed it.

This can also be caused by a platform mismatch between .NET Core and your project. You get the error:
Could not load assembly 'DataProject'. Ensure it is referenced by the startup project 'ProgramProject'.
even though you have specified correct project and startup project names. (Either by using the drop down boxes in VS and the Package Manager Console, or by using the -project and -startupproject parameters.)
You can fix it by switching to Any CPU instead of x86, or vice-versa (or maybe to x64, etc.), but then you will have to switch back and forth every time you need to make changes to your model/DB.
As per this answer you can fix this by changing the order of your .NET Core path entries in system environment variables. If you're getting this error, then it means that either the first .NET Core path is for x64 but you're trying to make changes to your x86 project, or possibly other way around. Move the one you're targeting above the one you're not targeting, save, and then restart Visual Studio.
You can see which one is currently being used with the command dotnet --info.
(Note that this assumes you've installed both. You may also only have one of them installed, in which case you'd need to install the other one, and then check the order of the PATH entries; if the second one you installed is the one you want, then you will definitely need to change the PATH order to make it the one used by VS, since its entry should be at the bottom.)

The problem might not be so obvious if you have Package Manager Console docked with a narrow window...hiding the default project.
Its needs a wide docking.

If all fails there's always the verbose flag (-v).
A command like dotnet ef database update -v should help clarify the problem ef is facing.
In my case, the issue stemmed from EntityFramework finding it difficult to deal with the fact that my platform target was changed from AnyCPU to x86 or x64.
System.BadImageFormatException: Could not load file or assembly 'MyProject, Culture=neutral, PublicKeyToken=null'. An attempt was made to load a program with an incorrect format.
Temporarily changing the platform target to AnyCPU worked just fine.

Make sure that you are focused on:
1- Startup Projects is UI (MVC, API, ... etc).
2- Default project in package manager console is place of (ApplicationDbContext).

I would like to add, if you are using .net6 preview, you will need to update the packages.
so you will need to use the preview versions EntityFrameworkCore.Tools and EntityFrameworkCore.SqlServer (6.0.0-rc-1.21452.10 version as of today)

I had this exact problem, and it turned out because I createdthe project under a blank solution and then added the class libraies and web app seperately it didnt have a start up project.

None of these worked for me. I temporarily unloaded the unrelated project from the solution, ran the command, and then loaded the project back in.

I've got this issue migrating an Asp.Net 5 to Asp.Net 6.
The problema was in the .csproj file.
This configuration
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<PlatformTarget>x86</PlatformTarget>
</PropertyGroup>
I've just removed this property group and the dotnet ef worked

This can also be caused by a platform mismatch between .NET Core and
Also check this in your packages
if don't have that package Dependency Injection
Its very simple you have to install dependency injection package

The package manager window has a Default Project Property.
Setting the default project in the package manager window fixed this for me.
I also had to set the startup project to the same application in the solution explorer.

You should define 2 constructor and OnConfiguring method in context.cs. And also in your UI layer you should define connection string.
Like this:
In Context.cs :
public Context()
{
}
public Context(DbContextOptions<Context> options) : base(options)
{
}
protected override void OnConfiguring(DbContextOptionsBuilder
optionsBuilder)
{
if (!optionsBuilder.IsConfigured)
{
optionsBuilder.UseSqlServer("Data Source=..");
}
}
In appsetting.json:
"ConnectionStrings": {
"SqlServer": "Data Source=....."
}
In Program.cs:
builder.Services.AddDbContext<Context>(opt =>
{
opt.UseSqlServer(builder.Configuration.GetConnectionString("SqlServer"));
});

Set the target project for the migration as the startup project and continue

Related

There was an error running the selected code generator: 'Scaffolding failed. The path is empty. (Parameter 'path')' in VS 2022

Project type is asp.net MVC core. Adding a Razor View with or without Model I receive the following results:
There was an error running the selected code generator: 'Scaffolding failed. The path is empty. (Parameter 'path')'
Using VS2022 17.0.4 targeting .net 6.0 EntityFrameworkCore 6.0.1
I tried some of the remedies from the question that pops up on SO for VS2013:
cleaned out bin and obj folders and rebuilt
verified that all projects with EntityFrameWorkCore had the same version
BTW, adding a controller works.
Any help or guidance would be welcomed. This is a show stopper.
EDIT: I noticed that some or all of the projects in the solution were corrupted so I recreated project from scratch. I was able to add two views and then I received the message as above, again. Also, as I was building the project again I tested by adding a Razor view before I made any changes to the template generated project (asp.net core MVC) and it worked.
Something is corrupting one or more of my projects, and I think it might be NuGet. Any help would be greatly appreciated. I will now go rebuild the project from scratch for a third time and observe better and more frequently as to when the add Razor view fails.
I solved this issue by uninstalling the nuget package: Microsoft.AspNetCore.Identity
Reference
I got this error today while adding the Identity Scaffolded item to my existing Blazor server project.
I tried to add Identity Scaffolded item after updating the EF Core packages to 6.0.9 but unfortunately there seems to be some issue in the latest EF core packages.
So, I rolled back the EF Core packages from 6.0.9 to 6.0.8 and everything worked fine.
When I was recreating the solution from scratch I found the culprit. ME!
I do not like the new style of Main entry points where the code just starts without a namespace or class definition such as follows:
namespace MyNamespace
{
public static class MyClass
{
public static void Main(string[] args)
{
}
}
}
So I rewrote the class Program and created Startup and attempted to refactor all the code from Program. Obviously I did not do well. This caused my problem with the failed add of a templated Razor view.
download all packages the same version and cleaned up obj and bin file and rebuild your project. It worked for me
I was having the same issue and tried everything I could find to resolve it. - Made sure project would compile. Made sure all NuGet packages were the same version - 7.1. Looked for references to Microsoft.EntitiyFramework.Identity.
- No love.
Then I ran the latest Visual Studio updater to 17.4.3, I don't recall the version I as on, and we're good to go!

EF Migration: Could not load assembly. Ensure it is referenced by the startup project after switching from x64 to x86

After switching the all the projects to x86 architecture, I get the following error:
> dotnet ef migrations add Nullable-Fields --startup-project ..\LairageScanner.BlazorApp
Build started...
Build succeeded.
Could not load assembly 'LairageScanner.Context.SQL'. Ensure it is referenced by the startup project 'LairageScanner.BlazorApp'.
As seen above I have tried to run the command through CMD - but also done this for the package manager. I have seen some suggestion to fix this error: Stack Overflow & GitGub but neither of them had the solution to my issue.
Current Stack:
EF Core 3.1.3
Dotnet Core 3.1
Note: From the Git Solution it suggest converting to x64 and then just converting back later. And it does work. But I am looking for a more permanent solution.
I fixed it once with a simple action.
You need to be sure that the Startup Project is the one with the startup.cs file. Also, be sure that all Project references are complete.
Well, it worked for me.
Select the layer where the dbcontext class exists

AutoMapper 6.2.2 restore fails on VSTS build server

The Restore step fails in my build definition with this error:
error NU1100: Unable to resolve 'AutoMapper (>= 6.2.2)' for '.NETCoreApp,Version=v2.0'.
This is in a .NETCoreApp 2.0 that is using AutoMapper. Restore succeeds locally in VS 2017. Locally I am using dotnet sdk 2.0.0, and nuget 4.3.1. On the VSTS (cloud) server, I am specifying the latest nuget version, 4.5.0. I have tried many other versions, including 4.3.1 with no success.
I know there is an older, similar question here, but that was never answered satisfactorily, in my opinion.
If I look at the meta data in VS, at the top of one of the Automapper files I can see this:
Assembly AutoMapper, Version=6.2.2.0, Culture=neutral, PublicKeyToken=be96cd2c38ef1005
// C:\Users\randyg.nuget\packages\automapper\6.2.2\lib\netstandard1.3\AutoMapper.dll
From this you can see it's taking the netstandard1.3 version, which is correct. I'm wondering if the nuget on the build server is looking for a netcoreApp2.0 folder, rather than the netstandard1.3 folder? Following this theory, I tried adding this to my .csproj file:
<AssetTargetFallback>$(AssetTargetFallback);netstandard1.3</AssetTargetFallback>
My theory was this would tell nuget to look for a netstandard1.3 version of automapper if it couldn't find a netcoreapp2.0 version. However, this didn't have any effect. I later read that behind the scenes this fallback is already added automatically.
If anyone has any ideas I would greatly appreciate it. I'm pulling out (what's left of) my hair on this, as this is the only package giving me trouble, and it's a critical one for my project.
On the build server I'm using .NET Core sdk 2.0.3 as well, if that matters.
This is how I solved this: since it seemed it might have to do with my target being netcoreapp2.0, I tried adding an additional 'dummy' project to my solution, with its target = netstandard1.3. In this configuration, the restore/build succeeded. I thought I would have to maintain this dummy project for this purpose, until I tried deleteing it and now the netcoreapp2.0 solution still restores fine without it. I can only assume something was corrupted in the TFS build server NPM cache (even though I had tried checking the box to disable that cache), and once I got it to succeed once, it has cleared up whatever the issue was.

NUnit Unit tests not showing in Test Explorer with Test Adapter installed

Want to improve this post? Provide detailed answers to this question, including citations and an explanation of why your answer is correct. Answers without enough detail may be edited or deleted.
I've installed NUnit Test Adapter for VS2012 + 2013. When I first installed the Adapter tests were showing up, but they stopped showing up for some reason today. After building, rebuilding, cleaning, restarting, nothing shows up in Test Explorer. Why would this be happening? I'm using VS2013 Ultimate.
If you're using a NUnit3+ version, there is a new Test Adapter available.
Go to "Tools -> Extensions and Updates -> Online" and search for "NUnit3 Test Adapter" and then install.
If your test project is set to target a 64bit platform, the tests won't show up in the NUnit Test Adapter.
My test assembly is 64-bit. From the menu bar at the top of visual studio 2012, I was able to select 'Test' -> 'Test Settings' -> 'Default Processor Architecture' -> 'X64'. After a 'Rebuild Solution' from the 'Build' menu, I was able to see all of my tests in test explorer. Hopefully this helps someone else in the future =D.
Check for NUnit versions mismatch. The currently available NUnit Test Adapter only works for NUnit version 2.6.4 and below.
To downgrade NUnit from version 3.x go to
Package Manager Console > update-package NUnit -version 2.6.4
http://jeremybytes.blogspot.co.ke/2015/11/review-of-unit-testing-makes-me-faster.html
In my situation the 'NUnit3 Test Adapter' has been disabled.
To re-enable it go to menu
Tools->Extensions and Updates...
On the left side select 'Installed'->'All'.
On the upper right corner search for 'nunit'.
If you have 'NUnit3 Test Adapter' installed, with the found item you can enable/disable it.
This answer seems pretty basic but wasn't completely obvious to me at first. If you (re)build the solution it only builds the projects that are configured to build in the Build -> Configuration Manager
This was my issue, I must have inadvertently changed a build configuration settings or something that caused my test projects not to build (when they previously were). So the Test Explorer window was looking at dlls that were out of date. It became clear to me this was the case after doing a Clean and seeing most of my tests disappear and not come back after a rebuild...further inspection of bin folder showed that these projects weren't being built at all.
I had a working setup (for NUnit2 and NUnit3 depending on the solution, and multiple versions of Visual Studio between 2012 and 2017), and it suddenly stopped working one day: no tests detected in any solution or version of VS.
In my case, it helped to delete %localappdata%\Temp\VisualStudioTestExplorerExtensions. After a restart of VS, everything worked as before.
If you are using VS 2017 and .net core ,as said here, you should add references to the test framework NUnit 3.6.1, to the test runner NUnit3TestAdapter 3.8.0-alpha1 and to the test SDK Microsoft.NET.Test.Sdk 15.0.0.
Tools
NuGet Package Manager
Manage NuGet Packages For Solution
Browse
NUnitTestAdapter.WithFramework
Ctrl+R,A to build/run tests
Using NUnitTestAdapter.WithFramework makes sure there are little/no inconsistencies across versions of NUnit and NUnit Adapter (i.e. "it just works")
Check whether you have stated
[TestFixureSetUp]
and
[Test]
in the test class
sample:
namespace ClassLibrary1
{
public class SimpleCalculator
{
public Calculator _calculator;
[TestFixtureSetUp]
public void initialize()
{
_calculator = new Calculator();
}
[Test]
public void DivideTest()
{
int a = 10;
int b = 2;
int expectedValue = a/b;
int actualValue = _calculator.Divide(a, b);
Assert.AreEqual(expectedValue, actualValue, "Functionality not working properly!");
}
}
}
I had to uninstall then re-install the xunit.runner.visualstudio nuget package. I tried this after trying all the above suggestions, so may be it was a mixture of things.
One other cause to this problem is if you open a project from a mapped drive - Visual Studio handles such projects properly, but apparently Nunit doesn't support them.
Copying the project to a physical fixed the issue.
I also found that when I uninstalled nunit v3.2.1, the nunit framework reference for v3.2.1 was still in my project in solution explorer.
Solution Explorer > ProjectName > References
If you right click it will show the version. Remove this
Then Right click on References > Add Reference.
Search for the version 2.x version and add then rebuild solution.
That worked for me!
I experienced the problem mentioned by op
My case was that I was handed an old project and the tests were actually part of the system under test. I assume they were using the external test runner.
this task chain resolved the issue for me
created a test project,
moved the test files there
added references so the test project would compile
added the Nunit and Nunit adapter NuGet packages to the test project
recompiled
i was able to successfully run the Nunit tests.
If you are using the TestCaseSource attribute, ensure the source exists and respects the documentation, otherwise your tests will not be discovered.
I had a similar issue where the tests where not being discovered. I had the correct version of NUnit, versions matched up between NUnit and adapter, and the tests where tagged correctly. I was running VS 2017 Enterprise not as an administrator. After starting VS as administrator the tests appeared.
I started a new solution with a test project in it, and compared it against my original, problem project. The original, for some reason, had an app.config in it. I excluded that file from the project and saw my tests reappear in the test explorer.
I had this problem too but the cause was different. I'm using VS2017 with F# 4.0.
Firstly, the console in Visual Studio does not give you enough details why the tests could not be found; it will just fail to the load the DLL with the tests. So use NUnit3console.exe on the command line as this gives you more details.
In my case, it was because the test adapter was looking for a newer version of the F# Core DLL (4.4.1.0) (F# 4.1) whereas I'm still using 4.4.0.0 (F# 4.0). So I just added this to the app.config of the test project:-
<dependentAssembly>
<assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="4.4.0.0" />
</dependentAssembly>
i.e. redirect to the earlier F# core.
I had the same problem, when suddenly any test didn't appeared on Test Explorer window.
I has the updated version of "NUnit3TestAdapter"
and after lots of searches and efforts,
I found that I need set the following values in project properties:
[In Solution Explorer window: right click on Project > Properties]
Under Build tab, set Platform=x64, and set Platform target=x86 or Any CPU
Build the project and all tests will be appear on Test Explorer window.
Important note:
I came to a solution after seeing the next msg in the output window:
"Test run will use DLL(s) built for framework Framework45 and platform X86. Following DLL(s) will not be part of run: AutomationTests.dll is built for Framework Framework45 and Platform X64."
I had some msbuild.exe processes that were hung. I don't know if that was my problem or not, but it took me a lot of trail and error with reinstalling various NUnit adaptors before I found the hung processes.
Just to add my $.02 here, I ran into a similar issue just yesterday, where 168 of my tests were missing. I tried most everything in this post - most especially making sure my version(s) of NUnit were the same - all to no avail. I then remembered that I had my tests divided into playlists; and these do not update automatically as you add new tests. So, when I deleted the playlists, BAM!, all of my tests were back once more.
I use NUnit 3 and tried most of the other solutions I saw here. None of those worked for me.
Even though already selected, reselecting the "Playlist: All Tests" option in test explorer showed all hidden tests in my case. I need to do this after every rebuild.
Make sure your test class is public. I often make this mistake then I just look at the code for 5 minutes what is going on.
[Test]
public void YourTest()
{
...
}
Tools
NuGet Package Manager
Manage NuGet Packages For Solution
Browse
NUnit3TestAdapter (NUnit 3 in my case ..)
After installation it should be possible to use the default TestExplorer included with the installation of Visual Studio.
If your test project is not x86, the tests will not be found until you tell the test runner the correct target platform.
Prior to Visual Studio 2022, this was the "Test/Test Settings/Default Processor Architecture" option.
In VS2022 you need to create a 'runsettings' file and set the test project to use it. In that file you can specify the Target Platform, like this:
<?xml version="1.0" encoding="utf-8" ?>
<RunSettings>
<!-- Configurations that affect the Test Framework -->
<RunConfiguration>
<TargetPlatform>x64</TargetPlatform>
</RunConfiguration>
</RunSettings>
You still also need to include the Nunit3TestAdapter and Microsoft.NET.Test.Sdk nugets (and make sure the project actually built, and check the various other more obscure mistakes mentioned in other answers)
Make sure your tests are properly marked with the Test attribute. If all of the tests are marked with only the Explicit attribute, the TestAdapter doesn't recognize the fixture.

Code First Migrations for a custom NuGet package can't be executed from main application

I have created a module to be included in a main MVC3 web application. The module is packaged into a NuGet package and it can be installed and uninstalled via NuGet. Both, the main site and the module use Code First, EF >= 4.3
To create the package I have another MVC3 site and all the functionality is inside an area, so to create the package I just pack the libraries, the views and all the needed files. Database Migrations work fine in the project and the package is created nicely.
Now I install the package in the main site via NuGet. This site is in another solution, and the solution has two projects:
MyProject.Web.UI: this is an Mvc3 project
MyProject.EntityFramework: this is a class library with all the models, dbContext for MyProject...
The package is installed correctly and the Area, the Area views and libraries are correctly installed.
The problem now is how I update the database? I've tried first to run "Update-Database" but I get the message:
"No migrations configuration type was found in the assembly
'MyProject.Web.UI'. (In Visual Studio you can use the
Enable-Migrations command from Package Manager Console to add a
migrations configuration)."
I've tried then to enable the migrations with "Enable-Migrations" but I got this other message:
"No context type was found in the assembly 'MyProject.Web.UI'."
I tried also just to run the site and see if the changes are automatically applied but I get the exception page with the typical message:
"The model backing the 'NugetPackageDbContext' context has changed
since the database was created. Consider using Code First Migrations
to update the database"
I don't know what to do to update the database with the required changes in migrations that come in the NuGet package. Any one could put some light here in this matter? I'm quite new to Migrations, maybe there are some configs to update the database if there is a change instead of running the commands in the console, I'm a bit lost.
Thanks in advance :)
Good news! It seems that I got it. I was looking for a way to make the NuGet package to update the database to the latest version.
Well, this package comes with an Admin controller, so I added a new action called Update:
public ActionResult Update()
{
System.Data.Entity.Database.SetInitializer(new System.Data.Entity.MigrateDatabaseToLatestVersion<MyPackageDbContext, MyPackage.Migrations.Configuration>());
return View();
}
In my Configuration class for the migrations I have:
public Configuration()
{
AutomaticMigrationsEnabled = true;
}
I have to say that in my way to do all of this I've found a few strange behaviors. One thing that surprises me is this, I don't know if this is normal, read the secuence:
Package installed with new migrations but database not up to date. So if I access the EF this affected by this I get the exception about this. Ok up to this.
I go to my action /MyPackage/Admin/Update and run it. Apparently it runs. I go to the database and I don't see changes. Even the migrations table does not have a new row.
I access again the EF part that displayed the exception before (point number 1) and then everything goes through, database is updated and the migrations table shows the new line.
One thing that you have to notice is that the Configuration class is internal, but because this is a module I needed to be accessible from another assembly. I tried to make it public but I got some strange warnings/errors that I don't know if they are related. So in the end I kept it internal but used
[assembly: System.Runtime.CompilerServices.InternalsVisibleTo("OtherAssembly")]
I've found a few of strange behaviors in Visual Studio with all this stuff of the NuGet packages, CF, migrations ... I don't know if these things are bugs, but all this thing took me two full working days.
I hope it is useful for any other that wants to create a CF NuGet package that is updateable.
In package manager console you will need to the Default project to MyProject.EntityFramework
You may also need to make sure MyProject.Web.UI is set as the start up project (in case there are multiple), then you can pass in the connection string into update command:
Update-Database -ConnectionStringName MyConnStringName
This should update the database correctly, unless there is data that will be lost.
If your DbContext is in MyProject.EntityFramework then the Default Project in the Package Manager Console needs to be set to MyProject.EntityFramework before you can use Update-Database.
I realize that this question is very old, but since I don't see this answer I'll throw it in anyway.
To perform migrations and such on projects or external references you can still use the same three command:
Enable-Migrations
Add-Migration
Update-Database
but you wil need to supply some additional parameters. For the Enable-Migrations command you will need to add the -ContextTypeName and optionally the -ContextAssemblyName commands like so:
Enable-Migrations -ContextTypeName MyProject.EntityFramework.NugetPackageDbContext -ContextAssemblyName MyProject
This will give you a migration configuration class in your current project. The other two commands will require you to specify this configuration class:
Update-Database -ConfigurationTypeName MyProject.Web.UI.Migrations.Configuration
Hope that helps