Fehlende Projektverweise in Solution für unterschiedliche Projekttypen

Hallo Leute

Eine selbstgeschriebene DLL soll zum einen unter .NET 3.5 und .NET CF 3.5 verwendet werden. Also einmal für normale PC x86 Windows Anwendungen und zusätzlich auch eine Anwendung, für den Einsatz unter Windows CE Systemen.

Mein Problem ist der saubere Weg, wie ich meinen Code in einer Solution für diese unterschiedlichen Projekttypen sauber verknüpfen kann ohne alle doppelt zu schreiben.

Mein bisheriger Weg:

Solution: MySolution mit projekten...

Project F_global : Fremd DLL die unter x86 und WinCE funktioniert (.NET 3.5)

Projekt A_wce : Eigenes DLL Projekt, dass F_global verwendet und nur unter WindowsCE funktioniert.

Projekt A_win : Eigenes DLL Projekt, dass F_global verwendet und nur unter x86 Windows funktioniert. mit eigenen Codeteilen

Projekt B_wce : Eigenes Dll Projekt, dass auf A_wce verweist und unter WindowsCE funktioniert. Im prinzip funktioniert der Code auch unter x86

Jetzt kommt abschließend noch das Problemprojekt:
Project B_win : Eigenes DLL Projekt, dass per Link alle Dateien des B_wce einbindet unter x86 funktioniert und auf A_win verweist. ziel ist es nicht den ganzen Code doppelt zu schreiben.

Abschließend wird jetzt das DLL Projekt in einer Windows Anwendung verwendet.
Project C_win : windows Anwendung, die Projekt B_win verwendet.
Hier kommt beim ausführen eine Fehlermeldung, dass noch ein Verweis auf A_wce fehlen würde. Mir ist aber nicht klar warum und zudem würde die Windows Anwendung nur funktionieren, wenn der verweis auf A_win verweisen würde. 🤔
Daher habe ich den verweis auf A_win eingebaut. Dann kommt aber wieder eine Fehlermeldung, da anscheinend der B_wce Code nicht auf A_win verweist sonder auf A_wce.

Hat jemand von euch ein Tipp wie ich das mit den Projekten funktionsfähig verbinden kann? X(

Grüße Cornflake

Schau Dir Newtonsoft.Json an.
Er löst das (noch) über verschiedene Solutions - anders geht es auch aktuell nicht.
Bald (mit DNX) geht das einfacher mit der xproj-Projekten und project.Json-Dateien.

Mit Deinem alten Zeugs und .NET 3.5 wird Dir aber nur die Verwaltung mit verschiedenen Solutions (und im dümmsten Fall mit eigenen Projekten je Target) übrig bleiben.

Hallo Abt

Ich habe mal die Dateien von Netonsoft verglichen.

Wenn ich das richtig sehe, ist das eigentlich nur eine Solution die der da verwendet. Es unterscheiden sich anscheinend nur die GUIDs und Namen der Projektdateien (.csproj)
Die Projekte sind dann wie bei mir unterschiedlich Art z.B. Net35 und Portable.
In den Projektfiles werden dann verschiedene Konstanten gesetzt z.B. (TRACE;DEBUG;PORTABLE) vs (TRACE;DEBUG;CODE_ANALYSIS;NET35).
Im Code wird dann z.B. mit Präprozessorbefehlen:

#if !(NET20 || NET35 || PORTABLE40 || PORTABLE)
        private static string ToStringInternal(BigInteger value)
        {
            return value.ToString(null, CultureInfo.InvariantCulture);
        }
#endif

zwischen den verschiedenen Projektarten unterschieden.

Leider konnte ich nicht erkennen, wie er auf unterschiedliche externe DLL verweist. Anscheinend nutzt er keine externen Dlls.

Ich konnte jetzt auch nicht erkennen, ob er die Dateien als Link einbindet oder nicht.

Hast du da nochn Tipp?

Grüße Cornflake

Noch eine Frage zu den DLL Verweisen.

Wenn meine Anwendung eine DLL (x) einbindet, die wiederum eine andere DLL (y) einbindet, dann muss ich doch in der Anwendung normalerweise nur die DLL (x) einbinden?

Die dahintergelagerte DLL (y) muss ich doch nicht noch extra in der Anwendung einbinden/verweisen ?

Grüße Cornflake

Nicht extra verweisen, aber die muss im (standardmäßig) bin-Ordner liegen.

Sorry hänge aber immer noch 😦

Nochmal zu dieser dll Projektverknüpfungsgeschichte.

Also es gibt :

DLL-Project F_global
DLL-Projekt A_win : Verwendet F_global und erstellt:

public abstract class MyClass
{
 public virtual void MyMethod() {...}
}

DLL-Project B_win : Verweist auf A_win und erstellt:

public class MyClassErbe : MyClass
{ ... }

In einer weiteren Klasse funktioniert in diesem Projekt:

public class otherClass 
{ 
void  test()
{
MyClassErbe  mce = new MyClassErbe();
mce.MyMethod();   //Methode existiert und lässt sich aufrufen
}
}

Im Windows Project C_win : Verweist auf Projekt B_win
kommt es zum Fehler:

public class SomeOtherClass 
{ 
void  test()
{
MyClassErbe  mce = new MyClassErbe();
mce.MyMethod();   //!!!! Methode existiert nicht mehr !!!!
}
}

Irgend eine Idee, warum da die Methode auf einmal nicht mehr existiert?

Grüße Cornflake

Genaue Fehlermeldung?

Fehlermeldung:
Fehler 52 "B_win.MyClassErbe" enthält keine Definition für "MyMethod", und es konnte keine Erweiterungsmethode "MyMethod" gefunden werden, die ein erstes Argument vom Typ "B_win.MyClassErbe" akzeptiert. (Fehlt eine Using-Direktive oder ein Assemblyverweis?) C:\Projekt_c_win\Program.cs 74 17 C_win

Es ist zum Haare raufen.

Ich habe jetzt C_win ein Verweis auf A_win hinzugefügt.
Die Methode existiert jetzt auf einmal, allerdings kommt beim Ausführen der Fehler:> Fehlermeldung:

"Der Typeninitialisierer für "C_win.Program" hat eine Ausnahme verursacht."

{"Die Datei oder Assembly "C_win, Version=1.0.5933.33033, Culture=neutral, PublicKeyToken=null" oder eine Abhängigkeit davon wurde nicht gefunden. Es wurde versucht, eine Datei mit einem falschen Format zu laden."}

Bad Image Fehler = falsche Bittigkeit oder falsche Plattform.
Solche Fehler bekommst Du gut selbst raus, wenn Du die entsprechend englische Exception in Google eingibst.
Wenn die Bittigkeit falsch ist, dann funktioniert Intellisense auch (korrekterweise) nicht mehr richtig.

Bei Dir ist wohl was grundlegend krum...

Super vielen Dank 😁 Wäre ich bei der Fehlermeldung nicht drauf gekommen.

Während ich in den anderen Projekten, jeweils x86 zum Debugen mit Edit & Continue eingestellt habe, war in der exe noch Any CPU aktiv.

Schade, dass man im Debug Modus nicht generell alles auf x86 CPU laufen lassen kann und dann beim Release erstellen automatisch auf Any CPU kompiliert. Dann könnte man zum Debuggen Edit & Continue verwenden und später im richtigen Einsatz auf Any CPU zurück greifen. So laufe ich aktuell gefahr, zu vergessen, dass beim Umstellen auf Release die "Any CPU" einzustellen.

Grüße Cornflake

Schade, dass man im Debug Modus nicht generell alles auf x86 CPU laufen lassen kann und dann beim Release erstellen automatisch auf Any CPU.

Doch, das kannst du. Hab jetzt kein VS zur Hand, aber spätestens wenn du die Projektdatei manuell bearbeitest, kannst du das erreichen. Sind ja standardmäßig zwei komplett voneinander unabhängige Konfigurationen.

Rechtsklick auf die Solution, Eigenschaften.
Dort auf Configuration Manager und die Profile für Debug und Release unterschiedlich setzen -> fertig.

Einerseits würde ich Dir bei komplizierten BuildProzessen empfehlen, FAKE anzuschauen - da kommt Visual Studio an seine Grenzen.

Für reine Bit-Einstellungen kann man auch Corflags benutzen, um im nachhinein die Bit Version einzustellen - solange Du keinen speziellen Code mit Präprozessor #if hast, was ich brauche.

Danke für eure Tipps 😃