DevForce 2010: IDataSourceKeyResolver and deployment

IDataSourceKeyResolver and deployment

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2010
Forum Discription: For .NET 4.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=3319
Printed Date: 13-May-2026 at 8:52am

Topic: IDataSourceKeyResolver and deployment

Posted By: mikke63
Subject: IDataSourceKeyResolver and deployment
Date 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

Replies:

Posted By: DenisK
Date 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.

See http://drc.ideablade.com/xwiki/bin/view/Documentation/logged-info - http://drc.ideablade.com/xwiki/bin/view/Documentation/logged-info for more info.

Posted By: mikke63
Date 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

Posted By: DenisK
Date 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.

Posted By: mikke63
Date 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.

Posted By: kimj
Date 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.

Posted By: mikke63
Date 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.

Posted By: mikke63
Date 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.

uploads/1256/DebugLog1.txt - uploads/1256/DebugLog1.txt

Posted By: kimj
Date 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 - http://forums.asp.net/t/1692257.aspx/1 .

Posted By: midnit
Date 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!

Posted By: mikke63
Date 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