Laden...

MAUI - Im Release-Mode kein IRootObjectProvider registriert

Letzter Beitrag vor einem Jahr 8 Posts 630 Views
MAUI - Im Release-Mode kein IRootObjectProvider registriert

Hallo zusammen,

ich hab das Problem, dass mein MAUI-Projekt nach dem Publish sich mit einem EventLog-Eintrag sofort wieder beendet.

Das Problem ist Folgendes:
Ich habe eine MarkupExtension, die anhand des IServiceProvider-Parameters den IRootObjectProvider-Dienst abruft.
Genau diesen Dienst scheint es im Relase-Mode aber nicht zu geben? Im Debug-Mode ist alles korrekt da.

Das ist der Code der ServiceProvider-Klasse, die da zum Einsatz kommt:
https://github.com/dotnet/maui/blob/main/src/Controls/src/Xaml/XamlServiceProvider.cs
Der Code ergibt für mich keinen Sinn, wenn es den IRootObjectProvider nicht gibt, müsste der context null sein, aber dann gäbe es auch andere Dienste nicht, die aber da sind.

Hat jemand eine Idee, woran das liegt und wie ich es beheben kann?

Besten Dank 😃

NuGet Packages im Code auslesen
lock Alternative für async/await

Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.

Ne, hilft leider nicht.

Ich brauch den IRootObjectProvider ja abhängig vom Kontext der MarkupExtension.
Die Services der Application sind dagegen ohne Kontext und enthalten auch keinen IRootObjectProvider.

Ich habe auch keine Lösung für das Problem gefunden, ist scheinbar ein Bug in MAUI.
Ich habe aber einen Workaround gefunden, sodass ich zumindest weiterarbeiten kann.

NuGet Packages im Code auslesen
lock Alternative für async/await

Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.

Zitat von Palladin007

Ich habe auch keine Lösung für das Problem gefunden, ist scheinbar ein Bug in MAUI.

Ein Bug dazu auf GitHub gemeldet, dass man sich kümmern kann?
Find nämlich 0 Issues zu IRootObjectProvider (ausser ein Roadmap Item), was bisschen weird is, wenns wirklich nen Bug sein sollte.

Ich habe gerade ein Issue dazu erstellt:

https://github.com/dotnet/maui/issues/16881

NuGet Packages im Code auslesen
lock Alternative für async/await

Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.

So wie es aussieht, musst du wohl ein Test Projekt bereitstellen.
Hoffentlich ist das einfach machbar, dann kann es ggf. schnell gefixt werden 😃
Hatte zwar auch mal im Source geschaut, bin aber leider damit nicht sonderlich vertraut.
Wie portieren bei uns gerade auch einen Client von WPF zu Maui, da halte ich bei solchen Themen auch die Augen offen.

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.

Wozu auch immer sie ein Repository haben wollten, ich hätte gedacht, der Code reicht 😄
Naja, jedenfalls gibt's jetzt ein Repository mit dem Bug.

Hatte zwar auch mal im Source geschaut, bin aber leider damit nicht sonderlich vertraut.

Dito - ich werde aus dem Code auch nicht schlau, zumindest sehe ich keinen Grund, warum er IRootObjectProvider nicht finden sollte, alles andere aber schon.

NuGet Packages im Code auslesen
lock Alternative für async/await

Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.

Zitat von Palladin007

Wozu auch immer sie ein Repository haben wollten, ich hätte gedacht, der Code reicht 😄

Ist generell üblich, dass man ein lauffähiges Beispiel bringen soll.
Steht auch in den Issue Guidelines der meisten Projekte, hier von MAUI.

Why do we ask for a reproducible example?

Depending on your project a codebase can be pretty big. The bigger your project, the more factors that can be of influence on a bug or issue that you might be seeing. In order to be sure that this is something that is happening in .NET MAUI and not something in your code (or a combination of these things), it is super helpful to have a small sample that reproduces the issue. This way we can:

  • better pinpoint the source of the issue;
  • therefore, we can fix the issue faster;
  • and we can make sure that the issue is not a false positive.

It also acts as a double-edged sword. When you take your code apart piece-by-piece in a new project, adding things back one by one, it will become very clear what different factors are at play here and you might discover that the issue might be something in your code. At the very least you will be able to provide a very detailed description of what you're seeing. That helps us get to the cause faster and resolve the issue quicker.

Dann kann man direkt das Ding ziehen, debuggen und sehen woran es liegt und nicht erst Zeit verschwenden in ein Setup, in dem der Error evtl. nicht auftaucht.
Spart Zeit, Frust und Co.