[C#] EF4.0 Model niet bekend in service, metadata onbekend

[Jan_V]

Momenteel zit ik met een probleem dat de metadata van m'n EF4.0 niet beschikbaar is in m'n WCF-service, waardoor er niet succesvol een connectie kan worden opgezet. De connectiestring wordt niet geaccepteerd.

Eerst maar wat achtergrondinformatie.
Momenteel ben ik bezig met het maken van een website, hierbij wil ik de presentatielaag en 'de rest' scheiden in 2 tiers. De communicatie tussen de 2 lagen geschied door middel van een WCF-service. Tot nu toe niet heel spannend.
In de niet-presentatie-tier heb ik meerdere layers, de basis bestaat uit een WCF-service, BLL en DAL. De BLL en DAL zijn 2 losstaande class libraries. De service, BLL en DAL zijn gekoppeld door references.
Ook heb ik nog een 2-tal projecten (ook class libraries) die zorgen voor de werking van de EF objecten. Hier heb ik onder andere de walkthrough van deze link gebruikt: http://blogs.msdn.com/ado...the-entity-framework.aspx
Ik heb dus nog een project met het Model en een project met de Entities.
In de DAL heb ik een reference gemaakt naar zowel de Entities als het Model
In de BLL en service heb ik alleen een reference gemaakt naar de Entities. Zo heb ik afgedwongen dat er alleen in de DAL naar de database kan worden weggeschreven.

Inmiddels heb ik de code van enkele methoden geschreven in alle lagen van de applicatie en wilde ik testen of het geheel ook ging werken.

Het eerste probleem dat ik had was de fout:

The specified named connection is either not found in the configuration, not intended to be used with the EntityClient provider, or not valid.

Door op deze fout te zoeken kwam ik er al vrij snel achter dat ik de connectiestring nog in m'n WCF-service moest definieren. Op zich wel logisch natuurlijk.
In de DAL was een app.config aangemaakt met de juiste connectiestring. Ik had gehoopt dat deze app.config wel zou worden gekopieerd naar de bin van de service en dat de connectiestring daaruit zou worden gebruikt. Iets dergelijks heb ik namelijk een keer bij een andere applicatie gezien en had gehoopt dat het op deze manier zou werken. Geeft natuurlijk niets, aangezien het snel is op te lossen door de connectiestring te kopieren naar de web.config van de service.

Nu liep ik tegen een andere fout aan, namelijk:

Unable to load the specified metadata resource.

Als je op deze fout zoekt krijg je honderden resultaten met eigenlijk 2 verschillende oplossingen.
1 methode stelt dat je de 'Metadata Artifact Processing' op Copy to 'Output Directory' moet zetten. Daarna de gegenereerde bestanden (3) moet kopieren naar de root van je applicatie en de connectiestring hierop aan moet passen.
Dit heb ik geprobeerd, maar werkte niet. In mijn geval kreeg ik eerst de melding dat de connectiestring fout was. Na wat tweaken had ik hem werkend, maar kreeg ik de melding dat de metadata weer niet gevonden kon worden.
De 2e oplossing is om de connectiestring aan te passen.
Je moet dan de res://*/...... aanpassen in res://AssemblyNameWhereTheEDMXIsLocated/....
Dit heb ik ook geprobeerd en dat werkt! Zoals in de walkthrough is te zien, staat het edmx-bestand in het Model project. Nadat ik het *-teken had vervangen door de naam van het Model project (naam van de dll) werkte de connectie naar de database. Echter, ik zou hier niet posten als er nog iets mis zou zijn.

Standaard wordt de Model dll niet in de bin-directory geplaatst bij een build. Bij het builden van de DAL komt de Model dll wel in de bin van de DAL. Nu kan ik een post-build scriptje maken dat de dll in de bin plaatst, maar waarschijnlijk doe ik iets verkeerd of zie ik wat over het hoofd. Dit lijkt me namelijk iets dat 'standaard' zou moeten werken.

In de vele voorbeelden op het internet maken ze ook n-tier applicaties, maar daar is de WCF-service ook gelijk de DAL. In zo'n geval zal alles inderdaad prima werken, aangezien je dan ook de Model tot je beschikking hebt.
Waarschijnlijk wordt dit ook opgelost door in de service een reference te maken naar het Model project, maar dat wil ik dus niet. Dan kun je in theorie namelijk gelijk in de service naar de database.

Waarschijnlijk ben ik niet de enige met dit 'probleem'. Tijdens het zoeken kwam ik eigenlijk alleen maar op sites uit waar ze de bovenste 2 oplossingen bieden. Echter is dat voor mij niet van toepassing.
Mocht het toch zo zijn dat ik hier iets heel raars aan het doen ben (en dus toch de enige ben met dit probleem), mag er ook een alternatief worden voorgesteld hoewel ik het vermoeden heb dat ik hier toch wel goed bezig ben.....

[Jan_V]

Heb m'n probleem nu opgelost.
De reden waarom m'n Model project niet mee werd genomen in de bin van de Service applicatie, is omdat ik in eigenlijk geen van de projecten het Model project gebruik. Wel heb ik een reference in de DAL naar het Model, maar het T4 template heb ik als Add as Link toegevoegd aan de DAL.
Hierdoor is VS slim genoeg om te zien dat het Model niet wordt gebruikt, dus wel weg kan worden gelaten. Op zich wel logisch dus.

Heb nu een lege klasse gemaakt in het Model project:

C#:

namespace ModelProject
{
    public class Empty
    {
    }
}

Deze gebruik ik nu in de DAL op deze manier:

C#:

var ep = new OnsKoopje.Model.Empty();

Nu wordt de Model dll wel gewoon in de bin geplaatst.

Zal nog even iets maken zodat ik deze code niet in productie aan ga roepen, maar de work-around werkt in ieder geval!

[Anoniem: 172123]

Precies dit probleem had ik gisteren ook

Ik heb ook reference naar de assembly met de metadata (edmx bestand), en die assembly komt ook netjes in de output te staan. Probleem kan dan nog steeds zijn dat de assembly niet geladen wordt, omdat je inderdaad niets uit die assembly direct gebruikt. In Global.asax heb ik daarom nog een expliciete Assembly.Load("MyProject.Model"). Ik vind dat persoonlijk netter dan een dummy type, hoewel er wellicht nog wel nettere methoden zijn.

Op forums vind je mensen die uit wanhoop afstappen van het scheiden over assemblies, en alles in één project stoppen. Jammer, want als het eenmaal werkt is het ideaal.

[EfBe]

begrijp niet echt waarom je 'model' EN 'entities' EN een 'DAL' EN een 'BLL' project.

[Jan_V]

Het Entities wordt in alle andere projecten gebruikt, zodat de entities in al die projecten gebruikt kunnen worden.
De BLL is uiteraard voor business logica. Momenteel is dat er nog niet veel, dus is het eigenlijk een wrapper om de DAL.
Alleen het Model en DAL project zou samengevoegd kunnen worden, maar vond het niet zo mooi om een database representatie te hebben in m'n DAL project.

Zie ook weinig voorbeelden waar ze dit zo ver hebben gescheiden, wellicht dat ik dus een beetje 'te' bezig ben. Vind het in ieder geval wel 'mooi' als ik er zo mee werk.

[EfBe]

Ik zie het verschil tussen entities en model niet. Model als in MVC? (dus dat je aparte classes gebruikt voor UI representaties van de entities) Dan nog zou het geen probleem moeten zijn, immers de meta-data zit op de service, en die moet toch bij de context, dus als je de context + edmx in dezelfde assembly houdt zou het altijd moeten werken (en bij MS' templates is dat sowieso een logisch gevolg)

[Anoniem: 172123]

EF4 kan self-tracking entities genereren via een code template. Dergelijke entities zijn niet meer afhankelijk van een context, dus deze kunnen gescheiden worden van de context en de metadata. Of je dat ook wilt, hangt van de architectuur af. In een n-tier architectuur is de assembly met entities gedeeld over meerdere tiers, terwijl de context en de metadata alleen vereist zijn voor data access. In tier met een UI kunnen de entities gemapt worden naar UI specifieke entities.

[Jan_V]

De eigenlijke reden hiervoor is omdat ik het zo in 2 walkthroughs heb zien werken en mij dat ook wel handig lijkt.

In de walkthrough die ik in de OP link hebben ze een project BloggingModel waar dus je edmx, T4 templates, etc. Daarna verwijderd hij de daadwerkelijke entities/types en zorgt er voor dat die in een ander project worden aangemaakt/serialized.

Doordat die entities nu in een ander project zitten kunnen die veilig worden gereferenced naar andere projecten, zonder dat je bang hoeft te zijn dat er dan ook stiekem acties in de database worden gedaan. Immers, wanneer je alles in 1 project laat, dan kun je vanuit je service of BLL ook wel een datacontext aanmaken en dan een update of select uitvoeren. Wanneer je de entities en het model van elkaar los trekt is dit niet meer mogelijk.

De entities heb ik nodig in de service, BLL en DAL. Van de service naar de website worden ze gedeserialized en geserialized. Hierdoor hoef ik het entities project niet in de echte website te referencen. De entities zijn automagisch aanwezig in het website project, omdat deze in de service werden gebruikt.

Het geheel heeft hier weinig met MVC of programmeer pattern te maken volgens mij. Toevallig maak ik daar wel gebruik van in het website project, maar dat staat dus los in het geheel van de overige projecten, omdat ik in de website gebruik maak van de objecten die ik van de WCF service heb gekregen.

Hoop dat het een beetje is te volgen. De naam van Model en Entities voor de projectnamen is misschien niet helemaal juist gekozen, daar kan wel verwarring door ontstaan denk ik.
Wellicht is het naar jou idee overkill wat ik hier doe, maar volgens mij is er geen andere (juiste) optie om er voor te zorgen dat je service en BLL niet acties naar je database kunnen doen.

[Anoniem: 172123]

Ik vind beveiliging persoonlijk niet de belangrijkste reden om entities van metadata te scheiden. Je connection string staat niet in de metadata, dus daar hoef je je geen zorgen over te maken.

In een solution heb ik een project met WCF services waar externe partijen verbinding mee maken, een MVC2 website en een Silverlight applicatie. Tussen de website en de Silverlight applicatie zit een WCF RIA Services link. Omdat RIA een eigen mechanisme heeft voor change tracking, werkt dit niet in combinatie met de T4 templates van EF4. Toch heb ik self-tracking entities nodig voor de WCF services voor externe partijen. Ik heb daarom één project met de metadata en genereer twee soorten entities: algemene, openbare, self-tracking entities en daarnaast entities specifiek voor de website en (via RIA) Silverlight applicatie.

[EfBe]

Anoniem: 172123 schreef op donderdag 27 mei 2010 @ 15:33:
EF4 kan self-tracking entities genereren via een code template. Dergelijke entities zijn niet meer afhankelijk van een context, dus deze kunnen gescheiden worden van de context en de metadata. Of je dat ook wilt, hangt van de architectuur af. In een n-tier architectuur is de assembly met entities gedeeld over meerdere tiers, terwijl de context en de metadata alleen vereist zijn voor data access. In tier met een UI kunnen de entities gemapt worden naar UI specifieke entities.

Ja weet ik, heb ik die STE templates ook zitten implementeren voor EF 4 voor llblgen pro v3 Overigens zijn de MS t4 templates niet echt nuttig in dit kader, ze genereren alles in 1 project (aangezien de T4 die de entity classes genereert de edmx nodig heeft)

Mijn vraag was waarom het project met de entity classes (de 'entities') niet het model genoemd werd, het leek er nl. op dat er NOG een project was met entity classes, maar topic starter noemt de edmx/context de 'entities'.

[Anoniem: 172123]

EfBe schreef op donderdag 27 mei 2010 @ 21:11:
Overigens zijn de MS t4 templates niet echt nuttig in dit kader, ze genereren alles in 1 project (aangezien de T4 die de entity classes genereert de edmx nodig heeft)

Dat klopt. Maar dit topic gaat toch juist over de work-around?

Je kunt in die tt files het pad aangeven waar het edmx bestand staat. Op die manier kun je met links de metadata scheiden van de gegenereerde entities over verschillende projecten. Ik vind dat persoonlijk een nette scheiding; hogere tiers hoeven geen metadata te hebben.

Probleem wat TS had, is dat de assembly met de metadata ("model") niet geladen werd, en dus de metadata niet gevonden kon worden. Oplossing daarvoor is dus expliciet de assembly laden of een class gebruiken uit die assembly.