| Author |
Share Topic Topic Search Topic Options
|
mikke63
Newbie
Joined: 01-Sep-2011
Location: Norway
Posts: 19
|
Post Options
Quote Reply
Topic: IDataSourceKeyResolver and deployment Posted: 21-Mar-2012 at 7:49am |
Now it all works! As you both have suggested it turned out to be a wrong version of the Oracle Data Provider on the production server. It was one version older than on the development machine, and did not properly support Entity Framework. Thanks for all help; I would have used some time to figure out the connection between the "general purpose" exception thrown by DevForce and the ODP version. Case closed, Mikael
|
 |
midnit
Senior Member
Joined: 22-Jun-2009
Location: Charlotte
Posts: 112
|
Post Options
Quote Reply
Posted: 20-Mar-2012 at 10:15am |
I use Oracle and I have seen this in two cases.
1. The provider wasn't installed properly - 32bit vs 64bit vs version supporting proper parameters (but you aren't using any special params)
2. Debug mode ran differently than Release mode - even locally but it appeared the problem was only on the server (built in release mode).
What version of IIS is prod? Is your windows 64bit? Is the server? Same version of odp.net?
I wish you a quick resolution!
|
 |
kimj
IdeaBlade
Joined: 09-May-2007
Posts: 1391
|
Post Options
Quote Reply
Posted: 19-Mar-2012 at 12:22pm |
Thanks mikke63. The connection string does look OK. I've seen reports of problems with single/double quotes within a connection string, but that doesn't appear to be the problem. Is there any possibility that you can trap the exception and inspect the inner exception(s)? DevForce is throwing that exception when an ArgumentException is raised when opening the EF ObjectContext, and it appears that an ArgumentException can be thrown for any number of reasons. Since the problem occurs only when deployed, I'd guess a configuration-related problem, either with the Oracle provider or IIS. Here's a promising link to someone reporting a problem with their data provider - http://forums.asp.net/t/1692257.aspx/1.
|
 |
mikke63
Newbie
Joined: 01-Sep-2011
Location: Norway
Posts: 19
|
Post Options
Quote Reply
Posted: 19-Mar-2012 at 1:17am |
I've put in som logging to the GetKey method. The complete log file is attached for completness. As the last part of the log file shows my GetKey method is called as expected. The default connection string is fetched according to the keyName argument, and then modified as defined by the keyExtension argument. Finally the new connection string is wrapped in a ClientEdmKey with the assembled keyName and returned.
Edited by mikke63 - 19-Mar-2012 at 1:21am
|
 |
mikke63
Newbie
Joined: 01-Sep-2011
Location: Norway
Posts: 19
|
Post Options
Quote Reply
Posted: 13-Mar-2012 at 6:33am |
|
I will put in some TraceFns later this week. Will post back here as soon as I have some more info.
|
 |
kimj
IdeaBlade
Joined: 09-May-2007
Posts: 1391
|
Post Options
Quote Reply
Posted: 12-Mar-2012 at 2:47pm |
Denis is out sick today, so I'll try to help. The error message you're getting is somewhat general purpose, and would most commonly indicate that your IDataSourceKeyResolver hasn't been found. Since your implementation has been found, then the next question is what is its GetKey method returning, and why does DevForce (or EF) think it's invalid? If you can add TraceFns diagnostic messages to your code that will help isolate the problem. The TraceFns messages will be written to the debug log, along with DevForce log messages, and are a handy tool for diagnosing problems outside of Visual Studio. If it's not possible to modify the code ... then we'll have to think of Plan B.
|
 |
mikke63
Newbie
Joined: 01-Sep-2011
Location: Norway
Posts: 19
|
Post Options
Quote Reply
Posted: 12-Mar-2012 at 4:07am |
|
Sorry for being unclear; the above log file entry verifying probing and discovery is fetched from the deployed application, i.e. not when run from VS2010.
|
 |
DenisK
IdeaBlade
Joined: 25-Aug-2010
Posts: 715
|
Post Options
Quote Reply
Posted: 08-Mar-2012 at 11:19am |
Thanks for the info. That's good to know. Now the next thing to check is if the log shows the same thing i.e. discovered your non-default IDataSourceKeyResolver when not run from within VS 2010.
My guess is it doesn't since it's throwing the exception above. Verify that the assembly containing PilenKlage.DevForceDataSource is also deployed, probed and discovered.
|
 |
mikke63
Newbie
Joined: 01-Sep-2011
Location: Norway
Posts: 19
|
Post Options
Quote Reply
Posted: 08-Mar-2012 at 12:48am |
Hi, The probing/discovery seems to be successfull. This entry is found in the log file: CompositionContext: '-IbDefault-' - Probed for non-default
'IDataSourceKeyResolver' and found 'PilenKlage.DevForceDataSource'. I have also verified that the GetKey method runs to completion and does what it should. As mentioned above, it all works when run from within Visual Studio 2010. Any other ideas? Thanks
|
 |
DenisK
IdeaBlade
Joined: 25-Aug-2010
Posts: 715
|
Post Options
Quote Reply
Posted: 07-Mar-2012 at 4:22pm |
Hi mikke63,
You might want to ensure that the assembly containing your custom IDataSourceKeyResolver is being probed and discovered. The debug log will contain more detailed information regarding this.
|
 |
mikke63
Newbie
Joined: 01-Sep-2011
Location: Norway
Posts: 19
|
Post Options
Quote Reply
Posted: 07-Mar-2012 at 3:24am |
I have a MVC3 application using DevForce 6.1.6.0. Depending on url parameters I want to access different databases / using different crendetials. This is solved by creating my own IDataSourceKeyResolver class, putting the connection logic in the GetKey method. Running from Visual Studio 2010 using the development server this works excellent and the application switches databases as required. But when deployed to server I get this exception: Key 'Entities_Dynamic1': The connection string for Key 'Entities_Dynamic1' was not found or is invalid. A default IdeaBladeConfig is in use and does not contain either connectionStrings or EdmKeys. Ensure a valid configuration file containing connection information is present, or implement a custom IDataSourceKeyResolver. What am I missing in the deployment or server configuration? (The most frustrating is that I experienced this same exception early in the development process, but I'm completely unable to remember how I fixed it.) Thanks
|
 |