EF4 Code First pre-generated view has different hash values in other machines - entity-framework

My pre-generated views for EF4 Code First using this T4 template does not work in the build server. I am not re-generating the view in the build server, just compile and run the MSTest. Error is thrown when the tests are ran:
System.Data.MappingException: The mapping and metadata information for
EntityContainer 'DB' no longer matches the information used to create
the pre-generated views
I ran the same template in another machine and the hash values are different. I guess this is the reason why its it does not work in the build server. The hash values are different at runtime in other machines, hence the verification fails and throws the exception.
Im using:
VS 2010 Pro
.Net Framework v4.0.30319
Entity Framework v4.2 (Code First)
EF CodeFirst View Generation T4 Template for C# (v1.0.1) - slightly modified GetEdmxSchemaVersion to return the correct EntityFrameworkVersions version for my setup.
using Class Library project template
The tests that I am running connects to a SQL DB file that is checked in with the code.
I have checked the build server and its using the same EF dll version and .Net Framework version.
Any idea why the hash values are different?
UPDATE:
I've generated and compared two XML file from two dev machines using EdmxWriter.WriteEdmx().
Here is schema version (the same in both machine):
<?xml version="1.0" encoding="utf-8"?>
<Edmx Version="2.0" xmlns="http://schemas.microsoft.com/ado/2008/10/edmx">
The obvious difference are the order some nodes in the XML files. Here is an example:
Machine 1:
<EntityType Name="PersonEntity" BaseType="Self.Entity" />
<EntityType Name="CompanyEntity" BaseType="Self.Entity" />
Machine 2:
<EntityType Name="CompanyEntity" BaseType="Self.Entity" />
<EntityType Name="PersonEntity" BaseType="Self.Entity" />
Any idea why they are in different order?
UPDATE 2:
The Edmx (xml) from the build server is also different for the other 2 dev machines. Again, the order of some nodes are different.
Machine 1 and build server both have System.Data.Entity.dll (same File and Product version -- v4.0.30319.1) in %windir%\Microsoft.NET\assembly\GAC_MSIL\System.Data.Entity\v4.0_4.0.0.0__b77a5c561934e089.
UPDATE 3:
I also looked at the version of System.Data.Entity.Design.dll. The T4 template references this assembly. Machine 1 has two copies of this dll ... in GAC (v4.0.30319.233) and in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0 (v4.0.30319.1). This is also true in the build server and Machine 2. I wonder if hash validation function during runtime is using this dll as its not referenced in my project. If it does, which version is used. But then again, the hash validation is successful in Machine 1.

I'm answering my own question. Here's how we solve the main problem (how to pre-generate views in EF Code First that is usable in different machines). I am now using .Net runtime 4.0.30319.17929.
In the ABC.csproject where MyContext.cs is located, delete the T4 template and MyContext.Views.cs.
Compile ABC.csproject
Create a console app that will generate the views. I copied most of Pawel's T4 template. Reference the ABC.dll (and other required dlls). Here's one of the changes:
var edmx = GetEdmx(typeof(MyContext));
Save the string output of GenerateViews() to a text file.
Run the console app.
Add new file named MyContext.Views.cs to ABC.csproject and copy the content of the text file to this class.
Recompile ABC.csproject
I find my solution insane and must be simplified or automated but it works.

Related

Entity Framework Core: Script-Migration not recognizing migrations when creating script

I've got a full .NET Framework 4.6.2 Web API app that I've installed Entity Framework Core 1.1.2 into. It contains some classes, a DbContext class and has the relevant EF Core NuGet packages installed.
When I run Add-Migration Initial in the package manager console within Visual Studio, it correctly identifies the DbContext in the project and produces the migration class as well as a snapshot. The migration looks correct, given that within the Up method, it shows a number of create tables for each of the classes I want, it shows the expected columns for each and the constraints I'd expect, so that looks good. Also, within the Down method, it drops all the tables (which makes sense since this is the first migration done). This migration class is created in the /Migrations directory within the project.
When I run Script-Migration in the console next, it produces a SQL script that is incorrect, in that it only creates the table for the EFMigrationsHistory, as follows:
IF OBJECT_ID(N'__EFMigrationsHistory') IS NULL
BEGIN
CREATE TABLE [__EFMigrationsHistory] (
[MigrationId] nvarchar(150) NOT NULL,
[ProductVersion] nvarchar(32) NOT NULL,
CONSTRAINT [PK___EFMigrationsHistory] PRIMARY KEY ([MigrationId])
);
END;
GO
This SQL file is created in the bin/Debug directory for the project.
I would expect that the output of this Script-Migrations command contain the SQL version of the Up method in the migration class that was produced by the previous Add-Migrations Initial command, but alas, this is not the case. If I run Update-Database, it runs against this SQL file and continues to ignore the existing Migrations.
Similarly, this appears to be a larger issue with EF Core, because if I attempt to do a Remove-Migration as suggested in the console after running Add-Migration, it is also unable to find the Migration it just produced and gives me the following error:
No ModelSnapshot was found.
And I know this can't be the case because I see it right there in the Migrations folder along with the initial migration class it created.
What's going on and is there any known workaround to get these tools working appropriately?
Update
While testing, I've found that if I create a new solution with just these few parts in it, it works fine. However, in my original solution, I have these projects within a number of solution folders, so perhaps that's the issue at hand, because putting the new project in a solution folder causes the same issues observed in the rest of this question.

UnintentionalCodeFirstException thrown by mstest

I have a test project which references another project, which in turn references a third project containing my Entity Framework 5.0 file (edmx). I find that I can run database-driven unit tests directly from Visual Studio, but when I run from mstest I get the following errors:
System.Data.Entity.Infrastructure.UnintentionalCodeFirstException:
Code generated using the T4 templates for Database First and Model
First development may not work correctly if used in Code First mode.
To continue using Database First or Model First ensure that the Entity
Framework connection string is specified in the config file of
executing application.
I have non-database connecting unit tests which run fine. I've fiddled with my various app.config EF connection strings and they seem to be OK (every tests runs fine on Visual Studio). The problem is when I run mstest from a command line on my desktop or on a build server. This is the command I use:
MSTest.exe /nologo /searchpathroot:"\Binaries"
/resultsfileroot:"\TestResults"
/testcontainer:"\Binaries\driver.orderedtest"
/testcontainer:"\Binaries\EF.DataAccess.dll"
/publish:"http://"
/publishbuild:"vstfs:///Build/Build/99" /teamproject:"ProjectName"
/platform:"Any CPU" /flavor:"Debug" /noisolation /detail:errormessage
/detail:errorstacktrace /detail:stderr
I have references to all dll's in the test project, as outlined here: Entity Framework custom tool does not correctly embed or load the model as resource files
I've been on this for a few days off and on, and it looks to me that this is an EF 5.0 bug, but according to the connect link this should be fixed, but it doesn't seem to be the case.

When precompiling ASP.NET MVC 4 project in Visual Studio 2012, does it try to resolve the entire config chain locally?

Can someone please confirm or deny my assumption below and/or offer any alternatives?
My Goal
I'd like to be able to precompile and merge my ASP.NET MVC 4 application (as documented here and here) when one-click publishing to our production environment.
The Symptom
I've got an ASP.NET MVC 4 project in Visual Studio 2012. My Web.config contains various entries that are removed in the Web.Release.config transformation. One of the removed entries is the entire configSections element because we maintain those entries in the production server's Machine.config.
However, when I configure my project to precompile and merge for release publication, I get the following error:
Unrecognized configuration section [our custom section name]
My Assumption
What I assume is happening is that it is precompiling everything locally before publishing to the production server (which makes perfect sense) but that part of that precompilation process is to resolve and validate the entire .config chain, from the project's Web.config up to my local Machine.config (which doesn't make much sense, practically). And since my local Machine.config does not declare configSections (or any of the other settings we rely on the production server's Machine.config for), the resolved Web.config doesn't validate.
And since the Web.config doesn't validate, the site can't be precompiled and so nothing is ever published to production.
The Rub
If that is indeed what's happening, then we won't be able to precompile, because the only solution I can think of (other than some potential configuration option I haven't been able to find) would be for all of our developers to have local copies of our production server's Machine.config on their machines. And that simply isn't reasonable because it defeats the whole purpose of having those common settings declared in a single location.

Publish Web dialog doesn't detect my entity framework 5 context as Code First

I've recently upgraded a WFC project that uses Entity Framework from v4.3.1 to 5.0.
I'm running Coded migrations only (no automatic migrations).
Previously, I was using the Publish Profiles to deploy this solution and apply the migrations. Since upgrading the project to EF5, the migrations portion no longer works and the publish dialog doesn't detect the context as having code-first migrations.
Specifically, the .pubxmlfile changed from detecting my context as <Object Type="DbCodeFirst">to <Object type="DbDacFx"> which is incorrect for my context.
As a workaround, I've manually added the <entityFramework> database initializer configuration to my web.config transforms, but I'd like to understand why the publish profiles aren't working. That was a much nicer solution.
It once happened on me when merging another developer's commit and triggered Visual Studio project reload. That's how it caused the "DbCodeFirst" to "DbDacFx" change.
If I restart Visual Studio then everything goes back to what it should be.
Just another thought.
You probably missed adding the reference to EntityFramework into your project. By just adding the reference you should be able to control whether or not the DbCodeFirst option is available or not.
As this post suggests, try using the fully-qualified name of your DbContext as the name of the connection string. Instead of:
Web.config
<connectionStrings>
<add name="MyContext" .../>
</connectionStrings>
Use:
Web.config
<connectionStrings>
<add name="MyNamespace.AnotherNamespace.MyContext" .../>
</connectionStrings>
In my case, in order to use my existing publish profiles (.pubxml), I also had to manually edit the <ObjectGroup Name="..." ...>. Probably recreating the publish profiles would work too.
I had the same issue but not in the same context.
I had been using Code First Migrations with existing ASP.NET MVC 5.2.3 application using EF 6.1.3 for a month without issues. At one point in time I added support for Windows Azure Storage but I made some mistakes:
I added a new project. Unfortunately I chose "Console Application" instead of "Class Library". I tried to fix it by changing it back to "Class Library" in "Project Settings"
I used Nuget to Install-Package WindowsAzure.Storage but I installed it on the MVC project and not on the class library. I tried to fix it by doing Uninstall-Package on the MVC project and installing it to the correct project
I called the class in the class library "WorkOrderStorage"
I added the connectionString to <connectionStrings> element in web.config and a transformation in web.release.config
I guess my project was now in an inconsistent state. I noticed that it would forget about Code First Migrations (I monitored the changes to the .pubxml file):
when I put a reference between the MVC project and the library
containing the WorkOrderStorage class
when I created an empty 'WorkOrderStorage' class in one of the existing libraries
In the end I fixed it by recreating this library correctly from scratch as a class library (because of observation 1). I also named the class WorkOrderRepository (because of observation 2).

Moles 0.94.51023.0 error on VS 2010 SP1

I'm trying to mole System.ServiceModel v4 in VS 2010 SP1 with Moles 0.94.51023.0 and I keep getting the following errror:
The type or namespace name 'IHttpCookieContainerManager' does not exist in the namespace 'ssm::System.ServiceModel.Channels' (are you missing an assembly reference?) [my-test-project.Test\obj\Debug\Moles\ssm\m.g.csproj] my-test-project.Test\m.g.cs 293022 43
This interface appears to have been removed from System.ServiceModel.dll in .NET 4.0 as I can only find it in System.ServiceModel.dll v2.0.5.0 (Silverlight) when I search in the Object Browser.
I'm able to reproduce this via the cmdline using moles.exe and I've tried altering the moles file to only generate type names I specify but it doesn't appear to make any difference. This was working fine prior to my upgrade to VS2010 SP1 so I suspect it's a bug, but any help would be appreciated.
Thanks
Nick
I debugged this on my own as well and found that the root cause appears to be that VS2010 SP1 (and the related GDR KB update for .NET 4) update one set of DLLs but not another:
The System.ServiceModel.dll in %ProgramFiles(x86)%\Referenced Assemblies\ doesn’t match the one in the .NET v4 install at %windir%\Microsoft.NET\Framework64\v4.0.30319...
Post VS 2010 SP1 update:
%Program Files(x86)%\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.ServiceModel.dll -> File version 4.0.30319.1
%windir%\Microsoft.NET\Framework64\v4.0.30319\System.ServiceModel.dll -> File version 4.0.30319.225
Comparing these two dlls in the Object Browser in VS as well as in Reflector yields the result that the IHttpCookieContainerManager interface has been removed in the newer file. So I suspect that this is a combination of .NET probing finding the newer DLL and Moles reflecting over the older one when doing mole/stub generation. I was able to manually generate a Moles dll for the newer DLL by running the Moles exe manually with no reference paths of any kind as opposed to the MSBuild target that adds a bunch of ref paths during a build.
I don't know why that happens, but I had the same issue, and I resolved it by using Moles type filters, and only including the ones I really need (which has the nice side-effect of speeding up compilation quite a lot!!). This is an example .moles file I'm using:
<Moles xmlns="http://schemas.microsoft.com/moles/2010/">
<Assembly Name="System.ServiceModel"/>
<StubGeneration>
<Types>
<Clear/>
<Add Namespace="System.ServiceModel.Description!"/>
</Types>
</StubGeneration>
</Moles>
It looks like it was a conflict between the System and System.ServiceModel assemblies that Moles was using for compilation.
I had recently installed the Microsoft .NET Framework 4.5.
After uninstalling this and re-installing 4.0 everything worked.
Well, in case anyone is working with legacy code and happens to be cornered into using Microsoft Moles, I've done extensive digging on this topic and hope to save some from the anger and frustration I encountered.
I tried using the accepted answer's suggestion, which meant going to the Moles directory (in C:\Program Files..) and running the command line utility (moles.exe) as Administrator. There a lot of options, one of which allows you to include referenced assemblies (as suggested above).
However, even when trying to run the utility without referenced assemblies, the utility ultimately calls the C# compiler (csc.exe) with pre-defined referenced assembly paths, which is where I conclude that the confusion between .NET Framework versions occurs. I couldn't get it not to include these assembly paths.
My specific scenario was that I was trying to Mole a custom assembly, however because, apparently, I had .NET 4.5 installed on this machine, it was complaining upon compilation about System.Collections.Generics IReadOnlyCollection, IReadOnlyDictionary, and I think one other.
Solution: The only solution I got to work was to use Mole filters, which I read about on other posts and on the Microsoft Moles website (there is a special link for .NET 4.5 troubleshooting on the main page). In Visual Studio, I simply added the Moles assembly to my unit test project for my referenced custom assembly via right click in Solution Explorer. I then tried to build. For each error I received, I noted the offending classes and excluded them from being Shimmed or Stubbed by adding the following to the moles file:
<Moles xmlns="http://schemas.microsoft.com/moles/2010/">
<Assembly Name = "MyCustomAssembly" />
<StubGeneration>
<Types>
<Remove TypeName="ClassThatUsesIReadOnlyCollectionEtc" />
</Types>
</StubGeneration>
<MoleGeneration>
<Types>
<Remove TypeName="ClassThatUsesIReadOnlyCollectionEtc" />
</Types>
</MoleGeneration>
</Moles>
Now clearly that's not going to work if you need the classes that you're excluding from mole/stub generation, however for my case it worked fine because the offending classes were not important and I wouldn't be needing to Stub or Shim anything in those classes.