I'm getting this error when I try to update my database
Update-Database : Cannot bind argument to parameter 'Path' because it
is null. At line:1 char:2
Update-Database
CategoryInfo : InvalidData: (:) [Update-Database], ParameterBindingValidationException
FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Update-Database
can you point me in the right direction to solve the problem?
thank you
This bug has been reported on GitHub (see issues 1290, 1306, 1348). It was fixed (by the reporter of issue 1290) and is available in nightly builds. It was first scheduled for the 6.4.0 release (scheduled for late November/early December per this comment) but has since been moved to a 6.3.1 release. Neither milestone has a due date as of writing this.
The bug only affects EF Migrations and it only applies to using a Web Application project as the startup project (even if your entities and context are in different projects). If affects multiple commands (Enable-Migrations, Add-Migration, Update-Database, and Get-Migrations) because they call into the code that contains the bug.
If you need to use Migrations, either downgrade to version 6.2.0 or use one of the workarounds that have been identified.
If you downgrade, make sure do it to all projects that use it within the solution. If the 6.3.0 package is referenced by any project, the 6.3.0 PowerShell module will take precedence. You can use the "Manage NuGet Packages for Solution..." command from the solution node to help identify where 6.3.0 might still be installed in any projects. Once that's done, you'll need to close and reopen the project in order to load 6.2.0's PowerShell module.
Workarounds
If you want/need to use version 6.3 and you're encountering this error, there are several workarounds you can try. Here's what I've been able to put together:
Use a Console Application as the startup project.
Because the bug only affects Web application projects, the conditional branch that has causes the error is never executed. If you already have a console application with the right connection string, you can use that. If you don't, you can add a dummy project for this purpose.
Note: If your connection string includes |DataDirectory|, this won't work because it avoids specifying the --data-dir argument in order to avoid the bug.
Use a nightly build.
Although this works, it's probably a non-starter for a lot of projects because pre-release builds are generally disallowed in production. If your production release is still several months away, though, it might be an option if you're willing to proceed with the hope that a working release becomes available in time.
Add a dummy project that references a nightly build.
Similar to using a nightly build, you're referencing it in an unused project in order to load the fixed PowerShell module. You would still reference the released version in the projects used by the application.
Modify the local package in the shared cache location.
Caution: This is not a tenable solution for teams (or CI/CD environments) but it might be okay for an individual who wants to use a quick hack while waiting for the next release and doesn't mind reapplying it if the shared cache gets cleared.
If you're using PackageReference tags in your project files, assemblies are referenced in a shared cache location, usually under %USERPROFILE%\.nuget\packages. You can modify the file there as shown in issue 1290 and it will be used by all projects that use the package via PackageReference tags. If you're using packages.config you have to modify it in the packages folder and that's more likely to be lost.
I have tested all of these workarounds with successful outcomes.
I have multiple DbContexts in a C# project and I'm trying to enable migrations. When I specify the full command, i.e.:
Enable-Migrations -ContextTypeName Models.Account.AccountDetailDbContext
A migrations folder is created, with the configuration class, but I then get a message:
Checking if the context targets an existing database...
And then
The migrations configuration type 'Portal.WebUI.Migrations.Configuration' was not be found in the assembly 'Portal.WebUI'.
Even though it has just created the file, it can't find it.
I have the correct project selected in the Package Manager Console
I have tried the command using -verbose, but it gives no additional information
If I copy the dbcontexts and classes into a new project then it all works, so it must be something in this existing project that is making the migration fail, but I can't tell what it is.
I solved this by adding EntityFrameworkCore\ before Add-Migration, i.e. the final statement was:
EntityFrameworkCore\Add-Migration
After give a name for your new migration.
I faced this problem. My solution:
Exit visual studio
Open your project again on visual studio
Rebuild solution
Then the error removed. And I can run the command.
After you run Enable-Migrations and the Configuration file is created, rebuild the project and run Enable-Migrations -Force again.
I had this problem and it was solved by changing the dropdown box at the top of the Package Manager Console to choose the correct project. You may need to maximise the width of the package manager console to see this box.
I managed to resolve this by uninstalling the EF nuget package and then reinstalling it.
I have stumbled upon this problem, and after endless hours of googling and trial and error, the solution to my specific problem was much easier.
Just make sure you have all your EF related nuget packages up to date.
I tried every answer I could find here, but what ended up working for me was: Select all EF related nuget packages
(In my case)
Microsoft.EntityFrameworkCore.SqlServer
Microsoft.EntityFrameworkCore.Tools
Microsoft.EntityFrameworkCore.Design
EntityFramework
And update them all, into their latest version (In my case)
The issue was that one of the defaults I downloaded of one of these NuGet packages, was outdated and invalid.
Another possible issue worth checking: is your project signed? As I just discovered, this problem can also eventuate if the assembly is signed with a strong name key file. Part of the EntityFramework tool kit is migrate.exe which is called during the migration process. It appears if the assembly is signed, this application can't find the configuration type.
Solution seems to be <Project> → Properties → Signing: untick "Sign the assembly", at least while performing migration tasks. Tick it back when you're done.
I also had this issue because of a spelling mistake in a namespace
I was facing the same issue. What I found was that in my project name, "-" was included as "abc-xyz". I deleted my project and recreated it as "abcxyz" and it worked. Don't rename the project—you have to rename it at every reference. In this case, first uninstall EF and rename it, then install EF again.
I have faced this problem due to version update of EF package. I have solved by reinstalling:
1.Microsoft.EntityFrameworkCore.SqlServer
2.Microsoft.EntityFrameworkCore.Tools
3.Microsoft.EntityFrameworkCore.Design
4.Microsoft.EntityFrameworkCore
The solution is to check the project reference. In my case, I have added Entity Framework and Entity Framework Core references to my project.
To Resolve this I have removed Entity Framework Reference from the project and now EF Core migration commands are working.
using Microsoft.EntityFrameworkCore.SqlServer;
using Microsoft.EntityFrameworkCore.Tools;
using Microsoft.EntityFrameworkCore.Design;
using Microsoft.EntityFrameworkCore;
Then:
Use EntityFramework6\ before Add-Migration for Entity Framework 6.
Like EntityFrameworkCore6\Add-Migration
In this case First, check NuGet packages
Microsoft.EntityFrameworkCore.SqlServer Microsoft.EntityFrameworkCore.Tools Microsoft.EntityFrameworkCore.Design
most probably missing one of the above packages you get an error.
if missing then install and
do migration using
Add-Migration InitialCreate
Recently I decided to use Entity Framework for a personal project.
From my Visual Studio 2013 community edition and using NuGet I installed the latest version of the framework (nuget version 2.8.60318.734 and Entity Framework 6.1.3)
Everything seems to work OK I was able to perform simple CRUD operations, till I needed to update my model.
After it, of course I got the error message:
“Additional information: The model backing the 'MyContext' context has changed since
the database was created. Consider using Code First Migrations to update the database
(http://go.microsoft.com/fwlink/?LinkId=238269).”
Seems an appropriate error message, I just need to Enable-Migrations.
Switch to Package Manager Console and there was a message in bright red background
PM> Import-Module : The specified module 'D:\[MyProjects]\[ProfOfConcept]\EntityFrameworkInvalidFilepath\packages\EntityFramework.6.1.3\tools\EntityFramework.psd1' was not loaded because
no valid module file was found in any module directory.
At D:\[MyProjects]\[ProfOfConcept]\EntityFrameworkInvalidFilepath\packages\EntityFramework.6.1.3\tools\init.ps1:8 char:14
+ Import-Module <<<< (Join-Path $toolsPath EntityFramework.psd1)
+ CategoryInfo : ResourceUnavailable: (D:\[MyProjects]...yFramework.psd1:String) [Import-Module], FileNotFoundException
+ FullyQualifiedErrorId : Modules_ModuleNotFound,Microsoft.PowerShell.Commands.ImportModuleCommand
Hmmmm something is wrong, I guess some needed part of the framework was not correctly installed, but let's check the file. The file was present, and the content seemed OK.
Alright let's try to reinstall it, just in case something went wrong at the first time. Using NuGet I tried to uninstall, and reinstall.
Checking Package Manager Console, again the same dreaded error!
Hmmm, let's try to do the uninstall /reinstall from the Package Manager Console. Again the same error!
After spending more time trying to Google similar problems I came across someone describing a similar problem Entity Framework with NuGet - Import-Module error in init.ps1 Tried that… no luck.
So what is really going on? In a Eureka moment I thought… hold on, what was my project path?
D:\[MyProjects]\[ProofOfConcept]\….
Could it be? Could the square brackets be the reason?
Create a copy the project to a simple path (d:\tmp\myProject) start the Visual Studio, enter Package Management Console, …. no error !
Enable-Migrations
PM> Enable-Migrations
Checking if the context targets an existing database...
Detected database created with a database initializer. Scaffolded migration '201504051040353_InitialCreate' corresponding to existing database. To use an automatic migration instead, delete the Migrations folder and re-run Enable-Migrations specifying the -EnableAutomaticMigrations parameter.
Code First Migrations enabled for project EntityFrameworkInvalidFilepath.
That's it!! The square brackets are the culprits
So the bottom line is this, if you are using Entity Framework don’t use [ ] in the path.
I recently had the same issue with NuGet not installing EF 6.1.3 properly because the EntityFramework.psd1 file wasn't being imported. Uninstalling and re-installing EF through Visual Studio didn't help.
What worked for me was to quit VS, navigate to '[Project Root Directory]\packages' and delete the EntityFramework6.1.3 directory. When you restart VS and go to the package manager console, it will let you know that there are modules missing and ask if you want to import them. When you click 'Reload' EF 6.1.3 is installed properly under the 'packages' directory.
In my case I'm using the 2015RC, which has a lot of issues with EF migrations.
I have developed an application using Entity Framework, SQL Server 2000, Visual Studio 2008 and Enterprise Library.
It works absolutely fine locally, but when I deploy the project to our test environment, I am getting the following error:
Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information
Stack trace: at System.Reflection.Module._GetTypesInternal(StackCrawlMark& stackMark)
at System.Reflection.Assembly.GetTypes()
at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadTypesFromAssembly(LoadingContext context)
at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.InternalLoadAssemblyFromCache(LoadingContext context)
at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadAssemblyFromCache(Assembly assembly, Boolean loadReferencedAssemblies, Dictionary2 knownAssemblies, Dictionary2& typesInLoading, List`1& errors)
at System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyFromCache(ObjectItemCollection objectItemCollection, Assembly assembly, Boolean loadReferencedAssemblies)
at System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyForType(Type type)
at System.Data.Metadata.Edm.MetadataWorkspace.LoadAssemblyForType(Type type, Assembly callingAssembly)
at System.Data.Objects.ObjectContext.CreateQuery[T](String queryString, ObjectParameter[] parameters)
Entity Framework seems to have issue, any clue how to fix it?
This error has no true magic bullet answer. The key is to have all the information to understand the problem. Most likely a dynamically loaded assembly is missing a referenced assembly. That assembly needs to be in the bin directory of your application.
Use this code to determine what is missing.
using System.IO;
using System.Reflection;
using System.Text;
try
{
//The code that causes the error goes here.
}
catch (ReflectionTypeLoadException ex)
{
StringBuilder sb = new StringBuilder();
foreach (Exception exSub in ex.LoaderExceptions)
{
sb.AppendLine(exSub.Message);
FileNotFoundException exFileNotFound = exSub as FileNotFoundException;
if (exFileNotFound != null)
{
if(!string.IsNullOrEmpty(exFileNotFound.FusionLog))
{
sb.AppendLine("Fusion Log:");
sb.AppendLine(exFileNotFound.FusionLog);
}
}
sb.AppendLine();
}
string errorMessage = sb.ToString();
//Display or log the error based on your application.
}
I solved this issue by setting the Copy Local attribute of my project's references to true.
One solution that worked for me was to delete the bin/ and obj/ folders and rebuild the solution.
Update:
Or you can try to right-click the Solution node in the "Solution Explorer" and click "Clean Solution", then click "Rebuild Solution" (thanks Emre Guldogan)
Two possible solutions:
You are compiling in Release mode but deploying an older compiled version from your Debug directory (or vise versa).
You don't have the correct version of the .NET Framework installed in your test environment.
As it has been mentioned before, it's usually the case of an assembly not being there.
To know exactly what assembly you're missing, attach your debugger, set a breakpoint and when you see the exception object, drill down to the 'LoaderExceptions' property. The missing assembly should be there.
Hope it helps!
The solution was to check the LoaderException: In my case, some of the DLL files were missing.
Make sure you allow 32 bits applications on IIS if you did deploy to IIS. You can define this on the settings of your current Application Pool.
I encountered this error with an ASP.NET 4 + SQL Server 2008 R2 + Entity Framework 4 application.
It would work fine on my development machine (Windows Vista 64-bit). Then when deployed to the server (Windows Server 2008 R2 SP1), it would work until the session timed out. So we'd deploy the application and everything looked fine and then leave it for more than the 20 minute session timeout and then this error would be thrown.
To solve it, I used this code on Ken Cox's blog to retrieve the LoaderExceptions property.
For my situation the missing DLL was Microsoft.ReportViewer.ProcessingObjectModel (version 10). This DLL needs to be installed in the GAC of the machine the application runs on. You can find it in the Microsoft Report Viewer 2010 Redistributable Package available on the Microsoft download site.
My instance of this problem ended up being a missing reference. An assembly was referred to in the app.config but didn't have a reference in the project.
Initially I tried the Fusion log viewer, but that didn't help
so I ended up using WinDbg with the SOS extension.
!dumpheap -stat -type Exception /D
Then I examined the FileNotFoundExceptions. The message in the exception contained the name of the DLL that wasn't loading.
N.B., the /D give you hyperlinked results, so click on the link in the summary for FileNotFoundException. That will bring up a list of the exceptions. Then click on the link for one of the exceptions. That will !dumpobject that exceptions. Then you should just be able to click on the link for Message in the exception object, and you'll see the text.
If you're using the EntityDataSource in your project, the solution is in Fix: 'Unable to load one or more of the requested types' Errors. You should set the ContextTypeName="ProjectNameNameSpace.EntityContainerName" '
This solved my problems...
Another solution to know why exactly nothing works (from Microsoft connect):
Add this code to the project:
foreach (var asm in AppDomain.CurrentDomain.GetAssemblies())
{
asm.GetTypes();
}
Turn off generation serialization assemblies.
Build and execute.
If you are using Entity Framework, try copying the following references locally.
System.Data.Entity
System.Web.Entity
Change the property "Copy Local" to "True" for these references and publish.
I had a .NET 4.0, ASP.NET MVC 2.0, Entity Framework 4.0 web application developed in Visual Studio 2010. I had the same problem, that it worked on one Windows Server 2008 R2 server but not on another Windows Server 2008 R2 server, even though the versions of .NET and ASP.NET MVC were the same, throwing this same error as yours.
I went to follow miko's suggestion, so I installed Windows SDK v7.1 (x64) on the failing server, so I could run !dumpheap.
Well, it turns out that installing Windows SDK v7.1 (x64) resolved the issue. Whatever dependency was missing must have been included in the SDK. It can be downloaded from Microsoft Windows SDK for Windows 7 and .NET Framework 4.
Adding my specific problem/solution to this as this is the first result for this error message. In my case, the error was received when I deployed a second application within the folder of my first application in IIS. Both were defining connection string with the same name resulting in the child application having a conflict and in turn generating this (to me) non-obvious error message. It was solved by adding:
<clear/>
in the connection string block of the child web application which prevented it from inheriting the connection strings of web.config files higher in the hierarchy, so it looks like:
<connectionStrings>
<clear/>
<add name="DbContext" connectionString="MySERVER" providerName="System.Data.SqlClient" />
</connectionStrings>
A reference Stack Overflow question which helped once I determined what was
going on was Will a child application inherit from its parent web.config?.
This worked for me. Add it in your web.config
<system.web>
<trust level="Full" />
My issue has been resolved after I deleted the redundant assembly files from the bin folder.
In case none of the other answers help you:
When I had this problem, it turned out my Windows service was built for an x64 platform, and I was inadvertently running the 32-bit version of InstallUtil.exe. So make sure you're using the right version of InstallUtil for the platform you built for.
Other suggestions are all good. In my case, the problem was that the developer box was a 64-bit machine using the x86 location of various APIs, including Silverlight.
By changing the target platform to match the 32-bit server where the web application was being deployed removed the majority of the errors related to not being able to load one or more of the requested types.
I changed the Specific Version Property of the Refrences to false and that helped.
I had the same error message reported when compiling a Visual Studio package (VSPackage). The whole solution compiles and the error is thrown when the package is being created by CreatePkgDef. Having said that, it is clear that I cannot catch the LoaderExceptions as it is not my application that throws it, but Microsoft's own tool. (Though I am responsible for the confusion of CreatePkgDef.)
In my case the root cause was that my solution creates a MyDll.dll that has already been registered to the GAC (and they are different), so the CreatePgkDef got confused which one to use and it decided just to throw an error which isn't really helpful. The MyDll.dll in the GAC was registered by the installer of the same product (obviously an earlier version, with /slightly/ different content).
How to fix it
Preferred way: Make sure you use the correct version of MyDll.dll
When compiling your project make sure you use a different version number than you used in the previous version located in the GAC. Make sure the following attributes are correct:
[assembly: AssemblyVersion("1.0.0.1")] // Assuming the old DLL file was versioned 1.0.0.0
[assembly: AssemblyFileVersion("1.0.0.1")] // Assuming the old DLL file was versioned 1.0.0.0
If needed, specify the fully qualified assembly name (for example, "MyDll.dll, Version=1.0.0.1, Culture=neutral, PublicKeyToken=1234567890abcdef") when you reference it in your other projects.
If the above failed: You can uninstall the old MyDll.dll from GAC
How to Uninstall an Assembly from the GAC
Uninstall the application that includes MyDll.dll
Changing the AssemblyVersion was good enough for me. :)
I hope this was helpful.
I had the same issue (but on my local) when I was trying to add Entity Framework migration with Package Manager Console.
The way I solved it was by creating a console application where Main() had the following code:
var dbConfig = new Configuration();
var dbMigrator = new DbMigrator(dbConfig);
dbMigrator.Update();
Make sure the Configuration class is the migration Configuration of your failing project. You will need System.Data.Entity.Migrations to use DbMigrator.
Set a breakpoint in your application, and run it. The exception should be caught by Visual Studio (unless you have that exception type set to not break the debug session), and you should be able to find the info you are looking for.
The missing reference in my case was EFProviderWrapperToolkit.
I got this problem when I installed a NuGet package on one of the projects and forgot to update the other project.
I solved this by just making both projects having the same reference assembly.
It happened for me also. I solved the problem as follows:
Right click Solution, Manage NuGet Packages for Solution...
Consolidate packages and upgraded the packages to be in the same version.
I had this issue while referencing a nuget package and later on using the remove option to delete it from my project. I had to clear the bin folder after battling with the issue for hours. To avoid this its advisable to use nuget to uninstall unwanted packages rather than the usual delete
Set 32 bit IIS mode to true, debug mode to true in the configuration file, deleting the temp directory and resetting IIS fixes the issue temporally and it comes back after some time.
Verify that each of your projects is setup correctly in the Configuration Manager.
Similar to William Edmondson's reason for this issue, I switched my Configuration Manager setting from "Debug" "Any CPU" to "Debug" ".NET". The problem was that the ".NET" version was NOT configured to build ALL of the projects, so some of my DLLs were out of date (while others were current). This caused numerous problems with starting the application.
The temporary fix was to do Kenny Eliasson's suggestion to clean out the \bin and \obj directories. However, as soon as I made more changes to the non-compiling projects, everything would fail again.
I also got this issue when create new Microsoft Word add-in with Visual Studio 2015. The issue is about I have 2 versions of MS Office, 2013 and 2016. I uninstall MS Office 2013 and then it works.
I build a few projects for SharePoint and, of course, deployed them. One time it happened.
I found an old assembly in C:\Windows\assembly\temp\xxx (with FarManager), removed it after reboot, and all projects built.
I have question for MSBuild, because in project assemblies linked like projects and every assembly is marked "Copy local", but not from the GAC.
I am able to fix this issue by marking "Copy Local=True" on all referenced DLL files in the project, rebuilding and deploying on a testing server.