UWP und ADO.NET is back

Bereits seit Silverlight ist der direkte Zugriff auf Datenbanken nicht mehr möglich. Die mehrschichtige Architektur mit einem Service Layer findet sich naturgemäß in Web Frameworks, aber eben auch in WinRT bis hin zu UWP. Ich gehe mal davon aus, das irgendwer bei Microsoft in die Runde gefragt hat, “warum WPF?” und dann kam die Antwort, “Weil wir ADO.NET lieben”.

Man glaubt es kaum. SQLClient und auch Entityframework sind zurück. Mit UWP (Universal Windows Platform) gibt es nun wieder direkten Zugriff auf einen SQL Server. Gerne auch 2 Schicht Architektur genannt. In den diversen Feeds wird schon wieder abgewettert, ob der furchtbaren Software, die da entstehen wird. Nehmen wir es mal gelassen, manchmal muss es schnell gehen und oft sitzen die Clients auch nahe und im gleichen Subnetz eines SQL Servers.

Das ganze ist reichlich vorab und mir erst seit 8.August 2017 überhaupt erfolgreich gelungen. Aus den Issues auf Github kann man rauslesen, das es reichlich Veränderung (breaking changes) gibt.

bei mir läuft (ohne Gewähr)

  • Windows 10 Insider Build 16257.1
  • Visual Studio 2017 15.3 Preview 7
  • SQL Server 2016 Developer Edition

Dazu Anmerkungen: das TCP/IP Netzwerkprotokoll in den SQL Server Configuration Manager aktivieren und den Dienst neu starten. Von Remote PC per Telnet auf die IP Port 1433 prüfen. Eventuell muss in der Windows Firewall die APP aktiviert werden.

Jedenfalls läuft folgender Code in einer WPF Anwendung ohne Probleme und in einer UWP ohne vorige Änderungen nur in eine Exception in der Art

System.Data.SqlClient.SqlException occurred
HResult=0x80131904
Message=A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 35 - An internal exception was caught)

   1:  var conn = new SqlConnection("Data Source=WIN10-PRE;
Initial Catalog=NORTHWND;Integrated Security=True"
);
   2:  conn.Open();
   3:  var cmd = new SqlCommand("Select * from Customers",conn);
   4:  using (var reader = cmd.ExecuteReader())
   5:         {
   6:                  while (reader.Read())
   7:                  {
   8:   
   9:   
  10:                  }
  11:   
  12:          }

Ich habe dann den Connection String auf User Id und Password umgestellt. Entspricht auch mehr dem reellen Szenario.

UWP Anwendungen werden in Zukunft (als jetzt als preview) auf dotnetcore zugreifen (integrieren?) können. Dazu muss allerdings auch das Windows 10 preview SDK gesondert installiert sein.

https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewSDK

Dafür muss man natürlich Mitglied im Windows Insider Programm sein, was nur ein paar Klicks kostet.

Dann legt man ein ganz normales Windows Universal C# Projekt an und wählt als Zielversion und Min Version 16257. Das sollte man auch später noch ändern können über die Projekteigenschaften. Das entspricht dem Creators Update Fall Edition (oder wie das heißen wird).

In dem so erzeugten UWP Projekt taucht ein neuer Verweis auf Microsoft.NETCore.UniversalWindowsPlatform vermutlich in einer 5.x Version. Um nun auf die neuesten und täglichen Bits zu bekommen, habe ich in Visual Studio einen weiteren Nuget Server eingerichtet, der auf die Url ttps://dotnet.myget.org/F/dotnet-core/api/v3/index.json verweist.

image

Wählt man im Paketmanager diesen aus, zeigt Visual Studio ein verfügbares Update auf eine 6.x Version (Preview 2 25609). Führen Sie das Update durch, Nur Mut jetzt ist es auch schon egal.

image

Hinter diesem Verweis stecken per Alias eine Reihe von Libraries - .NET Assemblies wie System.Threading und eben SqlClient als .NET Standard 2.0 Variante und können dann direkt im C# Referenziert werden ohne zusätzliche Pakete per Nuget zu holen.

Referenziert ist dieses Paket seit kurzer Zeit wieder im .csproj File  ala

   1:   <PackageReference Include="Microsoft.NETCore.UniversalWindowsPlatform">
   2:        <Version>6.0.0-preview2-25609-02</Version>
   3:      </PackageReference>

 

Was habe ich gelernt. SQLExpress Local DB ist nicht möglich, weil diese Treiber auf die Registry zugreifen und das in .NET Standard für die Librarys nicht definiert ist und auch nicht sein wird weil Windows Plattform spezifisch. Weiters gibt es eine .NET Standard 1.6 Variante, die ziemlich anders ist. Die Portable Class Librarys (PCL) machen in Zukunft keinen Sinn mehr und sind als abgekündigt angekündigt Zwinkerndes Smiley.
Update: SqlClient macht im klassischen .NET einen Fallback von TCP/IP auf Named Pipes und Shared Memory. .NET Core tut das nicht. Das Attribut “Network Library” wird im Connection String von Core nicht unterstützt. Statt dessen kann man das Protokoll als Prefix mitgeben, z.B. lcp: (local) um per Shared Memory auf den lokalen SQL Server zuzugreifen. Wird im Testszenario mit einer T%CP Provider Error 35 Exception quittiert. Ich geh davon aus, es ist nicht implementiert und es könnte auch sein, das UWP Apps das grundsätzlich nicht können.

Feedback oder Fragen einfach über das Github Projekt https://github.com/hannespreishuber/ado.netsharp3

adcteaser360x90

Kommentare sind geschlossen