Mam obiekt struktury jednej encji i kiedy dodaję go do mojego projektu, connectionstring
jest dodawany do app.config
w connectionstring
sekcji, ale kiedy chcę utworzyć nowy entitycontext
i użyć tego connectionstring
, pojawia się ten błąd
Mam obiekt struktury jednej encji i kiedy dodaję go do mojego projektu, connectionstring
jest dodawany do app.config
w connectionstring
sekcji, ale kiedy chcę utworzyć nowy entitycontext
i użyć tego connectionstring
, pojawia się ten błąd
Odpowiedzi:
Podejrzewam, że twój problem wynika z faktu, że masz więcej niż jeden projekt w swoim rozwiązaniu, a ten, który zawiera elementy struktury jednostki, w tym edmx
pliki, NIE jest projektem startowym rozwiązania. W tym przypadku, nawet jeśli parametry połączenia istnieją w app.config
projekcie EF , środowisko CLR nadal nie może go znaleźć w czasie wykonywania. Na przykład jeśli masz witrynę sieci Web i projekt EF w swoim rozwiązaniu, musisz skopiować parametry połączenia z projektu EF app.config
do witryny sieci Web web.config
. Zasadniczo wszelkie dane parametrów połączenia powinny istnieć w pliku konfiguracyjnym projektu, z którego wątki .Net są inicjowane przez CLR (czyli projekt startowy). Jeśli to nie jest Twoja sprawa, po prostu otwórz plikedmx
plik, kliknij prawym przyciskiem myszy jego powierzchnię, wybierz właściwości i skopiuj parametry połączenia i wklej je do app.config
sekcji Parametry połączenia. W ten sposób możesz upewnić się, że masz poprawną konfigurację.
EDYCJA:
Jak widać tutaj w
Documenation on ObjectContext Constructor , pierwszym parametrem jest nazwa łańcucha połączenia, która jest kodem generowanym w czasie tworzenia EDM. Jeśli w jakiś sposób nazwa twojego łańcucha połączenia zostanie zmieniona, wszystko, co musisz zrobić, to kliknąć prawym przyciskiem myszy model i wybrać "Aktualizuj model z bazy danych ...", a następnie postępuj zgodnie z instrukcjami kreatora, aby zaktualizować konfigurację i projektanta, aby to odzwierciedlić zmiana.
Musisz skopiować parametry połączenia z pliku app.config do pliku web.config lub skopiować cały plik do projektu, który wyświetla dane wyjściowe. Jest to jeden z warunków korzystania z ramy.
Napotkałem ten problem, gdy próbowałem umieścić moją niestandardową logikę bazy danych w pliku .dll, który ma być używany przez wiele projektów w moim rozwiązaniu.
Chociaż .dll miał poprawny plik app.config, to nie działało. Struktury jednostek potrzebowały informacji o połączeniu w pliku app.config pliku .exe. Kopiowanie tam informacji działało dobrze.
Rozwiązanie Morteza polegające na wklejeniu parametrów połączenia bezpośrednio do .edmx nie zadziałało, ponieważ nie pozwoliłoby mi wkleić tam wartości - chociaż właśnie to chciałem móc zrobić.
Cześć, miałem ten problem i doprowadzało mnie to do szału. Zresztą w końcu zorientowałem się, na czym polega problem. Pierwszą rzeczą, którą musisz zrobić, jest upewnienie się, że connectionstrings
in app.config
i web.config
są takie same. Następnie musisz dwukrotnie kliknąć .edmx
plik, aby zobaczyć tabele. Po kliknięciu w dowolnym miejscu w pobliżu tabel, ale nie w tabelach, przejdź do właściwości. Z listy rozwijanej wybierz ConceptualEntityModel
i wyszukaj nazwę kontenera jednostki i dobrze ją zapamiętaj.
Następnie przejdź do projektanta pliku edmx i otwórz konstruktory. (projektant jest podfolderem pliku edmx) konstruktorzy powinni mieć dwa parametry w parametrze BASE
public DBEntities() : base("name=DBEntities", "DBEntities")
{
this.ContextOptions.LazyLoadingEnabled = true;
OnContextCreated();
}
to jest jeden z nich. pierwszy parametr powinien mieć nazwę pliku projektu, w którym .edmx
plik się znajduje. Drugi parametr musi mieć nazwę kontenera encji z właściwości, o których wspomniałem wcześniej. nie zapomnij ułożyć wszystkich konstruktorów za pomocą:base("", "")
To był przynajmniej mój problem i mój problem został rozwiązany w ten sposób. Mam nadzieję, że uda ci się rozwiązać twoje w ten sposób.
Miałem wariację na ten temat, której nikt nie zdawał się uwzględniać.
Miałem główny projekt z kilkoma modelami i projekt testowy zawierający testy jednostkowe. Projekt testowy działał, ale następnie zatrzymał się z błędem wymienionym w PO. Nie wykonałem żadnej zmiany nazwy ani przeniesienia pliku EDMX.
Wiele porad wspomniało o porównywaniu plików .config, ale mój projekt nie miał żadnego.
W końcu skopiowałem plik app.config z głównego projektu do mojego projektu testowego i wtedy zadziałało. Nie wiem, czy jest to właściwy krok, czy też wystąpią problemy z utrzymywalnością po dodaniu dodatkowych modeli, nie wiem, ale przynajmniej moje testy jednostkowe działają teraz poprawnie.
Chociaż odpowiedź Morteza Manavi rozwiązuje ten problem, innym rozwiązaniem jest dynamiczne zbudowanie parametrów połączenia i przekazanie ich do konstruktora obiektu ObjectContext:
public static string CreateConnectionString()
{
var assemblyPath = Assembly.GetExecutingAssembly().Location;
string assemblyLocation = Path.GetDirectoryName(assemblyPath);
string dbPath = Path.Combine(assemblyLocation, "YourDatabase.sdf");
var sqlBuilder = new SqlConnectionStringBuilder { DataSource = dbPath };
var entityBuilder = new EntityConnectionStringBuilder
{
ProviderConnectionString = sqlBuilder.ConnectionString,
Provider = "System.Data.SqlServerCe.3.5",
Metadata = @"res://*/YourModel.csdl|
res://*/YourModel.ssdl|
res://*/YourModel.msl"
};
return entityBuilder.ToString();
}
// Snip...
var entityContext = new YourObjectContext(CreateConnectionString());
Eliminuje to potrzebę kopiowania informacji o parametrach połączenia do pliku app.config projektu startowego, co przynajmniej w moim przypadku nie było pożądane.
Zapomniałem dodać providerName = "System.Data.EntityClient" jako atrybut w ciągu połączenia. Spowodowało to ten błąd tak
<add name="connectionName" connectionString="metadata=res://*/..." providerName="System.Data.EntityClient" />
zamiast
<add name="connectionName" connectionString="metadata=res://*/..." />
Właśnie odkryłem, że jeśli aplikacja jest tworzona w usługach IIS z VS2010 dwa poziomy z katalogu głównego witryny, wystąpi ten błąd. Nie jestem pewien, dlaczego tak się dzieje, musiałbym zbadać więcej. Na przykład, jeśli Twoja aplikacja znajduje się w tej ścieżce: /admin/advertiser
błąd pojawi się, jeśli nie masz /admin
katalogu wirtualnego w witrynie usług IIS.
Wszystko, co zrobiłem, to utworzony pusty admin
katalog w moim .../intepub/wwwroot
błędzie zniknął.
Przekonasz się, że nie będziesz w stanie rozpocząć debugowania, dopóki nie wykonasz powyższego kroku.
Mieliśmy ten problem w naszym zespole w przeszłości, zajęło nam to trochę czasu, aby pamiętać, ale dokładnie tak to naprawiliśmy wcześniej.
Używam innej architektury i mam ten sam problem, ale ten mi pomoże. Mam nadzieję, że to ci pomoże. Najpierw masz to samo, connection string
w libraries
którym możesz uzyskać dostęp do bazy danych jak w, app.config
a następnie web.config
po prostu dodajesz przeciążony konstruktor w pliku .edmx (Model.context.cs), który teraz masz dwa konstruktory, jeden jest domyślny, a drugi właśnie dodany ( przeciążony).
public YourEntityName(string connString)
: base(connString)
{
}
Miałem bibliotekę klas, która również nie chciała współpracować z EF. Po skopiowaniu pliku app.config (lub tylko sekcji connectionstring) z mojej biblioteki klas do projektu exe połączenie działało dobrze! Prawdopodobnie plik konfiguracyjny powinien znajdować się w tym samym folderze co projekt exe i dlatego nie został znaleziony. Dlatego zawsze zachowaj szczególną ostrożność, gdy plik konfiguracyjny jest używany w projekcie biblioteki klas!
Cóż ... ten problem mógł być również z bardzo prostego (głupiego) powodu ... Skopiowałem plik z innego projektu i zapomniałem zmienić ConnectionString w EntityDataSource ... tak jak byłem na początku projektu i się stało na stronie logowania myślałem, że to coś w konfiguracji, ale była to tylko niewłaściwa nazwa ciągu połączenia (i DefaultContainerName).