MetadataException: nie można załadować określonego zasobu metadanych

Ta mała zmiana pomaga w tym problemie.

Mam rozwiązanie z 3 projektu.

connectionString="metadata=res://*/Model.Project.csdl|res://*/Model.Project.ssdl|res://*/Model.Project.msl;

Zmień na

connectionString="metadata=res://*/;

Możesz uzyskać ten wyjątek, gdy Edmx jest w jednym projekcie, a Ty używasz go z innego.

Powodem jest to, że Res://*/ jest uri, który wskazuje na zasoby w bieżącym zbiorze. Jeśli Edm jest zdefiniowany w innym złożeniu niż kod, który go używa, res: / / * / nie zadziała, ponieważ zasobu nie można znaleźć.

Zamiast podawać '*', musisz podać pełną nazwę zgromadzenia (w tym token klucza publicznego). Eg:

res://YourDataAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=abcdefabcedf/YourEdmxFileName.csdl|res://...

A lepszym sposobem konstruowania łańcuchów połączeń jest użycie EntityConnectionStringBuilder:

public static string GetSqlCeConnectionString(string fileName)
{
    var csBuilder = new EntityConnectionStringBuilder();

    csBuilder.Provider = "System.Data.SqlServerCe.3.5";
    csBuilder.ProviderConnectionString = string.Format("Data Source={0};", fileName);

    csBuilder.Metadata = string.Format("res://{0}/YourEdmxFileName.csdl|res://{0}/YourEdmxFileName.ssdl|res://{0}/YourEdmxFileName.msl", 
        typeof(YourObjectContextType).Assembly.FullName);

    return csBuilder.ToString();
}

public static string GetSqlConnectionString(string serverName, string databaseName)
{
    SqlConnectionStringBuilder providerCs = new SqlConnectionStringBuilder();

    providerCs.DataSource = serverName;
    providerCs.InitialCatalog = databaseName;
    providerCs.IntegratedSecurity = true;

    var csBuilder = new EntityConnectionStringBuilder();

    csBuilder.Provider = "System.Data.SqlClient";
    csBuilder.ProviderConnectionString = providerCs.ToString();

    csBuilder.Metadata = string.Format("res://{0}/YourEdmxFileName.csdl|res://{0}/YourEdmxFileName.ssdl|res://{0}/YourEdmxFileName.msl",
        typeof(YourObjectContextType).Assembly.FullName);

    return csBuilder.ToString();
}

Jeśli nadal napotkasz wyjątek, otwórz zespół w reflektorze i Sprawdź nazwy plików dla Twojego .csdl,ssdl i .pliki msl. Gdy zasoby mają inne nazwy niż te określone w wartości metadanych, nie będzie to działać.

Miałem podobny błąd. Odtworzyłem projekt (długa historia) i wyciągnąłem wszystko ze starego projektu. Nie zdawałem sobie sprawy, że mój model był wcześniej w katalogu o nazwie "Model", a teraz był w katalogu o nazwie "Models". Kiedy zmieniłem połączenie w mojej sieci.Config from this:

<add name="RecipeManagerEntities" connectionString="metadata=res://*/Model.Recipe.csdl 

Do tego:

<add name="RecipeManagerEntities" connectionString="metadata=res://*/Models.Recipe.csdl

Wszystko działało (zmieniono Model na Models). Zauważ, że musiałem zmienić te trzy miejsca w tym łańcuchu.

Oraz szybki sposób sprawdzenia nazwy modelu bez odbłyśnika.... poszukaj katalogu

...obj / {Config output} / edmxResourcesToEmbed

I sprawdź, czycsdl,msl, oraz .pliki zasobów ssdl są tam. Jeśli znajdują się w podkatalogu, nazwa podkatalogu musi być poprzedzona nazwą modelu.

Na przykład, moje trzy pliki zasobów znajdują się w podkatalogu Data, więc mój łańcuch połączeń musiał być

Metadane = res://*/Data .MyModel.csdl|res://*/Data .MyModel.ssdl / res://*/Data .MyModel.msl;

(versus metadata = res: / / * / MyModel.csdl / res:/ / * / MyModel.ssdl|res:/ / * / MyModel.msl;)

Miałem również ten problem i to dlatego, że connectionstring w mojej sieci.config był nieco inny niż ten w aplikacji.konfiguracja zestawu, w którym znajduje się mój EDMX. Nie wiem, dlaczego to się zmieniło, ale oto dwie różne wersje.

App.config:

<add name="SCMSEntities" connectionString="metadata=res://*/Model.SMCSModel.csdl|res://*/Model.SMCSModel.ssdl|res://*/Model.SMCSModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=SANDIEGO\sql2008;initial catalog=SCMS;integrated security=True;multipleactiveresultsets=True;application name=EntityFramework&quot;" providerName="System.Data.EntityClient" />

Www.config:

<add name="SCMSEntities" connectionString="metadata=res://*/Model.SCMSModel.csdl|res://*/Model.SCMSModel.ssdl|res://*/Model.SCMSModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=SANDIEGO\sql2008;initial catalog=SCMS;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework&quot;" providerName="System.Data.EntityClient" />

Naprawiono to po prostu kopiowanie aplikacji.Config string (zwróć uwagę na małą różnicę na końcu-zamiast" App=EntityFramework "chciał" application name=EntityFramework") do sieci.config i problem został rozwiązany. :)

Zdarzyło mi się to, gdy przypadkowo zamieniłem akcję budowania pliku edmx (pojawia się pod właściwościami w IDE) z 'EntityDeploy' na 'None'. EntityDeploy jest tym, co wypełnia metadane dla Ciebie: zobacz http://msdn.microsoft.com/en-us/library/cc982037.aspx

Spędziłem z tym szczęśliwe 30 minut. Zmieniłem nazwę obiektu encje, zmieniłem nazwę wpisu w pliku konfiguracyjnym, ale jest coś więcej ... musisz również zmienić odniesienie do csdl

Bardzo łatwo przegapić - jeśli zmieniasz nazwę, upewnij się, że otrzymasz Wszystko ....

Udało mi się to rozwiązać w Visual Studio 2010, VB.net (ASP.NET) 4.0.

Podczas kreatora modelu encji będzie można zobaczyć ciąg połączenia encji. Stamtąd można skopiować i wkleić do łańcucha połączenia.

Jedyne czego mi brakowało to " App_Code."w łańcuchu połączeń.

entityBuilder.Metadata = "res://*/App_Code.Model.csdl|res://*/App_Code.Model.ssdl|res://*/App_Code.Model.msl"

Miałem ten sam problem. Zajrzałem do mojego dll z reflector i widziałem, że nazwa zasobu nie była w porządku. Zmieniłem nazwę i teraz wygląda dobrze.

W moim przypadku jest to rozwiązane poprzez zmianę właściwości pliku edmx.

1. Otwórz plik edmx
2. Kliknij prawym przyciskiem myszy na dowolnym miejscu projektanta EDMX
3. wybierz Właściwości
4. zaktualizuj właściwość o nazwie "przetwarzanie artefaktów metadanych "do"Embed in Output Assembly"

To rozwiązało problem dla mnie. Problem polega na tym, że gdy kontener próbuje znaleźć metadane, nie może go znaleźć. więc po prostu zrób to w tym samym zespole. To rozwiązanie nie zadziała, jeśli masz Twoje pliki edmx w innym zbiorze

Spędziłem cały dzień na tym błędzie

Jeśli pracujesz z n-tear architecture

Lub próbowałeś separate Models wygenerować przez EDMX formularz DataAccessLayer do DomainModelLayer

Może dostaniesz ten błąd

1. pierwszym krokiem jest upewnienie się, że łańcuch połączeń w webconfig (UILayer) i appconfig (DataAccessLayer) są takie same

2. Druga, która jest bardzo ważna connection string

   connectionString="metadata=res://*/Model.csdl|res://*/Model.ssdl|res://*/Model.msl;provid.....
   

   Czyli problem

Skąd ja mam Albo cokolwiek .csdl in my connection string where are they

Oto nasze rozwiązanie spójrz na zdjęcie

Hope the help you

ostatecznym rozwiązaniem (nawet po odtworzeniu bazy danych na dwóch innych maszynach, a także EDMX i innych innych) było nieużywanie pierwszej edycji Entity Framework. Czekamy na ponowną ocenę w. NET 4.0.

Po napotkaniu tego samego problemu Ponownie i szukaniu wszędzie odpowiedzi, w końcu znalazłem kogoś, kto miał ten sam problem. Wygląda na to, że ciąg połączenia nie został poprawnie wygenerowany przez kreatora Visual Studio, a link do zasobów metadanych brakowało ważnej ścieżki.

Błąd V1. 0?: Nie można załadować określonego zasobu metadanych. Scenariusze != Modele

Aktualizacja 2013-01-16: po przejściu na prawie wyłącznie Korzystanie z kodu EF pierwsze praktyki (nawet z istniejących baz danych) ten problem nie jest już problemem. Dla mnie było to realne rozwiązanie do zmniejszenia bałaganu z automatycznie generowanego kodu i konfiguracji oraz zwiększenia mojej własnej kontroli nad produktem.

Mój problem i rozwiązanie, objawy były takie same "nie można załadować określonego zasobu metadanych", ale przyczyna była inna. Miałem 2 projekty w rozwiązaniu jeden był EntityModel, a drugi rozwiązanie. Faktycznie usunąłem i odtworzyłem plik EDMX w modelu EntityModel.

Rozwiązanie polegało na tym, że musiałem wrócić do projektu aplikacji webowej i dodać tę linię do pliku konfiguracyjnego. Nowy model zmienił kilka elementów, które musiały być powielone w " innych" www projektu.Plik konfiguracyjny. Stara konfiguracja nie była już dobra.

     <add name="MyEntities"
     connectionString="metadata=res://*/Model1.csdl|res://*/Model1.ssdl|res://*/Model1.msl;
                    provider=System.Data.SqlClient;
                    provider connection string=&quot;
                    data source=Q\DEV15;initial catalog=whatever;
                    user id=myuserid;password=mypassword;
                    multipleactiveresultsets=True;
                    application name=EntityFramework&quot;"
     providerName="System.Data.EntityClient" />

Po godzinach googlowania i próbach rozwiązania żadne z proponowanych rozwiązań nie zadziałało. Wymieniłem tutaj kilka rozwiązań. Zauważyłem również ten, który pracował dla mnie. (Używałem EF w wersji 6.1.1 i SQL server 2014-ale starszy DB)

1. przebudować projekt i spróbować ponownie.
2. Zamknij i otwórz VS-Nie wiem jak to działa
3. Upewnij się, czy umieściłeś .Plik EDMX wewnątrz katalogu, upewnij się, że zawierają katalogi w ConnectionString. na przykład mój znajduje się w folderze DAL. Wygląda więc tak: connectionString="metadata=res://*/DAL.nameModel.csdl|res://*/DAL.nameModel.ssdl|res://*/DAL.nameModel.msl; (są to pliki. aby je zobaczyć, możesz przełączyć Pokaż wszystkie pliki w solution explorer, pod ~ / obj/.. katalog)

...i wiele innych, które próbowałem [jak: przywrócenie wersji EntityFramework do późniejszej wersji (nie jestem tego pewien)]

Co mi się udało:

Z tego artykułu tutaj, pomógł mi rozwiązać mój problem. Właśnie zmieniłem moje ProviderManifestToken="2012" na ProviderManifestToken="2008" w pliku EDMX. Do zrobienia to:

Solution Explorer

1. Kliknij prawym przyciskiem myszy plik .edmx
2. Otwórz..
3. edytor XML
4. Change ProviderManifestToken = "XXXX" with 2008

W moim przypadku problem ten związany był ze zmianą nazwy pliku edmx mojego modelu... poprawianie aplikacji.config connection string dla plików csdl / ssdl / msl Naprawiono mój problem.

Jeśli używasz EF 4.0 designer do generowania csdl / ssdl / msl, te 3 "pliki" będą faktycznie przechowywane w głównym pliku edmx modelu. W tym przypadku post Przez Waqas jest prawie na miejscu. Ważne jest, aby zrozumieć, że "Model_Name" w jego przykładzie będzie musiał zostać zmieniony na dowolną obecną nazwę Twojej modelki .plik edmx (bezedmx).

Ponadto, jeśli Twój plik edmx nie znajduje się na poziomie głównym projektu, musisz wprowadzić nazwę modelu ze ścieżką względną, np.

res://*/MyModel.WidgetModel.csdl|res://*/MyModel.WidgetModel.ssdl|res://*/MyModel.WidgetModel.msl

Określa, że csdl / ssdl / msl XML jest przechowywany w pliku modelu ' WidgetModel.edmx", który jest przechowywany w folderze o nazwie "MyModel".

Napisałem tę klasę pomocniczą, aby tworzyć instancje obiektów ObjectContext, gdy są one zdefiniowane w innym projekcie niż projekt z niego korzystający. Analizuję łańcuch połączeń w pliku konfiguracyjnym i zastępuję ' * ' pełną nazwą zestawu.

Nie jest doskonały, ponieważ wykorzystuje odbicie do zbudowania obiektu, ale jest to najbardziej ogólny sposób zrobienia tego, jaki mogłem znaleźć.

public static class EntityHelper<T> where T : ObjectContext
{
    public static T CreateInstance()
    {
        // get the connection string from config file
        string connectionString = ConfigurationManager.ConnectionStrings[typeof(T).Name].ConnectionString;

        // parse the connection string
        var csBuilder = new EntityConnectionStringBuilder(connectionString);

        // replace * by the full name of the containing assembly
        csBuilder.Metadata = csBuilder.Metadata.Replace(
            "res://*/",
            string.Format("res://{0}/", typeof(T).Assembly.FullName));

        // return the object
        return Activator.CreateInstance(typeof(T), csBuilder.ToString()) as T;
    }
}

Dla wszystkich SelftrackingEntities użytkowników , jeśli zastosowałeś Microsoft Walk-through i oddzieliłeś klasę kontekstu obiektu na projekt usługi wcf (poprzez linkowanie do context. tt) więc ta odpowiedź jest dla ciebie:

Część pokazanych odpowiedzi w tym poście, która zawiera kod jak:

... = string.Format("res://{0}/YourEdmxFileName.csdl|res://{0}/YourEdmxFileName.ssdl|res://{0}/YourEdmxFileName.msl", 
        typeof(YourObjectContextType).Assembly.FullName); 

NIE BĘDZIE DZIAŁAĆ DLA CIEBIE !! powodem jest to, że YourObjectContextType.Assembly obecnie znajduje się w innym asemblerze (wewnątrz asemblera projektu wcf),

Więc należy zastąpić YourObjectContextType.Assembly.FullName przez -->

ClassTypeThatResidesInEdmProject.Assembly.FullName 

Miałem problemy z tym samym komunikatem o błędzie. Mój problem został rozwiązany poprzez zamknięcie i ponowne otwarcie Visual Studio 2010.

Miałem ten sam problem, ponieważ zmieniłem nazwę zespołu.

Musiałem również zmienić jego nazwę w Assemblytle i Assemblykod atrybutów w properties projektu / AssemblyInfo.cs, a także usunięcie i ponowne dodanie odwołania do pliku edmx.

Wtedy to działało dobrze.

Mając ten sam problem ponownie utworzyłem edmx z bazy danych. Rozwiązuje mój problem.

Wyjątek jest spowodowany tym, że kompilator wskazuje na nieistniejące metadane, więc po prostu skopiuj app.config connectionstring do Web.config ConnectionString

Zdarza mi się to, gdy nie czyszczę roztworu przed zbudowaniem nowego .projektant edmx. Więc nie zapomnij wyczyścić roztworu przed zbudowaniem nowego .projektant edmx. To pomaga mi ominąć więcej problemów z tym. Poniżej podane dane nawigacyjne okrywają, że jesteś nowy w visual studio.

Click - > Build - >Clean Solution

Następnie Kliknij->Build- > Rebuild Solution

Mam nadzieję, że to pomoże. Dzięki wszystkim

Miałem również ten sam problem i rozwiązanie jak na Ricka, z tym, że importowałem istniejący .edmx do nowego projektu i chociaż podstawowa przestrzeń nazw nie miała znaczenia, został zaimportowany do innego podkatalogu, więc musiałem również zaktualizować ciąg połączenia wewnątrz Web.Config w trzech miejscach, aby uwzględnić nazwy różnych podkatalogów:

Miałem ten sam problem z rozwiązaniem, które zawierało projekty w folderze rozwiązania, kiedy zostały przeniesione do katalogu głównego rozwiązania(w celu przezwyciężenia podejrzewanego błędu z Mvc3AppConverter ze względu na lokalizacje projektów).

Chociaż rozwiązanie skompilowane po ponownym dodaniu wszystkich odniesień do projektu* w razie potrzeby, błąd został wyrzucony podczas uruchamiania Strony internetowej.

EDMX jest w jednym z projektów, które zostały przeniesione( projekt "DANE"), ale oczywiście brak odniesienia do projektu Danych nie spowodował błędu kompilacji, tylko błąd w czasie wykonywania.

Po prostu dodanie brakującego odniesienia do głównego projektu rozwiązało ten problem, nie trzeba w ogóle edytować połączenia.

Mam nadzieję, że to pomoże komuś innemu.

Słaba aplikacja.config lub web.plik konfiguracyjny może to zrobić.. Skopiowałem aplikację.Config connection string to my web.config w moim UI i skończyło się wpisaniem:

<connectionStrings>
    <connectionStrings>
          <add name="name" connectionString="normalDetails"/>
    </connectionStrings>
</connectionStrings>

Po prostu nie odwołałem się do mojej biblioteki klasowej, która zawierała plik EDMX.

Jeśli używasz edmx z innego projektu, to w łańcuchu połączeń Zmień...

metadata=res://*/Data.DataModel.csdl

...do ...

metadata=res://*/DataModel.csdl

Moja teoria jest taka, że jeśli masz więcej niż jeden plik edmx o tej samej nazwie (na przykład Model1), da to ten wyjątek. Mam ten sam problem, gdy postanowiłem nazwać wszystkie moje pliki edmx (siedząc w różnych projektach) Model1, ponieważ uznałem, że powinny być niezależne.

Inną przyczyną tego wyjątku jest umieszczenie powiązanej tabeli w zapytaniu obiektowym, ale wpisanie błędnej nazwy właściwości nawigacji.

Przykład:

var query = (from x in myDbObjectContext.Table1.Include("FKTableSpelledWrong") select x);