Create a new project (e.g. C# console project)
Using the project's properties change the target framework to .NET 4.0
Create an empty ADO.NET Entity Data Model
Add 1 Entity with 1 property
Save everything (you will have a V2 EDMX because targeting .NET 4.0)
_Keeping the EDMX file open in the designer_ change the target framework to .NET 4.5
You will receive the info message that the namespaces have been updated _but_ the designer for the EDMX will be in "safe mode" - showing that it is unable to display the file. If you open this file in the XML Editor you will see that the namespaces have not in fact been changed.
Comments: I looked a little bit at this and to me it seems it could be closed as External/ByDesign/Won't Fix (in this order). Basically we decide whether to change namespaces or not when the project is retargeted based on the EF dlls the project is referencing or, if no such reference exists, based on the target .NET Framework version. I checked and things seems to work correctly if there are no references to EF dlls - namespaces are changed accordingly. If the project references only System.Data.Entity.dll things work correctly again - namespaces are changed when retargeting the project. However if the project references EntityFramework.dll namespaces will not be changed. The problem here is that an EF5 project on .NET Framework 4 will have a reference to System.Data.Entity.dll 4.0.0.0 from .NET Framework 4 and EntityFramework.dll 4.4.0.0. When retargeting the project to .NET Framework 4.5 the reference to System.Data.Entity.dll will be updated to use System.Data.Entity.dll from .NET Framework 4.5 but the referenced EntityFramework.dll version will still be 4.4.0.0 even though when installing the package we put the .NET Framework 4.5 specific version on the disk. So the issue here is that the nuget/package manager does not update packages correctly/at all when retargeting the project (this is why I said the issue can be resolved as external). With EF6 schema versions are not a problem since we support v3 on both .NET Framework 4.5 and .NET Framework 4 and when retargeting the project that references EF6 we should not change schema versions (and we don't do it). Note that due to the nuget issue we will use .NET Framework 4.5 specific version of EF6 on .NET Framework 4 which can result in weird exception (like MissingMethodException) etc. For simplicity when we discover the latest version of schema supported in the project we take all the EF dlls (i.e. System.Data.Entity.dll and EntityFramework.dll) referenced in the project and sort by version number. This generally works apart from the case where the project references System.Data.Entity.dll from .NET Framework 4.5 and EntityFramework.dll 4.x. In this case the EntityFramework.dll will take precedence even though it supports v3 schema because its version is 4.0.0.0. It's unfortunate that due to the nuget bug it's relatively easily to get into this state however it the project was setup like this intentionally v2 seems to be the right choice. Therefore I said it could be closed also as "by design" Finally fixing this might introduce a lot of confusion to a simple mental model we have now (and already quite complicated code to support this simple mental model) for a problem which may not be a real problem given that (for edmx files) it really applies to .NET Framework 4 and retargeting. If needed we could probably just document this and provide steps to resolve the problem (update the EF.dll accordingly, open the edmx file and click on watermark to bring it to the latest supported version) and resolve this bug as Won't Fix due to low pri.
Using the project's properties change the target framework to .NET 4.0
Create an empty ADO.NET Entity Data Model
Add 1 Entity with 1 property
Save everything (you will have a V2 EDMX because targeting .NET 4.0)
_Keeping the EDMX file open in the designer_ change the target framework to .NET 4.5
You will receive the info message that the namespaces have been updated _but_ the designer for the EDMX will be in "safe mode" - showing that it is unable to display the file. If you open this file in the XML Editor you will see that the namespaces have not in fact been changed.
Comments: I looked a little bit at this and to me it seems it could be closed as External/ByDesign/Won't Fix (in this order). Basically we decide whether to change namespaces or not when the project is retargeted based on the EF dlls the project is referencing or, if no such reference exists, based on the target .NET Framework version. I checked and things seems to work correctly if there are no references to EF dlls - namespaces are changed accordingly. If the project references only System.Data.Entity.dll things work correctly again - namespaces are changed when retargeting the project. However if the project references EntityFramework.dll namespaces will not be changed. The problem here is that an EF5 project on .NET Framework 4 will have a reference to System.Data.Entity.dll 4.0.0.0 from .NET Framework 4 and EntityFramework.dll 4.4.0.0. When retargeting the project to .NET Framework 4.5 the reference to System.Data.Entity.dll will be updated to use System.Data.Entity.dll from .NET Framework 4.5 but the referenced EntityFramework.dll version will still be 4.4.0.0 even though when installing the package we put the .NET Framework 4.5 specific version on the disk. So the issue here is that the nuget/package manager does not update packages correctly/at all when retargeting the project (this is why I said the issue can be resolved as external). With EF6 schema versions are not a problem since we support v3 on both .NET Framework 4.5 and .NET Framework 4 and when retargeting the project that references EF6 we should not change schema versions (and we don't do it). Note that due to the nuget issue we will use .NET Framework 4.5 specific version of EF6 on .NET Framework 4 which can result in weird exception (like MissingMethodException) etc. For simplicity when we discover the latest version of schema supported in the project we take all the EF dlls (i.e. System.Data.Entity.dll and EntityFramework.dll) referenced in the project and sort by version number. This generally works apart from the case where the project references System.Data.Entity.dll from .NET Framework 4.5 and EntityFramework.dll 4.x. In this case the EntityFramework.dll will take precedence even though it supports v3 schema because its version is 4.0.0.0. It's unfortunate that due to the nuget bug it's relatively easily to get into this state however it the project was setup like this intentionally v2 seems to be the right choice. Therefore I said it could be closed also as "by design" Finally fixing this might introduce a lot of confusion to a simple mental model we have now (and already quite complicated code to support this simple mental model) for a problem which may not be a real problem given that (for edmx files) it really applies to .NET Framework 4 and retargeting. If needed we could probably just document this and provide steps to resolve the problem (update the EF.dll accordingly, open the edmx file and click on watermark to bring it to the latest supported version) and resolve this bug as Won't Fix due to low pri.