14

Mamy aplikację ASP .NET (MVC) i używamy architektury Entity Framework 6 do łączenia się z naszymi bazami danych. DbContext jest skonstruowany w standardowy sposób i ładuje ciąg połączenia w naszym imieniu. Wygenerowany kod wygląda następująco:Ustawienie łańcucha połączenia EF w aplikacji sieci Web Azure

public partial class MyContext : DbContext 
{ 
    public MyContext(string connectionName) 
     : base("name=" + connectionName) 
    { 
    } 
} 

Stawiamy ciąg połączenia w lokalnej web.config również w standardowy sposób:

<configuration> 
    <connectionStrings> 
    <add name="DefaultConnection" 
     connectionString="metadata=...;provider connection string=&quot;...&quot;" 
     providerName="System.Data.EntityClient" /> 

Kiedy opublikować aplikację do Azure możemy przejść do Azure Portal, następnie do Ustawień aplikacji sieci Web, a następnie do listy Ciągów połączeń. Tam dodajemy ciąg połączenia EF, który używaliśmy lokalnie. Po ponownym uruchomieniu i odwiedzeniu aplikacji otrzymujemy błąd wykonania w zależności od wybranego przez nas typu połączenia.

Dla Custom typu otrzymujemy następujący błąd czasu wykonywania:

Keyword not supported: 'data source'.

Dla SQL Server lub SQL Database otrzymujemy następujący błąd czasu wykonywania:

Keyword not supported: 'metadata'.

To naprawdę wydaje się to proste opowiadania, więc zastanawiamy się, co jest nie tak.

+0

Zajrzyj tutaj: http://azure.microsoft.com/blog/2013/07/17/windows-azure-web-sites-how-application-strings-and-connection-strings-work/ – Fals

Odpowiedz

17

Problem stanowią cytowane znaki zachęty: &quot;.

Ciągi połączeń w pliku web.config mają cytowane znaki, ponieważ są serializowane w atrybucie XML. Wprowadzając ciąg połączenia w portalu Azure, należy podać nieprzetworzony ciąg znaków. Coś takiego: odpowiedź

metadata=...;provider connection string="Data Source=..."

Davida Ebbo jest dobre dla potwierdzenia, że ​​środowisko jest skonfigurowane zgodnie z oczekiwaniami. Warto również zwrócić uwagę na plik .pubxml podczas publikowania za pośrednictwem kreatora w Visual Studio: spróbuje również wypełnić ciągi połączeń.

+0

Mam takie same problem i po wydatkowaniu al ong time searching Nie znalazłem rozwiązania. Usługa Azure po prostu ignoruje ustawienia aplikacji i używa ciągu połączenia z pliku web.config. Jak widzę w filmie [Channel 9] (https://channel9.msdn.com/Shows/Azure-Friday/Custom-configuration-and-application-settings-in-Azure-Web-Sites-with-Stefan-Schackow), byłoby to "magiczne", ale nie jest. –

9

"Zwyczaj" powinien być poprawny tutaj. W takim przypadku parametr providerName pozostanie niezmieniony, więc jeśli masz konfigurację System.Data.EntityClient, powinna ona pozostać po zmianie środowiska wykonawczego Azure.

Spróbuj przejść do Kudu Console i kliknij Środowisko, aby upewnić się, że ciąg połączenia wygląda tam prawidłowo.

1

Jeśli masz ten wiersz w web.connfig

<add name="Entities" connectionString="metadata=res://*/TestDB.csdl|res://*/TestDB.ssdl|res://*/TestDB.msl;provider=System.Data.SqlClient;provider connection string=&quot;Data Source=XXXXXXXX.database.windows.net,1433;Initial Catalog=YourDB;User ID=YourUser;Password=XXXXXX&quot;" providerName="System.Data.EntityClient" /> 

Dodaj ten w lazurowym portalu:

Name Column => Entities 

Value Column => metadata=res://*/TestDB.csdl|res://*/TestDB.ssdl|res://*/TestDB.msl;provider=System.Data.SqlClient;provider connection string="Data Source=XXXXXXXX.database.windows.net,1433;Initial Catalog=YourDB;User ID=YourUser;Password=XXXXXX" 

"Custom" - In the drop selection box 

Upewnij (jak wskazano w pierwszej odpowiedzi) aby zastąpić &quot; z "

Powiązane problemy