.NET 4.5 compatibility heads up
Posted: Fri 24 Aug 2012 08:42
All,
Just a heads up on .NET 4.5 compatibility. I installed .NET 4.5 on my development PC. However, my application targets .NET 4.0. As you may know .NET 4.5 is an in-place upgrade of .NET 4.0, rather than a side-by-side installation. So if you have .NET 4.5 installed, but you are targeting .NET 4.0, at runtime you will be running .NET 4.5. Turns out that the core Entity Framework code in .NET 4.5 generates different sql than .NET 4.0. Note that I am talking about the core Entity Framework code in the .NET Framework, not about the Entity Framework NuGet package. I found out about the different sql that was generated when I deployed the code to a test server that did not have .NET 4.5 installed.
The generated sql actually failed to parse on the test database. The development database had some new fields added to tables, that were not yet deployed to the test database. The EF model was updated from the development database (database-first is used). The LINQ code though did not select from any of those new fields so I expected it would run fine on the older test database. Well, you know how the generated sql sometimes contains inline select statements that select all the fields from a table when the outer select statements picks only the ones you asked for? That's why the sql did not parse on the test database because the inline select statement was selecting from all the fields the EF model knew about, but some of those fields were not yet deployed on the test database.
The sql on my developer PC was different. On my developer pc the inner select statement only selects those fields that are needed by the outer select statement (or where clauses etc). Much better sql, but I could not understand why it was different. At first I thought a different version of Devart dotConnect for Oracle was deployed on the test server. I made sure they were the same version. Turns out the generated sql on my developer PC was different because I had .NET 4.5 installed. Sure, .NET 4.5 generates better sql than .NET 4.0. But when you target .NET 4.0 you expect it to use .NET 4.0. Why o why is .NET 4.5 an in-place upgrade???
For my test server there were in fact two solutions now: either deploy the latest version of the database, or install .NET 4.5. Of course the correct solution was to deploy the latest version of the database to the test server. Perhaps I should also remove .NET 4.5 from my developer PC while I'm still targeting .NET 4.0.
Remco
Just a heads up on .NET 4.5 compatibility. I installed .NET 4.5 on my development PC. However, my application targets .NET 4.0. As you may know .NET 4.5 is an in-place upgrade of .NET 4.0, rather than a side-by-side installation. So if you have .NET 4.5 installed, but you are targeting .NET 4.0, at runtime you will be running .NET 4.5. Turns out that the core Entity Framework code in .NET 4.5 generates different sql than .NET 4.0. Note that I am talking about the core Entity Framework code in the .NET Framework, not about the Entity Framework NuGet package. I found out about the different sql that was generated when I deployed the code to a test server that did not have .NET 4.5 installed.
The generated sql actually failed to parse on the test database. The development database had some new fields added to tables, that were not yet deployed to the test database. The EF model was updated from the development database (database-first is used). The LINQ code though did not select from any of those new fields so I expected it would run fine on the older test database. Well, you know how the generated sql sometimes contains inline select statements that select all the fields from a table when the outer select statements picks only the ones you asked for? That's why the sql did not parse on the test database because the inline select statement was selecting from all the fields the EF model knew about, but some of those fields were not yet deployed on the test database.
The sql on my developer PC was different. On my developer pc the inner select statement only selects those fields that are needed by the outer select statement (or where clauses etc). Much better sql, but I could not understand why it was different. At first I thought a different version of Devart dotConnect for Oracle was deployed on the test server. I made sure they were the same version. Turns out the generated sql on my developer PC was different because I had .NET 4.5 installed. Sure, .NET 4.5 generates better sql than .NET 4.0. But when you target .NET 4.0 you expect it to use .NET 4.0. Why o why is .NET 4.5 an in-place upgrade???
For my test server there were in fact two solutions now: either deploy the latest version of the database, or install .NET 4.5. Of course the correct solution was to deploy the latest version of the database to the test server. Perhaps I should also remove .NET 4.5 from my developer PC while I'm still targeting .NET 4.0.
Remco