Mitt projekt i C# (spelet) är så långt gånget att jag inte tänker lägga ner mer tid och energi på det nu. Det sista steget var att bryta isär kompileringen av klient, server och bibliotek (dll). Läraren tyckte inte om mitt hack där jag kommenterade bort den entry-point som jag inte ville använda vid den kompileringen. Jag hade en "static Main" funktion för servern och en nästan likadan för klienten men eftersom jag inte kunde producera två exe filer med ett projekt i Visual Studio var jag tvungen att kommentera bort en åt gången för att bygga både klient och server. Fördelen var att jag, när jag testade, kunde kompiler ett program som startade en server och två klienter i separata trådar. Enligt nedan:
Men laborationsassistenen samtyckte inte. Jag hade kunnat bluffa mig runt hela problemet eftersom han inte viste vad han talade om men nu är jag så fördömt uppriktig och påpekar själv fel och problem och då får jag stå mitt kast. Till en början provade jag att kopiera projektet och ta bort den utkommenterade koden (det ena projektet (projekt och lösning (solution)) motsvarar klient och det andra server). Assistenten ansåg att: "det är inte objektorienterat att kopiera filer", jag fick retur.
Lösningen, som jag insett redan från början, var att ha en gemensam "solution" med flera projekt där projekten har möjlighet att använda sig av samma filer. Det fungerade så när som på att när jag valde att ha olika namn på programmen (DarkClient och DarkServer) fallerade deserialiseringen (när jag tar emot ett meddelande som är en klass så är den en ström av bits men jag vill såklart omvandla den tillbaka till ett objekt). Det visade sig att när jag kompilerade två varianter av "Message" klassen (som är meddlandet jag använder) med olika "assembly name" (DarkClient och DarkServer), så klarar inte mottagaren av att deserialisera.
Den klass som man serialiserar/deserialiserar måste inte bara vara lika i form av samma fil vid kompileringen utan måste också vara kompilerade under samma "assembly name". Som jag ser det nu är det puckat men det finns säkert en tanke bakom.
Lösningen var att lägga in "Message" i den dll som jag sedan tidigare skapat (eftersom det var tvunget att finnas en dll för att få godkännt på laben). Jag skapade således ännu ett projekt och la det i samma "solution" som jag hade för klient och server. Nu hade jag alltså tre projekt i samma "solution":
Såhär i efterhand hade jag kunnat använda den här lösningen hela tiden, om jag bara vetat att jag hade möjligheten.
Summan av kardemmumman: vad jag i linux kunnat gjort med en Makefile på under en minut tog mig i Visual Studio ca 8 timmar av frustration och irritation.
Så vad blev det för spel då? Här är en bild som beskriver spelet ganska väl:
Men laborationsassistenen samtyckte inte. Jag hade kunnat bluffa mig runt hela problemet eftersom han inte viste vad han talade om men nu är jag så fördömt uppriktig och påpekar själv fel och problem och då får jag stå mitt kast. Till en början provade jag att kopiera projektet och ta bort den utkommenterade koden (det ena projektet (projekt och lösning (solution)) motsvarar klient och det andra server). Assistenten ansåg att: "det är inte objektorienterat att kopiera filer", jag fick retur.
Lösningen, som jag insett redan från början, var att ha en gemensam "solution" med flera projekt där projekten har möjlighet att använda sig av samma filer. Det fungerade så när som på att när jag valde att ha olika namn på programmen (DarkClient och DarkServer) fallerade deserialiseringen (när jag tar emot ett meddelande som är en klass så är den en ström av bits men jag vill såklart omvandla den tillbaka till ett objekt). Det visade sig att när jag kompilerade två varianter av "Message" klassen (som är meddlandet jag använder) med olika "assembly name" (DarkClient och DarkServer), så klarar inte mottagaren av att deserialisera.
Den klass som man serialiserar/deserialiserar måste inte bara vara lika i form av samma fil vid kompileringen utan måste också vara kompilerade under samma "assembly name". Som jag ser det nu är det puckat men det finns säkert en tanke bakom.
Lösningen var att lägga in "Message" i den dll som jag sedan tidigare skapat (eftersom det var tvunget att finnas en dll för att få godkännt på laben). Jag skapade således ännu ett projekt och la det i samma "solution" som jag hade för klient och server. Nu hade jag alltså tre projekt i samma "solution":
Såhär i efterhand hade jag kunnat använda den här lösningen hela tiden, om jag bara vetat att jag hade möjligheten. Summan av kardemmumman: vad jag i linux kunnat gjort med en Makefile på under en minut tog mig i Visual Studio ca 8 timmar av frustration och irritation.
Så vad blev det för spel då? Här är en bild som beskriver spelet ganska väl:
2 kommentarer:
"Summan av kardemmumman: vad jag i linux kunnat gjort med en Makefile på under en minut tog mig i Visual Studio ca 8 timmar av frustration och irritation."
Hehe, vad försöker du säga? :P
Eftersom jag inte bryr mig om att vara politiskt korrekt (linux är ett OS och VS är en IDE mm.) så nöjer jag mig med att säga att linux är smidigare när man vet vad man vill. Annars kan man klicka omkring i Visual Studio och lösa problem som man inte viste att man hade.
Skicka en kommentar