Laden...

Warum stürzt Applikation mit NullReference Exception ab?

Erstellt von Maliko vor 3 Jahren Letzter Beitrag vor 3 Jahren 1.460 Views
M
Maliko Themenstarter:in
117 Beiträge seit 2012
vor 3 Jahren
Warum stürzt Applikation mit NullReference Exception ab?

Moin,

ich hoffe hier kann mir jemand weiterhelfen. Meine ASP-Kenntnisse sind nur rudimentär und reichen gerade mal dazu aus unsere Seite weiterzuentwickeln (ich bin zu der Aufgabe wie die Jungfrau zum Kinde gekommen, da der Kollege, der das Ding ursprünglich entwickelt hat gekündigt hat und ich der einzige bin, der zumindest in der Ausbildung mal mit ASP in Berührung gekommen ist).

Und zwar habe ich momentan das Problem dass ständig die Webseite komplett abschmiert. Sprich die Seite kann noch aufgerufen werden, doch sobald man versucht sich einzuloggen landet man auf der Fehlerseite weil irgendeine Exception geworfen wird, ich weiß aber nicht welche, da das Problem bei mir local nicht auftritt und die Exceptions vom Server unterdrückt werden.

Das einzige was dann noch hilft ist den kompletten Applicationpool einmal neu zu starten. Hat vielleicht irgendjemand von euch eine Ahnung woran das liegen könnte? Weil ich hab davon nicht die geringste Ahnung und weiß nicht einmal wonach ich da suchen muss. Wenn jemand von euch ein paar Tipps hat, wonach ich mal schauen könnte um das Problem zu lokalisieren wäre ich euch schon sehr dankbar.

Wie schon gesagt, ich hab seit fast 10 Jahren kein ASP mehr wirklich gemacht und stümper hier momentan nur rum um das Ding überhaupt betreuen zu können. Ich bin inzwischen eigendlich eher im Bereich Java und Delphi aktiv. Von daher würde ich mich über ein paar Tipps sehr freuen.

16.806 Beiträge seit 2008
vor 3 Jahren

Das einzige was dann noch hilft ist den kompletten Applicationpool einmal neu zu starten.

Im Endeffekt hat das mit dem Pool nur wenig zutun; es startet einfach die Anwendung neu. Die Frage ist eher wieso die Anwendung abstürzt; aber unwahrscheinlich, dass der Pool selbst dafür verantwortlich ist.
"Voll laufen" kann der Pool jedenfalls nicht.

Weil ich hab davon nicht die geringste Ahnung und weiß nicht einmal wonach ich da suchen muss.

Ja, wir so auch nicht. Wir haben schließlich weder Code noch Exception 😉
Du solltest Dir unbedingt die Exception besorgen - zB über den Event Viewer oder eben auf dem Server erhalten.
Wenn sie unterdrückt wird, dann kannst Du das in der Web.Config ändern.

Ohne Exception ist das alles rumraten ohne wirklichen Sinn.

M
Maliko Themenstarter:in
117 Beiträge seit 2012
vor 3 Jahren

Moin,

es hat leider bis heute gedauert bis die Seite mal wieder komplett abgeschmiert ist und jetzt habe ich auch endlich eine vernünftige Fehlermeldung über den Server bekommen. Nur wirklich weiter bringt diese mich nicht.

Die Meldung lautet: > Fehlermeldung:

[NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.]

Die Codezeile die mir dabei angezeigt wird ist folgende:

public static string connetionStringtestdb = System.Web.HttpContext.Current.Session["connectionstring1"].ToString();

Die Session wird direkt beim Betreten der Seite gesetzt und funktioniert auch. Auf der Hauptseite bekomme ich nämlich keine Fehler obwohl er sachen aus der Datenbank ausliest.

Der Fehler tritt erst nach dem Login auf. Nachdem ich jetzt den Applicationpool neugestartet habe funktioniert es auch wieder. Ich bin da gerade etwas ratlos woran das liegen kann (vor allem da ich wie schon gesagt das Projekt auch nur zwangsweise übernommen habe).

T
2.219 Beiträge seit 2008
vor 3 Jahren

Warum wird der ConnectionString aus der Session gelesen?
Sowas wird aus der Config ausgelesen und nicht aus der Session.

Schaut euch am besten mal den ConfigurationManager aus .NET an, dann braucht ihr solche Konstrukte nicht.

ConfigurationManager.ConnectionStrings

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

2.078 Beiträge seit 2012
vor 3 Jahren

Unter ASP.NET Core wäre dagegen "Microsoft.Extensions.Configuration" das Mittel der Wahl.

16.806 Beiträge seit 2008
vor 3 Jahren

Der Connection String kann dynamisch sein, wenn man die Datentrennung pro User / Tenant auf physikalischer Ebene umsetzt. Da hilft einem die Config nicht.
Sicher ist jedoch, dass die Art und Weise nur krachen kann und ein grober Programmierfehler ist:
Sessions sind kein statischer Speicher sondern laufen aus. Sie also für ein statisches Feld zu nutzen ist ein richtig dicker Patzer.
nur eine Frage der Zeit, bis die Session hier Null ist und damit bei einem Zugriff eine NullReferenceException geworfen wird..

Der Fehler jedoch dürfte der sein, der im gesamten C# Universum am meisten auftritt und ist ein klassischer Programmierfehler.
[FAQ] NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt

Wenn du den Fehler nicht selbst beheben kannst, dann musst eben jemanden beauftragen.

M
Maliko Themenstarter:in
117 Beiträge seit 2012
vor 3 Jahren

Der Connection String kann dynamisch sein, wenn man die Datentrennung pro User / Tenant auf physikalischer Ebene umsetzt. Da hilft einem die Config nicht.

Das ist in diesem Fall auch so. Wir haben eine Application die je nachdem welche Domain aufgerufen wird einen anderen Datenbankserver aufruft. Von daher bringt uns die Config nichts.

Sicher ist jedoch, dass die Art und Weise nur krachen kann und ein grober Programmierfehler ist:
Sessions sind kein statischer Speicher sondern laufen aus. Sie also für ein statisches Feld zu nutzen ist ein richtig dicker Patzer.
nur eine Frage der Zeit, bis die Session hier Null ist und damit bei einem Zugriff eine NullReferenceException geworfen wird..

Und das ist das merkwürdige. Die Session wird automatisch auf der Loginseite gefüllt. Sprich auf der Seite auf der man zuvor war. Sprich die befüllung ist nicht mal eine Minute vorher. Liegt das daran dass Sessions in ASP.Net unzuverlässiger sind als in PHP? Weil anders kann ich es mir nicht vorstellen, dass ein und der selbe Code nach dem Neustarten der Application wieder funktioniert.

Aber ja, dann werde ich wohl mal die Zeit investieren müssen und das System komplett umbauen (ich hoffe dass ich sie bekomme). Das ist leider etwas dass sich durch die komplette Application zieht und von meinem Vorgänger so implementiert wurde. Hoffen wir mal dass ich das Zeitkontingent dafür bekomme.

16.806 Beiträge seit 2008
vor 3 Jahren

Das ist in diesem Fall auch so. Wir haben eine Application die je nachdem welche Domain aufgerufen wird einen anderen Datenbankserver aufruft. Von daher bringt uns die Config nichts.

Wenn die Domain hier eine statische Komponente ist, dann ist das super einfach über die Config zu lösen.


{
   "ConnectionStrings": {
      "Domain1": "String1",
      "Domain2": "String2",
      "Domain3": "String3"
   }
}

Wenn es keine statische Komponente ist, weil ihr zB ein fertiges Produkt umsetzt, dann würde man es über eine ConnectionFactory machen - aber niemals über die Http Session.

Liegt das daran dass Sessions in ASP.Net unzuverlässiger sind als in PHP? Weil anders kann ich es mir nicht vorstellen, dass ein und der selbe Code nach dem Neustarten der Application wieder funktioniert.

Nein, grundlegend sind Sessions in PHP sind nicht zuverlässiger - oder umgekehrt.
Das Problem ist hier ein einfacher Programmierfehler; und zusätzlich eben ein einfacher Folgefehler wie hier ConnectionStrings gemanaged werden.
Würde man so in PHP auch niemals tun.

M
Maliko Themenstarter:in
117 Beiträge seit 2012
vor 3 Jahren

Würde man so in PHP auch niemals tun.

Da gebe ich dir absolut recht. Ich werd das ganze jetzt auch vernünftig umbauen. Eine statische Verwaltung will unser PO nicht, aber wir handeln dass jetzt über eine zentrale Datenbank auf die immer zugegriffen wird, welche dann den ensprechenden Connectionstring zurückgibt. Ist zwar auch nicht optimal, aber die einzige Lösung die mir einfällt OnTheFly die Zugangsdaten der Datenbankserver ändern zu können ohne die Application an sich zu updaten.

16.806 Beiträge seit 2008
vor 3 Jahren

Wenn die Datenbank die Quelle für die dynamische Tenant-Verwaltung ist, dann kann das schon der richtige Ort sein.

Ist zwar auch nicht optimal, aber die einzige Lösung die mir einfällt OnTheFly die Zugangsdaten der Datenbankserver ändern zu können ohne die Application an sich zu updaten.

Hört sich nicht gerade nach einem ordentlichen Entwicklungsprozess an, wenn ihr quasi so eine Änderung ohne Update (und daher ohne Quellcodeverwaltungsystem?) hinbekommt 😉

M
Maliko Themenstarter:in
117 Beiträge seit 2012
vor 3 Jahren

Hört sich nicht gerade nach einem ordentlichen Entwicklungsprozess an, wenn ihr quasi so eine Änderung ohne Update (und daher ohne Quellcodeverwaltungsystem?) hinbekommt 😉

Ich glaub da hast du mich falsch verstanden. Natürlich muss ich die Änderung mit einem Update machen. Es geht nur darum dass die Datenbankverbindungen jederzeit ohne Update geändert werden können müssen (sprich ein Austauschen der Connectionstrings). Natürlich arbeiten wir mit Versionierung (SVN).

D
152 Beiträge seit 2013
vor 3 Jahren

Die ConnectionStrings können doch auch dynamisch in der Konfiguration hinterlegt.


string domain = ...
string connectionString = configuration.GetValue<string>($"ConnectionStrings:{domain}");
if (string.IsNullOrEmpty(connectionString))
{
    // keine Konfiguration für die Domain
}

309 Beiträge seit 2020
vor 3 Jahren

aber wir handeln dass jetzt über eine zentrale Datenbank auf die immer zugegriffen wird, welche dann den ensprechenden Connectionstring zurückgibt. Ist zwar auch nicht optimal, aber die einzige Lösung die mir einfällt OnTheFly die Zugangsdaten der Datenbankserver ändern zu können ohne die Application an sich zu updaten.

Wäre es nicht viel eleganter die Connectionstrings z.B. über eine kleine HTTP-API zu beziehen anstatt nochmal in einer Datenbank? 😁
Also die API gibt sie als JSON zurück. Geht glaube ich in Azure sogar ohne eine Zeile Code.

16.806 Beiträge seit 2008
vor 3 Jahren

Wäre es nicht viel eleganter die Connectionstrings z.B. über eine kleine HTTP-API zu beziehen anstatt nochmal in einer Datenbank? 😄

Nein. Nein. Nein. Nein.
Niemals!

Davon abgesehen, dass das hier gar nicht notwendig ist und auch nicht groß ungebaut werden möchte, macht das absolut keinen Sinn.
Zudem verteilt man keine fixen Credentials über irgendeine HTTP Schnittstelle.

P
441 Beiträge seit 2014
vor 3 Jahren

Nein. Nein. Nein. Nein.
Niemals!){gray}

So Pauschal würde ich das nicht ablehnen... Azure Key Vault z.B. ist auch eine HTTP Schnittstelle um an Credentials zu kommen, die dort gespeichert sind.

16.806 Beiträge seit 2008
vor 3 Jahren

Das ist aber keine Schnittstelle, die von außen erreichbar ist, sondern eine geschlossene Plattform.

309 Beiträge seit 2020
vor 3 Jahren

Also da finde ich es schon schöner, wenn man so einen Zugriff hat, anstelle dass jeder Client auf irgendeine Datenbank connected. Naja das muss dann halt jeder selber wissen 😁

16.806 Beiträge seit 2008
vor 3 Jahren

Dass ein Enterprise Credential System wie Azure Keyvault eine gute Lösung ist; keine Frage.
Aber a) wissen wir gar nicht, ob der Thread-Ersteller auf Azure ist und b) hat das nichts mit der generellen Aussage von Dir zutun JimStark, dass Du das Beziehen von ConnectionStrings via HTTP besser sei als eine Datenbank.
Er hat ja ohnehin schon gesagt, dass er nicht großartig umbauen will.

Enterprise Credential System: Ja.
Generell über HTTP: Nein.

M
Maliko Themenstarter:in
117 Beiträge seit 2012
vor 3 Jahren

Moin,

nope wir sind nicht auf Azure und das wird unsere Geschäftsleitung auch nicht zulassen. Wir verwenden außer für diese eine Application überhaupt keine Microsoft-Assoziierten Sprachen oder Dienste die nicht von uns selbst gehostet werden.

Von daher kommt die Keyvault sowieso nicht in Frage. Bei der Application handelt es sich lediglich um unsere Kundenportale (für jede Firma des Konzerns eines). Alleine dadurch wäre eine eigene API schreiben mit Kanonen auf Spatzen zu schießen. Wir haben unser eigenes Rechenzentrum und die Server stehen direkt nebeneinander. Sprich die Latenzen sind so gering, dass die zusätzlichen Datenbankzugriffe keine wirkliche Auswirkung haben werden.

Nur um mal eben für klarheit zu schaffen.

309 Beiträge seit 2020
vor 3 Jahren

Ist zwar auch nicht optimal, aber die einzige Lösung die mir einfällt OnTheFly die Zugangsdaten der Datenbankserver ändern zu können ohne die Application an sich zu updaten.

Ich wollte nur sagen, dass ich das Abrufen von Credentials über eine HTTP Schnittstelle schöner finde als das zusätzliche Verbinden auf eine Datenbank. Dabei ist man auch nicht nur auf Microsoft angewiesen (Open-Source gibt es ja auch)...
Mir kommt das irgendwie sehr bekannt vor, wenn z.B. irgend ein Leiter nur die Technologie nutzen will mit der er auch vertraut ist obwohl es bessere Alternativen gibt (auch bei DAX Unternehmen) 😁
Wie gesagt, ist nur meine eigene Meinung. Ich denke die Diskussion hilft dir auch nicht weiter, darum sollten wir es jetzt dabei belassen.