Nie można uzyskać dostępu do SQL Azure DB ze strony Azure, nawet jeśli ten sam ciąg połączenia działa z lokalnej witryny internetowej

Question

Niedawno skonfigurowałem moją pierwszą witrynę na platformie Azure. Na razie jest to po prostu standardowa strona szablonu MVC4 ze sterownikami Home i Account. Na platformie Azure mam jedną witrynę internetową i jedną bazę danych SQL. Mogę uzyskać dostęp do bazy danych SQL Azure z SSMS i skonfigurować login i użytkownika do wykorzystania przez moją stronę.

W moim środowisku programistycznym, wskazując na moją bazę danych, mogę uzyskać dostęp do strony/Konto/Logowanie. Mogę się zarejestrować i widzę nowego użytkownika w mojej lokalnej bazie danych. Mogę również zmienić ciąg połączenia, by wskazać moją stronę programistyczną w bazie danych SQL Azure DB, i znowu mogę uzyskać dostęp do/konta/logowania i zarejestrować nowych użytkowników. Mogę wtedy zobaczyć tych nowych użytkowników w SQL Azure DB.

Problemy pojawiają się, gdy wdrażam witrynę na platformie Azure. Mam konfigurację transformacji powiązaną z moim plikiem ustawień publikowania i widzę w oknie wyjściowym podczas publikowania witryny na platformie Azure, że ta transformacja jest stosowana podczas wdrażania. Spowoduje to zmianę lokalnego ciągu połączenia DB rozwoju z łańcuchem połączenia SQL Azure. Zweryfikowałem również, że ten ciąg połączenia SQL Azure znajduje się w faktycznym wdrożonym pliku web.config (przy użyciu FileZilla FTP w celu pobrania wdrożonego pliku web.config). Mogę wejść na stronę domową na mojej stronie [mojawitryna] .AzureWebsites.net, ale po kliknięciu na link, aby przejść do logowania na stronie/konta/logowania, pojawia się następujący błąd:

[ArgumentException: Format of the initialization string does not conform to specification starting at index 0.] 
System.Data.Common.DbConnectionOptions.GetKeyValuePair(String connectionString, Int32 currentPosition, StringBuilder buffer, Boolean useOdbcRules, String& keyname, String& keyvalue) +5313265 
System.Data.Common.DbConnectionOptions.ParseInternal(Hashtable parsetable, String connectionString, Boolean buildChain, Hashtable synonyms, Boolean firstKey) +124 
System.Data.Common.DbConnectionOptions..ctor(String connectionString, Hashtable synonyms, Boolean useOdbcRules) +95 
System.Data.SqlClient.SqlConnectionString..ctor(String connectionString) +59 
System.Data.SqlClient.SqlConnectionFactory.CreateConnectionOptions(String connectionString, DbConnectionOptions previous) +24 
System.Data.ProviderBase.DbConnectionFactory.GetConnectionPoolGroup(DbConnectionPoolKey key, DbConnectionPoolGroupOptions poolOptions, DbConnectionOptions& userConnectionOptions) +167 
System.Data.SqlClient.SqlConnection.ConnectionString_Set(DbConnectionPoolKey key) +61 
System.Data.SqlClient.SqlConnection.set_ConnectionString(String value) +66 

System.Data.Entity.Internal.LazyInternalConnection.InitializeFromConnectionStringSetting(ConnectionStringSettings appConfigConnection) +122 
System.Data.Entity.Internal.LazyInternalConnection.TryInitializeFromAppConfig(String name, AppConfig config) +32 
System.Data.Entity.Internal.LazyInternalConnection.Initialize() +127 
System.Data.Entity.Internal.LazyInternalConnection.get_ProviderName() +13 
System.Data.Entity.Internal.LazyInternalContext.InitializeContext() +346 
System.Data.Entity.Internal.InternalContext.CreateObjectContextForDdlOps() +17 
System.Data.Entity.Database.Exists() +36 
[MyWebsite].Filters.SimpleMembershipInitializer..ctor() +105 

Wydaje się to zasugerować, że istnieje problem z moim ciągiem połączenia, ale jak wspomniałem wcześniej, ten sam ciąg połączenia działa z mojej lokalnej strony internetowej.

Rozważałem, że problem może być związany z zaporą ogniową, ale sprawdziłem ustawienia w portalu zarządzania Azure i zastosowano regułę zapory sieciowej Windows Azure Services, aby umożliwić ten dostęp. Próbowałem też usunąć regułę zapory sieciowej dla mojego komputera lokalnego, aby uzyskać dostęp do SQL Azure DB, aby zobaczyć, czy otrzymam podobny wyjątek, ale zgłoszony wyjątek był w oczywisty sposób związany z zaporą ogniową.

Próbowałem również dodać ciąg połączenia SQL Azure za pośrednictwem portalu Azure Management (choć nie widziałem sposobu określania dostawcy) - nie trzeba dodawać, mam ten sam "Format inicjowania ... "wyjątek wymieniony powyżej.

Moje ciąg połączenia w pliku web.config jest w następującym formacie:

<add name="[my connection name]" 
    connectionString="Server=tcp:abc123.database.windows.net,1433;Database=[my database];User ID=[my login]@abc123;Password=[my password];Trusted_Connection=False;Encrypt=True;Connection Timeout=30;" 
    providerName="System.Data.SqlClient" /> 

Wszelkie sugestie będą bardzo mile widziane.

Answer 1

W KOŃCU dotarłem do sedna. Do tej pory nie zdawałem sobie sprawy, że w web.config ostatecznie znajdują się 2 ciągi połączeń, które ostatecznie zostaną wdrożone w witrynie Windows Azure - mój własny niestandardowy, ale także inny ciąg połączenia DefaultConnection, który ma format:

<add name="DefaultConnection" connectionString="DefaultConnection_ConnectionString" providerName="System.Data.SqlClient" /> 

• oczywiście, nie jest to poprawny ciąg połączenia (i stąd wyjątek formatu powyżej). Możesz to zobaczyć, pobierając rzeczywisty plik web.config ze swojej witryny Azure za pomocą FTP.

Ten domyślny ciąg połączenia nie znajduje się w żadnym miejscu w pliku web.configs lub różnych przekształceniach w moim rozwiązaniu. Patrząc na okno wyjściowe podczas publikowania, istnieje wiele transformacji, które zostaną zastosowane do pliku web.config. Przejrzałem różne wersje plików generowanych podczas cyklu budowania/publikowania i żaden z nich nie zawierał w nich ciągu połączenia DefaultConnection, nawet w folderze obj \ Release \ Package \ PackageTmp \. Zgaduję, że coś w fazie Web Deploy wstawia ją jako ostatnią modyfikację pliku web.config. W pliku settingssettings znajduje się element MSDeployParameterValue, który wspomina o ciągach połączeń i pliku web.config - chyba to możliwe.

W pliku AccountModels.cs, odniesienie do niniejszego DefaultConnection:

public UsersContext() 
: base("DefaultConnection") 
{ 
} 

ten sposób konkretny ciąg połączenia jest wybierany. Zmiana tego parametru na niestandardową nazwę ciągu połączenia zapewnia, że ​​niestandardowa baza danych zostanie użyta dla różnych elementów konta i rozwiąże opisany powyżej wyjątek formatu.

Answer 2

Spróbuj usunąć "Encrypt = True;" lub spróbuj dodać "TrustServerCertificate = True;" - Przeczytaj SqlConnection.ConnectionString Property więcej szczegółów, ale w zasadzie:

Beginning in .NET Framework 4.5, when TrustServerCertificate is false (the default) and Encrypt is true, the server name (or IP address) in a SQL Server SSL certificate must exactly match the server name (or IP address) specified in the connection string.

Answer 3

o ciągi połączeń SQL Azure

• usługi SQL Azure Database jest dostępny tylko z portem TCP 1433. Należy upewnić się, że zapora zezwala na wychodzącą komunikację TCP na porcie TCP 1433.

• SQL Azure nie obsługuje uwierzytelniania systemu Windows. Zaufane połączenie będzie zawsze ustawione na False.

• SQL Azure nie obsługuje połączeń nieszyfrowanych. Musisz określić w ciągu połączenia, że ​​chcesz zaszyfrować połączenie.

• Połączenie z SQL Azure przy użyciu OLE DB nie jest oficjalnie obsługiwane.

Standardowy sposób

Server=tcp:[serverName].database.windows.net;Database=myDataBase; 
User ID=[LoginForDb]@[serverName];Password=myPassword;Trusted_Connection=False;Encrypt=True; 

Use 'username@servername' for the User ID parameter.

Aby uzyskać więcej informacji sprawdź to Connection strings for SQL Azure

Mam nadzieję, że przyczyni się to do ciebie.

Answer 4

Wiem, że to stary post, ale chciałem podzielić się swoimi odkryciami. W moim pliku .pubxml przechowywał mój ciąg połączenia localdb i nie aktualizował żadnych kompilacji ani publikacji. Musiałem ręcznie zaktualizować plik publikowania za pomocą moich ciągów połączenia z Azure DB, aby mógł on działać. Mam nadzieję, że to pomoże uratować komuś czas.