Laden...

[gelöst]TypeInitializationException SqlConnection auf Client in Published-Version

Erstellt von BruisE vor 11 Jahren Letzter Beitrag vor 11 Jahren 7.299 Views
B
BruisE Themenstarter:in
12 Beiträge seit 2013
vor 11 Jahren
[gelöst]TypeInitializationException SqlConnection auf Client in Published-Version

Hallo Zusammen

Ich habe eine Anwendung geschrieben, mit der ich Sicherungen von Live-DBs und Einspielungen auf die Testserver machen kann.

Die Anwendung funktioniert sorgenfrei, nur sobald ich die Anwendung mit "Publish.." freigebe und auf einem Client installiere, tritt folgende Fehlermeldung auf:

Fehlermeldung:
Der Typeninitialisierer für "System.Data.SqlClient.SqlConnection" hat eine Ausnahme verursacht.

Sobald ich nun aber mit dem Remote-Debugger auf die Anwendung auf dem Client zugreife und nach verfolgen will woran es nun genau liegt (step by step), tritt die Fehlermeldung nicht mehr auf.

Ich habe neben dem Main-Thread noch einen Thread für meinen Zeit-Counter (Vergangene Sekunden) als auch einen Thread für die Komplette SQL Abwicklung (es sind also keine Zugriffe von mehreren Thread auf den SQL-Server oder die Klasse möglich).

Entwicklungs-PC: Keine Fehlermeldung auch im "Publish" nicht.
Client: Publish -> Fehlermeldung
Client: Debug/bin/[Exe direkt ausführen] keine Fehlermeldung.
Client: im Remote-Debuger -> keine Fehlermeldung.

Hier noch die InnerException der Fehlermeldung (Source: System.Data):> Fehlermeldung:

System.TypeInitializationException: Der Typeninitialisierer für "System.Data.SqlClient.SqlConnectionFactory" hat eine Ausnahme verursacht. ---> System.TypeInitializationException: Der Typeninitialisierer für "System.Data.SqlClient.SqlPerformanceCounters" hat eine Ausnahme verursacht. ---> System.IO.FileLoadException: Die Datei oder Assembly "file:///C:\Dokumente und Einstellungen...\Apps\2.0\7OLPGZDG.VRO\KT3W12LG.OY7\nvkd..tion_fd5693245ada4cd6_0001.0000_d6fd7e47cd7a588b\Database Manager.exe" oder eine Abhängigkeit davon wurde nicht gefunden. Zugriff verweigert
bei System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
bei System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
bei System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection, Boolean suppressSecurityChecks)
bei System.Reflection.RuntimeAssembly.InternalLoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean suppressSecurityChecks, StackCrawlMark& stackMark)
bei System.Reflection.Assembly.LoadFrom(String assemblyFile)
bei System.Runtime.Hosting.ManifestRunner.get_EntryAssembly()
bei System.AppDomainManager.get_EntryAssembly()
bei System.Reflection.Assembly.GetEntryAssembly()
bei System.Data.ProviderBase.DbConnectionPoolCounters.GetAssemblyName()
bei System.Data.ProviderBase.DbConnectionPoolCounters.GetInstanceName()
bei System.Data.ProviderBase.DbConnectionPoolCounters..ctor(String categoryName, String categoryHelp)
bei System.Data.SqlClient.SqlPerformanceCounters..ctor()
bei System.Data.SqlClient.SqlPerformanceCounters..cctor()
--- Ende der internen Ausnahmestapelüberwachung ---
bei System.Data.SqlClient.SqlConnectionFactory..cctor()
--- Ende der internen Ausnahmestapelüberwachung ---
bei System.Data.SqlClient.SqlConnection..cctor()

Ich bin leider mit meinem Latein am Ende (oder auch einfach nur verzweifelt) und weiß nicht genau wo ich weiter suchen soll.

Ich hoffe auf die eine oder andere Anregung.

Vielen Dank im Voraus
Viele Grüße von einem weiteren neuen Mitglied

BruisE

Gelöschter Account
vor 11 Jahren

Es fehlt allem Anschein nach eine Abhängigkeit. Du kannst dem Problem ganz gut auf die Spur kommen wenn du das AssemblyResolve Event der AppDomain triggerst und mitlogst was er vermisst. (evt. .ressources kannst du dabei ignorieren)

B
BruisE Themenstarter:in
12 Beiträge seit 2013
vor 11 Jahren

Die Abhängigkeit müsste in dem Fall in meiner Tools-Klasse sein in der ich den SQLClient referenziere.

Ich werde mir das ganze am Montag so einrichten dass ich den AssemblyResolve_Event mit loge.

Was mir aber nicht in den Schädel geht, wieso klappt die Abhängigkeit wenn ich per Remote-Debugger auf den Client-Prozess sitze?

Vielen Dank schon mal für den Tipp!

Gelöschter Account
vor 11 Jahren

Ich habe leider keine Erfahrung mit Remote Debuggern bzw. du scheinst deine Anwendung irgendwie zu hosten(vermutlich IIS) auch da fehlt mir die Erfahrung aber ganz ungewöhnlich ist es nicht das in den 3 Szenarien unterschiedliche Bindungs- und Sicherheitsregeln gelten. Wie gesagt, nimm dir das AssemblyResolve Event und gib einfach null zurück und protokolliere den 2 Parameter.

B
BruisE Themenstarter:in
12 Beiträge seit 2013
vor 11 Jahren

kleines Zwischenfazit:
So wies aussieht liegt das Problem nicht beim Laden der Assembly, sondern viel mehr in dem/den Thread/s.

Durch das Abgreifen des AssemblyResolve Events kommt folgendes raus:

Haupt-Thread:

System.Configuration.resources
Microsoft.VisualStudio.Debugger.Runtime
mscorlib.resources

SQL-Thread:

mscorlib.resources

Mit dem Remotedebugger wird der Prozess aus dem Clientsystem abgegriffen und steuert Ihn dann vom VS aus, wie eine normale Debug-Session (Es müssen aber Debuginformationen wie Breakpoints auf dem Clientsystem vorhanden sein).

Sobald ich also eine Verzögerung durch den Debug-Prozess (step-by-step) verursache tritt der Fehler nicht mehr auf.

Interessant ist nur, dass die Exception auf dem Entwicklungs-PC noch nie aufgetreten ist.

Da ich mit Threads noch nicht viel zu tun hatte, werde ich mich wohl noch tiefer in das Thema einlesen müssen.

Für weitere Ideen bin ich weiterhin dankbar (evtl. liegt es ja doch nicht an den Threads 8o )

849 Beiträge seit 2006
vor 11 Jahren

Hallo,

also der Pfad oben in deinem Stacktrace sieht mir ganz nach clickOnce aus. ClickOnce hat ersteinmal so gut wie keine Rechte... Wozu auch

Database Manager.exe" oder eine Abhängigkeit davon wurde nicht gefunden. Zugriff verweigert passen würde.

Du müsstest Dir für deine Anwendung in den Einstellungen von ClickOnce erhöhte rechte holen, und diese beim Installieren bestätigen, ich denke dann wirds klappen 😃

Grüße

B
BruisE Themenstarter:in
12 Beiträge seit 2013
vor 11 Jahren

Hallo unconnected,

Beim Antworten auf deinen Post (Zitat) ist mir die Lösung des Problems eingefallen.

Hallo Unconnected,

die ClickOnece Berechtigungen sind auf "This is a full trust application" eingestellt.
.....

Der Fehler lag in der Berechtigung, aber nicht in der ClickOnce. Ich benutze für den Zugriff auf die Datenbank eine Windows-Authentifizierung durch eine Impersonate-Methode.

Nun rufe ich die SQL-Klasse und die darin enthaltenen Methoden nicht mehr mit dem angemeldeten Domain-Benutzer auf dem Rechner, sondern mit dem SQL-Benutzer (Windwos-Authentifizierung) auf. In dem Moment besitzt der SQL-Benutzer nicht die Berechtigungen auf den Installationspfad der Anwendung zuzugreifen.

Schwuppdiewupp -> throw Exception.

Ich habe mir nun zum Test die Berechtigung auf den Pfad gesetzt und es funktioniert 👍 !

So nun muss ich den Impersonate-Aufruf gescheiter setzten, damit die Applikation nicht mehr in die missliche Lage kommt.

Vielen Dank an die Beteiligten! Habe wieder einiges dazugelernt!

B
BruisE Themenstarter:in
12 Beiträge seit 2013
vor 11 Jahren

P.S. kann ich den Beitrag noch irgendwie als [gelöst] markieren?
Wer sucht der findet ^^ - hat sich erledigt.