I’m working with Entity Framework 5 using code-first with DBContext and no config file (all defaults). I have SQL Server 2008 R2 with the default instance .\SQLEXPRESS installed and also SQL Server 2012 Express LocalDB (localdb)\v11.0).
The framework doesn’t seem to be able to handle these side by side and throws an exception when I run my app. I confirmed by removing SQL Server 2012 Express LocalDB and it works fine.
An interesting point is that when I run NuGet to install Entity Framework in either VS 2010 or VS 2012 it crashes VS and fails to install the framework. My suspicion is that similar code is being used to find/select servers in both cases. This post is intended to bring this to the attention of the Entity Framework team and not necessarily solve it here. I’d be happy to provide any addtional data that the team might require.
Edit –
I found where the problem with NuGet may be exposed:
When you installed the EF NuGet package a default connection factory
was registered that points to either SQL Express or LocalDb, depending
on which one you have installed.
It is hard to tell whether it is a EF bug or not since there is not enough details in the post. The scenario where you have both SqlExpress and LocalDB is supported and should work. SqlExpress is by default installed with VS2010 but not with VS2012 where the default database solution is LocalDb. It’s true that there is a piece of code that detects if you have SqlExpress installed on your box and if you do it will add entries to you config file accordingly. AFAIR on VS2012 if you don’t have SqlExpress LocalDB should be used by default. I have never seen VS crashing when installing EF nuget package. As I said above – there is not enough details to tell whether this is an EF bug or not – there just too many things in the play i.e. VS itself (the installation / common components can be somehow broken), NuGet, PowerShell (the scripts actually installing dlls are PowerShell scripts) and of course EF. Feel free to report this issue here: http://entityframework.codeplex.com/ – this way the bug will be looked at by the EF team. Put as much details as possible so that we are able to replicate the problem.