We have
An Old Web Project
A New Web Project
A Class Library containing all Entity Framework code
All three projects reference Entity Framework 6.1.3.
The Class Library is shared by Old Web Project and New Web Project. Both web projects have a file reference to Class Library. They both point to the same location on disk.
Both web projects are configured to use the same database.
When I run Old Web Project in Visual Studio, it runs just fine.
When I try to run New Web Project in Visual Studio, it throws an AutomaticMigrationsDisabledException.
When I temporarily add ClassLibrary.csproj to the New Web Project's solution and run
Add-Migration TestMigration -ConfigurationTypeName MyConfiguration -ProjectName ClassLibrary -StartupProjectName NewWebProject -ConnectionStringName MyContext
it scaffolds a migration with empty Up() and Down() methods, indicating it did not find changes after all.
What might cause New Web Project to throw an AutomaticMigrationsDisabledException under these circumstances? How can I further diagnose the issue?
I had very carefully checked that New Web Project's file reference to ClassLibrary.dll is the correct one and that the DLL in question is up-to-date.
As a test, I added a new method to a class in ClassLibrary.dll, and found that New Web Project could not resolve it.
I deleted the existing file reference and added it back in, and the problem resolved.
For an unknown reason, an older copy of ClassLibrary.dll was being referenced in contrast to the information seen in the Properties window for that reference.
Related
Good day,
I've created a C# .NET 4.7.2 class library project which integrates EF6. When the parent project makes any call to the DLL for db access, the above exception is thrown.
A common solution is to include a reference to EF in the parent project and to copy the connection string element from the class library's app config file. This indeed works, but is not ideal. I really envision all of these settings encapsulated within the DLL.
Anyone have a work-around?
Thanks.
I've a scenario where the project structure as following
DomainModels
Repository --ReferenceTo 'DomainModels'
Curator --ReferenceTo 'Repository'
MVC project -ReferenceTo 'Curator'
Now the problem is If I keep My DbContext in DomainModel which I'm supposed to keep, I cann't enable Db Migrations.
-- The only solution I've come across is to give the reference of 'DomainModels' to 'MVC projects'
using Enable-Migration MigrationName SomeAdditionalParameter here
Why is this a problem? I have a Data project which contains the models and DbContext. My web and business projects reference this. When I run the Add-Migration step, I just select the Data project in the project dropdown and it uses the connection string in the web.config in the web project. It works well and I have no problems.
I have a common DataAccess Class Library Project. This project needs to be Referenced in multiple Visual Studio Solution.
Currently we are Referencing this DA Library via Folder created in each project called binary.
so whenever there is a change in DataAccess Library project, we have Manually update all the projects that are Referencing this DAL.
I was thinking about creating Single Solution, which will have All the Projects
including DAL & all other Projects that are Referencing it and change the Reference to PRoject Reference DAL from other Projects, instead of File Reference from Binary folder.
Is there any other Better Solution around sharing this DAL ?
The answer is Nuget.
You should package you dal output as a nuget package and push it to a nuget server.a nuget server can be a network share our an application like ProGet.
Preferably you have an automated build do there package and push. That makes it easy.
Then each of your other solutions can take a dependency on that package. When you update it in the Nuget server each of the solutions will notify of a new version that can be used.
I thought this problem was fixed. I'm using Visual Studio 2013 and it is Entity Framework 6.1. I get the error message: PublicKeyToken=xxxxxx is not marked as serializable.
I thought this was fixed. Is it broken again and if so, is there a workaround?
Thanks.
Here is the complete error message when trying to install into a win32 C++ console application. (Built with default settings, no other adds to new build.)
Error: Type
'Microsoft.VisualStudio.Project.VisualC.VCProjectEngine.VCProjectShim' in Assembly
'Microsoft.VisualStudio.Project.VisualC.VCProjectEngine, Version=12.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' is not marked as serializable.
Here is the complete error message when trying to install into a C++ CLR:
(Actually, it's the exact same error message.)
Here is the complete error message when trying to install into a General Empty C++ Project:
(Again, same error message.)
Okay, I can finally figure out what you are doing. You are trying to run Nuget to download and install the Entity Framework into a C++ project. Yes, that's going to be a fail-whale. Nuget acquired the ability to install C++ libraries at version 2.5, but that only works for native libraries. Pure C++, not managed code like EF. Being a relatively new feature, it doesn't do anything to stop you from getting it wrong, it doesn't filter the available packages to the kind that can work in a C++ project.
The step that fails is the final one, download and copying files work okay but then Nuget runs a Powerscript script to modify the project properties. Which, for EF, was written to work in a C# or VB.NET project. The VS extension model for C++ projects (implemented by the VCProjectEngine class as reported in the error message) is too different to permit that script to complete successfully.
Do keep in mind that the odds of using EF in a native C++ projects are zero. You'll only have a smallish shot at it in a C++/CLI project. Starting with a project template in the CLR node is a required first step.
The next one is to fool the Nuget installer, add a dummy C# project to your solution and run Nuget to get EF installed into that project. You'll see it adding an app.config file to the project, you need to do the same in your C++/CLI project. And it adds two EF assemblies that you also need to add to your C++/CLI project:
Right-click the project in the Solution Explorer window, Properties
Select Common Properties + References
Click the Add New Reference button
Click the Browse button
Navigate to the dummy C# project's packages\EntityFramework.6.1.0\lib\net45 directory
Select EntityFramework.dll you see there
Repeat to add EntityFramework.SqlServer.dll there.
Be sure to write C++/CLI code to use it. Beware that you'll have a Eskimo's chance to find any. The much saner approach is to create a C# library that uses EF and use that library in a C++/CLI project.
Code first migrations have been working very well for me. I have a services project and a wpf project. The model is in the services project which is referenced by the wpf project. Update-database is done on the services project, but uses connection string from the wpf project. I now add a web project which also references the service project. So now that there is a connection string in the app.config and there is one in the web.config, which one will it use?
In my scenario, the app.config in the services project is ignored. Code first migrations will use either the app.config from the WPF project or the web.config on the web project, depending which is selected as the startup project.
When doing update-database you should specify the project that contains the migrations. Make sure that you have an app.config file in that project that contains the correct connection string.
you can do a Update-Database -ConnectionStringName "MyConnectionString" and it should work like a charm.