Visual Studio wirft mir hier völlig willkürlich Exceptions um die Ohren, obwohl sich am Projekt nichts geändert hat.
Genauer gesagt, RemotingExceptions: cl.ly/H6Mu
Ich weiß weder, warum, noch wo diese Exception im Code geworfen wird, ich weiß nur, dass sie geworfen wird.
Laut Google hat die Exception irgendwas mit Servern etc. zu tun, was hier aber nicht sein kann, da meine Anwendung nichts mit Servern etc. am Hut hat.
Weiß jemand, wie ich diesen unglaublich nervigen Mist loswerde?

Könnte was damit zutun haben:
de.wikipedia.org/wiki/.NET_Remoting
(Pass auf, ist ein Prank-Link, lol)

Wird vllt irgendwo auch zwischen lokalen Objekten benutzt. kA, hab den Fehler auch noch nie gesehn.

Sagt mir alles nichts, was vermutl. daran liegt, dass ich keins der aufgelisteten Dinge benutze.

Hi
kannst du das etwas genauer spezifizieren? Bei Remoting gehts eigentlich allgemein um den Datenaustausch, egal ob es um Interprozesskommunikation oder Internet geht. Evtl. wäre auch der StackTrace+InnerException (falls vorhanden) interessant.

Gruß
~blaze~

Ich hab weder Stacktrace noch InnerException
Ich hab im XAML ein paar Bindings drin, aber die haben nichts mit Internet etc. zu tun.

Wie gesagt, Remoting geht nicht nur über Internet. Wenn du zwischen zwei Anwendungen Daten austauschst (IPC) kannst du ebenfalls auf Remoting zurückgreifen. Afaik basiert das auf named pipes. Ich schätze, dass es irgendwas mit einem Datum zu tun hat, das du übertragen willst. Dazu müsste man aber die Anwendung und deren Kontext genauer kennen. Pauschal lässt sich da eher weniger etwas sagen. Bin bei Remoting und WPF leider nicht so bewandert.
Was jetzt ins Blaue geraten wäre, wäre, dass du versuchst, ein Datum zu bekommen, dessen Typ bei einer Konversion eine Ausnahme erzeugt, die dann von der RemotingException zurückgeleitet wird. Da das Debugging in deinem Fall nicht möglich und kein Stacktrace erzeugbar ist, gehe ich allerdings stark davon aus, dass die Ausnahme in der anderen Anwendung auftritt, mit der dein Programm kommuniziert.
Wenn du den Zeitpunkt feststellen kannst, zu dem die Anwendung fliegt, könnten wir evtl. weitere Details ermitteln.

Gruß
~blaze~

So. Durch Rumprobiererei hab ich bemerkt, dass die RemotingException nur auftritt, wenn ich das Programm nicht als AnyCPU kompiliere, warum auch immer.
Allerdings funktionieren die DWMAPI-Aufrufe dann nicht mehr, weil dann beim Aufruf AccessViolationExceptions geschmissen werden. Soll ich den DWMAPI-Teil als separate DLL mitliefern, die als x86 kompiliert ist, und die ins AnyCPU-Projekt einhängen oder wie?

Ich würde an deiner Stelle den DwmApi-Kram nicht selbst machen, sondern das Microsoft Ribbon for WPF herunterladen und daraus die Microsoft.Windows.Shell.dll verwenden. Diese Library hat die benötigten Aufrufe usw. in WPF-Form gekapselt und dadurch WESENTLICH vereinfacht. Vielleicht geht es ja damit?

Hier gehts nicht um 08/15-Aeroränder, sondern um die DWMGetColorizationParameters- und DWMSetColorizationParameters-APIs.
Die funktionieren auch, wenn ich sie in nem Testprojekt einfach so aufrufe, aber im jetzigen Projekt hindert mich die RemotingException daran.

Edit: Hat sich erledigt. Der zweite uint-Parameter MUSS dabei sein. Anscheinend hurrdurrt VB.NET da im Hintergrund noch rum, sodass das noch irgendwie geht, in C# MUSS der Parameter anscheinend da seom-