No valid exports were found that match the constraint

[Daniel Lee]

Hi,

I am testing out Simple.Data for the first time and am having a few
problems getting up and running. I created a new solution (VS 2010
and .NET 4) with two projects one data project and one test project.
And when trying to connect to a sql server express 2008 database I get
the following error (from MEF I think)

System.ComponentModel.Composition.ImportCardinalityMismatchException :
No valid exports were found that match the constraint
'((exportDefinition.ContractName == "Ado") AndAlso
(exportDefinition.Metadata.ContainsKey("ExportTypeIdentity") AndAlso
"Simple.Data.Adapter".Equals(exportDefinition.Metadata.get_Item("ExportTypeIdentity"))))',
invalid exports may have been rejected.
at
System.ComponentModel.Composition.Hosting.ExportProvider.GetExports(ImportDefinition
definition, AtomicComposition atomicComposition)
at
System.ComponentModel.Composition.Hosting.ExportProvider.GetExportCore(String
contractName)
at Simple.Data.MefHelper.Compose(String contractName)
at Simple.Data.AdapterFactory.DoCreate(String adapterName,
IEnumerable`1 settings)
at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey
key, Func`2 valueFactory)
at Simple.Data.CachingAdapterFactory.Create(String adapterName,
IEnumerable`1 settings)
at Simple.Data.DatabaseOpener.OpenConnectionMethod(String
connectionString)
at Simple.Data.DatabaseOpener.OpenConnection(String connectionString)
at TestSimpleData.Repo..ctor() in Repo.cs: line 11
at IntegrationTests.Test1.TestOpen() in Test1.cs: line 12

I cloned the Simple.Data project from Github and put the exact same
code and connection string in a test in the DatabaseOpenerTests test
class and it worked fine there. I then tried taking the binaries from
the cloned Github project but still got the same error. So I am
totally stumped. Any one got any clues?

Cheers,
Daniel

[Mark Rendle]

If you're using NuGet, you need to install the Simple.Data.SqlServer
package. I have an open issue to replace this exception with a
friendlier one.

Cheers,
Mark

[Grumpydev]

Incidentally, I got the same error when I had .4.0 on the end of the providerName like it is in Mr. Gu's blog:

http://weblogs.asp.net/blogs/scottgu/image_7915AE17.png

[Daniel Lee]

Hi Mark,

Thanks for the answer. I did use Simple.Data.SqlServer from Nuget
(version 0.9.3.2), I should have written that in my question. So I
have 3 dlls referenced in my project: Simple.Data, Simple.Data.Ado and
Simple.Data.SqlServer. I thought that the problem was the connection
string for ages and that Simple.Data didn't recognise it as an Sql
Server connection.

Here is the code:

var db = Database.OpenConnection(@"Server=COMPUTERNAME
\SQLEXPRESS;Database=TEST;User Id=Test;Password=test;");

Have tried putting it an app.config file and using Database.Open as
well.

Thanks for the help,
Daniel

[Mark Rendle]

Right, this is something I've been meaning to sort out, so I'm going
to open an issue for it on Github and get a release out ASAP.

In the meantime, if you specify the provider name as the second
parameter to OpenConnection, it will find the import:

var db = Database.OpenConnection(@"Server=COMPUTERNAME\SQLEXPRESS;Database=TEST;User

Id=Test;Password=test;", "System.Data.SqlClient");

Cheers,
Mark

[Daniel Lee]

Hi Mark,

I'm not seeing a Database.OpenConnection method with two input
parameters. Did you mean Database.Opener.OpenConnection? Still getting
the same error with that method. Will try on another computer to see
if it make any difference.

Cheers again,
Daniel

[Mark Rendle]

Hi Daniel,

Can you update to the latest NuGet (0.9.4.1) and see if it helps?

Cheers,
Mark

[Mark Rendle]

Are the Simple.Data.*.dll files getting copied to the build folder of
the test project?

[Mark Rendle]

Just checked this, and you do need to add the references to the test
project as well as the class library project.

[Daniel Lee]

Yes, the three dlls are getting copied to the bin\Debug folder. But
I'm getting a different error now:

Simple.Data.SimpleDataException : No ADO Provider found.

at Simple.Data.MefHelper.Compose(String contractName)
at Simple.Data.AdapterFactory.DoCreate(String adapterName,
IEnumerable`1 settings)
at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey
key, Func`2 valueFactory)
at Simple.Data.CachingAdapterFactory.Create(String adapterName,
IEnumerable`1 settings)
at Simple.Data.DatabaseOpener.OpenConnectionMethod(String

connectionString, String providerName)
at Simple.Data.DatabaseOpener.OpenConnection(String connectionString,
String providerName)
at TestSimpleData.Repo.GetStuff() in Repo.cs: line 15
at IntegrationTests.Test1.TestOpen() in Test1.cs: line 13

Trying to figure out if I'm doing something strange or wrong
somewhere.

Thanks for all the help!

[Daniel Lee]

Bingo!

Referencing Simple.Data in the test project did the trick. Thank you
so much for your help. Amazingly fast response.

[Mark Rendle]

And there was me feeling bad that this took a whole day to sort out.

Glad you're up and running now, anyway, hope this initial problem
hasn't put you off.

Cheers,
Mark

[Mark Rendle]

I've added that form as a ContractName on the export, so it should work now.

[Daniel Lee]

I was fully expecting to have to fix it myself and send in a pull
request so thank you for the quick turnaround. I'm going to give
Simple.Data a try for a legacy ASP.NET Webforms project with a ton of
CRUD stored procedures. The project feels too small for NHibernate and
it feels like I can get up and running very fast with Simple.Data.
Loving the use of dynamic, feels like it will be a perfect fit for
this project.

/Daniel

[bvgheluwe]

Strange, why should I add a reference to simple.data in other projects than the data access project?

Op maandag 5 september 2011 18:40:54 UTC+2 schreef Mark Rendle het volgende:

[Mark Rendle]

Because Simple.Data loads adapters and providers dynamically using MEF. It's actually the other way around: your data access project only needs to reference Simple.Data.Core; your application or test projects are the ones that need references to Simple.Data.Ado, Simple.Data.SqlServer or whatever as well. In fact, they don't need project references, that's just the easiest way to make sure that the adapter and provider are there. But if you copy the assemblies in yourself, you can switch databases without even recompiling your code.

This means, for example, that you can use SqlServer in your actual application, but SQLite, SQL Compact or just the InMemoryAdapter in your test apps.

Hope that makes sense.

Mark

--
You received this message because you are subscribed to the Google Groups "Simple.Data" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simpledata+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Bart]

After reading your answer a couple of times, I think I'm starting to understand it (I don't know anything about MEF).

Does this mean that:

1. I can remove the references to the ADO and SQLServer libraries from the data access project (and leaving the reference to simple.data.core)?
2. I should copy the dlls (ado and sqlserver) to whatever project that uses data access, without an explicit reference?

2013/2/2 Mark Rendle <ma...@markrendle.net>

[Mark Rendle]

Basically yes, although for step 2, installing the NuGet packages to the main project is fine too, and is the easiest way of keeping things current.