I have 2 Visual Studio projects; a .net core web API 3.1 project used as startup for ef migrations and a class library containing the dbcontext. When I open a powershell window, navigate to the folder for my class library and execute dotnet ef migrations add Initial --startup-project [path to csproj-file for the web API project] the migrations folder with a snapshot file and the initial migration file is created.
But when I open the migration file in Visual Studio I get several compile errors, one of them complaining that The type or namespace 'Migrations' does not exist in the namespace 'Microsoft.EntityFrameworkCore'... I can also see the auto generated migration file contains a using statement pointing to Microsoft.EntityFrameworkCore.Migrations which is marked as unnecessary and the documentation at msdn clearly contains both the base Migration class and MigrationBuilder class referenced by the compiler.
I tried looking for both Microsoft.EntityFrameworkCore.Migrations and Microsoft.EntityFrameworkCore.All on Nuget.org but none of them exist. Am I missing something obvious here? Why do the autogenerated migration files fail to compile?
Apparently I didn't look carefully enough at the msdn documentation for the Migration class. It is located in the Microsoft.EntityFrameworkCore.Relational assembly and after installing that Nuget package the project now compiles without errors.
Related
I have made a small MVC project and was trying to implement validation inside it.
following this tutorial
https://learn.microsoft.com/en-us/aspnet/mvc/overview/getting-started/introduction/adding-validation
I made changes in my student table class.
and then tried adding the migration as it says but it says
No migrations configuration type was found in the assembly 'Bittu2'.
(In Visual Studio you can use the Enable-Migrations command from
Package Manager Console to add a migrations configuration).
I tried Enabling-Migrations and running the code but it now says
Creating a DbModelBuilder or writing the EDMX from a DbContext created
using Database First or Model First is not supported. EDMX can only be
obtained from a Code First DbContext created without using an existing
DbCompiledModel.
I have used databasefirst approach
Please tell what to do?
We are planning to switch to Visual Studio 2017.
For our Entity Framework 6 edmx file we use the EntityObject Generator extension to create us the desired ObjectContext.
This extension is only compatible up to VS2013 - inofficially up to VS2015. The solution to simply adjust the manifest file in the vsix does not seem to work for VS2017 though - I guess among others because the vsix architecture changed.
Is there a way to get the ObjectContext template without using an old Visual Studio? I assume the template is not always the same for each edmx file so it could simply be copy pasted from an existing project.
I just did this in VS2017.
Download the VS extension package "EF 6.x EntityObject Generator for C#" from MS. It's a *.VSIX file. Rename it to ZIP. open the zip file and inside that you find one more zip.
There you will see a TT file. Copy it out.
In your project that have a MyModel.TT file that generates DbSet just replace that TT file with the one you got from vsix file.
Edit one line:
SourceCsdlPath = #"$edmxInputFile$",
to your
SourceCsdlPath = #"myEDM.emdx",
save TT file and your c# model code is generated with old EntityObjects
I created project with name Sorama.CustomAuthentication in that project I installed a package called c# CodeFirst Membership Provider via nuGet package manager.
You can see the reference that has been added to this project here
but it is not letting the CodeFirstMembershipProvider class inherit from MembershipProvider.
Error says MembershipProvider could not be found.
What am I missing?
It looks like you added this to a new Class Library project (i.e. not to the MVC project itself)? If so then most of the references they assume exist for the package (that would be in a template MVC project) are missing from your Class Library references.
That particular NuGet (currently at v1.0.0) frankly isn't a great package. It seems to be missing dependencies like EntityFramework and some .NET framework references, so once you get past this one you may have others to add as well, which will probably be:
From Nuget:
EntityFramework.dll, v5.0.0.0 (Install-Package EntityFramework -Version 5.0.0)
From the GAC (i.e. use the Add Reference context menu for the project, and in the dialog search in the Assemblies\Framework list for these names)
System.Web.dll, v4.0.0.0
System.Web.ApplicationServices.dll, v4.0.0.0
System.Configuration.dll, v4.0.0.0
In future you can work this out by asking Visual Studio to build the project, and looking at the build error messages, which will look like:
The type name 'MembershipProvider' could not be found. This type has been forwarded to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Consider adding a reference to that assembly.
The bit I have highlighted in bold tells you that it thinks the best match for your reference that you need is to System.Web.ApplicationServices, particularly v 4.0.0.0, and gives you the public key token as well.
Be sure to have a reference added to System.Web.ApplicationServices.dll
The type 'System.ComponentModel.DataAnnotations.MaxLengthAttribute'
exists in both
[path...]\packages\EntityFramework.4.3.1\lib\net40\EntityFramework.dll
and
'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework
\.NETFramework\v4.5\System.ComponentModel.DataAnnotations.dll'
Now, I have read on msdn that its safe to exclude the EntityFramework reference (which was added through the nuget package). However, when I do that, I cant create a DBContext properly as the DbModelBuilder class lives in the EntityFramework dll. Also, some other critical classes are missing when I remove the EntityFramework refference so this is old and irrelevant solution now.
Update (disambiguation): Both System.ComponentModel.DataAnnotations.dll and EntityFramework.dll include System.ComponentModel.DataAnnotations.MaxLengthAttribute. The problem is that each dll also includes other classes that are critical to EF code-first design. For example:
EntityFramework.dll:
- System.Data.Entity.DbModelBuilder
System.ComponentModel.DataAnnotations.dll:
- System.ComponentModel.DataAnnotations.RegularExpressionAttribute
Add this statement to top of your class
using System.ComponentModel.DataAnnotations;
System.ComponentModel.DataAnnotations namespace is distibuted across the EntityFramework.dll and System.ComponontModel.DataAnnotations.dll. So you need to add a reference to both of that in your project to make use of DataAnnotations.
The MaxLenth attribute is present in EntityFramework.dll. So make sure you have that reference to that dll present in your project references section.
EDIT : As of .NET framework 4.5, this namespace is moved to the System.ComponentModel.DataAnnotations.dll. So If you use .NET Framework 4.5 with Entity Framework 4.3.1 or less, You will run in to this conflict. The solution is to switch to Entity framework 1.50 beta 1/ 2 release if you want to stick with .NET 4.5 or downgrade to .NET 4 to use EntityFramework 4.3.1.
From the msdn documentations.
Starting with Entity Framework 5.0 Beta 1, the EntityFramework.dll
does not contain definitions for data annotations. These definitions
were moved to System.ComponentModel.DataAnnotations.dll and are
defined in the System.ComponentModel.DataAnnotations.Schema namespace.
I didn't have the option of upgrading the project to use EF5, or downgrading the build machine to .Net Framework 4.
There is a way to solve this though! It turns out when you install Visual Studio 2012 it adds the following folder (amongst others).
C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0
In VS if you open a project targetting 4.0 and look at the properties of your reference to System.ComponentModel.DataAnnotations you'll see that the path is pointing to the above location, rather than the GAC.
This folder contains the original Framework 4.0 assemblies. If they're present on the machine then MSBuild etc., upon building a project targeting 4.0 will reference these rather than the modified ones that 4.5 puts into the GAC.
In our case this meant we could fix the problem by copying that folder from a dev machine with VS installed up to our build server in the same location. (N.b. We only needed to copy this folder, there was no need to install VS on the build server).
More info here: http://marcgravell.blogspot.co.uk/2012/09/iterator-blocks-missing-methods-and-net.html
Hope this helps someone else!
Have taken over the management of a system written in C# MVC. It's a pretty big project so working my way through it bit by bit to learn what everything does. I've just made my first set of changes to it, and am ready to deploy. To do this I changed the debug mode to production which has have all the correct settings for deployment on the server.
However, when I try to compile the project I get lots of Errors and warnings. Most are to do with the third party NLog library which is used in the project.
The type or namespace name 'NLog'
could not be found (are you missing a
using directive or an assembly
reference?)
I have double checked the using statements which are all okay, and in References there is a reference to NLog. In my handover guide for this project, it states that the NLog.dll should be within the bin folder in the project. Now, if I go into the folder structure of the project, I can see this bin folder which does contain NLog, and other objects that are throwing me errors. However, I cannot see this bin folder at all in the folder structure in Visual Studio, so I'm wondering is this my problem?
If anyone could offer any advice I'd be so grateful.
Thanks.
You shouldn't see the bin folder in the solution explorer, so that's not the problem. My suspicion is that NLog is included in a class library project that is required by some other project in the solution. For some reason, this class library project is not compiling and thus you have this library as well as NLog (which it brings along when it's compiled) not available. I'd make sure that you have NLog included as a reference directly in all projects which directly reference it or have a dependency that references it. Pay particular attention to any test projects, which won't typically get built when you build your production code using the right-click menu build action, but will when you build the entire solution.