Do you have a clean installation of the production release?
Do you use your custom type mapping to regenerate your data model?
I don't know in what scenario that you still get the infamous error (Error 2019: Member Mapping specified is not valid).
Hopefully the following copy-and-paste would help.
It's possible that when restart VS or close and reopen a project within VS, ODT and its dependency ODP.NET are not loaded yet.
In this case following tricks should solve the error.
(copied and pasted from the readme.txt in Beta 2 version)
3. Tips to Resolve Compilation Errors With Custom Mapping
When custom mapping in a configuration file has changed, re-generate the data
model to solve compilation errors incurred by the new changes.
In some scenarios, custom mapping can cause compilation errors, when a
project that uses custom mapping is loaded by Visual Studio. There are
few ways to resolve the compilation errors:
(a) Open Visual Studio Help/About Microsoft Visual Studio and click OK
button to exit the dialog box or
(b) Open the to-be-used connection in Server Explorer
Then compile the project again to eliminate the compliation errors.
Once you have done the above and are still seeing custom type mapping related messages,
You may use MKSNT touch.exe (or the like utility) on app.config to change its timestamp but leave
its content intact.
This will force ODT/ODP to reread the custom type mapping because the timestamp of app.config has changed.
One thing I've found changed between beta 2 and the production release is that in the production release, this isn't done automatically when you bring in a new table.
In beta 2 if you created the custom mapping then did an update model from database to add a table, the new mappings are reflected in the model. In the production version they're not, they come in as int16 and you have to change them in the model to boolean. If you do that, then it works (because the custom mapping gets picked up at runtime).
Not sure why that changed, but it might be what's causing some of these issues.
Thank you for the input.
I cannot reproduce the behavior you described with the production release.
Update model from database to add a table.
As long as <add name="bool" value="edmmapping number(1, 0)" /> is in app.config and
this table has number(1, 0) column, then such column is mapped to Boolean as expected.
After doing so, create a new entity framework model from the database in that project (only one project in this case to keep it simple), with one table. Try to run it. I immediately get an error because the model has the number(1,0) columns mapped to int16 instead of bool, and at runtime it expects bool.
So I'm still having the problem. When I create the model, it's ignoring the web.config settings completely and just using the defaults. At runtime it tries to use the configured settings and fails because that's not what the model is.
Same problem with a console app. It also behaves that way if I simply use the base EF 4.0 libraries in .net 4 or if I use NuGet to pull down the current version (EF 4.3). As before, the settings ARE picked up at runtime, so I don't think there's anything wrong with my config file.
I've also found that the release version of the development tools forgets connection settings. It remembers the connection itself, but if you update the connection in server explorer to change the displayed schemas, that change is forgotten as soon as you close Visual Studio. Beta 2 remembered it, and beta 2 also didn't have this problem of ignoring my config file when creating the model (unlike beta 3 and the release).
Hi! I feel your pain. I have had some similar issues and have made a few discoveries that have allowed me to get around these issues through a couple of ODAC releases. I just upgraded from the previous beta 3. With the beta 3 I found that any time the .edmx was changed or validated I would get these errors. I could get rid of the errors by moving my edmmapping in the App.Config from on place to another and rebuilding. Very annoying, but I could proceed. Sometimes the errors would return seemingly without cause, but my kludgey fix would get rid of them. The reasons for the issue or why my recurring fix works are beyond me. It will differ a bit depending on what you are remapping, but this is the piece I move around.
Now I have downloaded the current release ODAC 11.2 Release 4 (220.127.116.11.0) and my ludgy fix no longer gets rid of the errors. Well it is always good to know someone who has suffered .NET development longer than you. I was whine to my more experienced friend and he knew of the issue and it is not restricted to Oracle. He has experienced this issue with SQL Server and mySQL as well. He found a fix by accident after much suffering (no claim of brilliance) and why it works is a mystery. If I click on the designer background and "Generate Database from Model…" and save the file to my project then my issues are gone. I am told I may have to occasionally do this again if the issues reappear. The presence of the file is benign and solves my issues. Let me know if the works for you.
I found a way to get rid of the error # 2019 in my Visual Studio. I additionally added the mapping to the Visual Studio 2010 devenv.exe.config (i.e. located in c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ ).