- This topic has 16 hozzászólás, 4 résztvevő, and was last updated 17 years, 9 months telt el by
.
-
Bejegyzés
-
Ha elmondod, mit szeretnél, még segítünk is. C# az .NET/Mono nyelv, nem tudom, hogy lenne benne statikus könyvtár de biztos. Mi a probléma? Mit szeretnél?
Ha elmondod, mit szeretnél, még segítünk is. C# az .NET/Mono nyelv, nem tudom, hogy lenne benne statikus könyvtár de biztos. Mi a probléma? Mit szeretnél?
Azt szeretném elérni, hogy ne kelljen monodevelop-ban mindenféle menükben hozzáadni a fájlt a projecthez, hanem kódba be tudjam írni, hogy melyik könyvtárat szeretném használni (mint c-/c++ -ban az #include vagy pascal-ban a uses).
Lehet, hogy nem statikus könyvtárnak hívják, de meg lehet azt is csinálni, hogy egy forráskódú fájlt hozzáadok és szerintem az nem lesz dinamikus, de ez végül is nem olyan fontos.
A lényeg az IDE kikerülése a kóddal.
Azt szeretném elérni, hogy ne kelljen monodevelop-ban mindenféle menükben hozzáadni a fájlt a projecthez, hanem kódba be tudjam írni, hogy melyik könyvtárat szeretném használni (mint c-/c++ -ban az #include vagy pascal-ban a uses).
Lehet, hogy nem statikus könyvtárnak hívják, de meg lehet azt is csinálni, hogy egy forráskódú fájlt hozzáadok és szerintem az nem lesz dinamikus, de ez végül is nem olyan fontos.
A lényeg az IDE kikerülése a kóddal.
A dolog Reflector-ozással megoldható, ám a kódot kötötté teszi, mert nem lehetnek dolgok akárhol. De tulajdonkép az yó, ha az IDE-be adod meg, mert akkor a build környezet dolga, hogy hol vannak a libek, nem kötöd le, hogy X lib csak a /opt/XYlib/lib/X.Y.dll helyen lehet, hanem akárhol, ahol a mono meg képes találni.
Reflectorozással csak úgy tudod megoldani, ha ismered a lib helyét, hogy hol van. A System.Reflection névteret nézegesd a MSDN-en.Amőgy .NET-ben az, hogy a projected része a dll névtere, nem jelenti azt, hogy használod is, lehet pl. using-ozni, és akkor explicite jelzed, hogy használod (ezzel persze beemeled a globális névtérbe a libet, de nem kötelező ezt kihasználni).
A dolog Reflector-ozással megoldható, ám a kódot kötötté teszi, mert nem lehetnek dolgok akárhol. De tulajdonkép az yó, ha az IDE-be adod meg, mert akkor a build környezet dolga, hogy hol vannak a libek, nem kötöd le, hogy X lib csak a /opt/XYlib/lib/X.Y.dll helyen lehet, hanem akárhol, ahol a mono meg képes találni.
Reflectorozással csak úgy tudod megoldani, ha ismered a lib helyét, hogy hol van. A System.Reflection névteret nézegesd a MSDN-en.Amőgy .NET-ben az, hogy a projected része a dll névtere, nem jelenti azt, hogy használod is, lehet pl. using-ozni, és akkor explicite jelzed, hogy használod (ezzel persze beemeled a globális névtérbe a libet, de nem kötelező ezt kihasználni).
Az a baj az IDE megoldásával, hogy ez az ostoba bemásolja a dll-t a project mappájába, így a dll-ből annyi példány lesz, amennyi project használja. A lefordított programok pedig mindig a saját mappájukban lévő dll-t használják. Ez pedig gáz, hiszen tudtommal pont az a dinamikus könyvtár lényege, hogy egy van belőle és ha frissítem, akkor minden program az újat használja anélkül, hogy újra kéne őket fordítani, vagy ahány program használja, annyi mappába át kéne másolni a dll-t.
És nem találtam monodevelop-ban olyan beállítást, amivel ezt a másolgatást ki lehetne kapcsolni.
Az a baj az IDE megoldásával, hogy ez az ostoba bemásolja a dll-t a project mappájába, így a dll-ből annyi példány lesz, amennyi project használja. A lefordított programok pedig mindig a saját mappájukban lévő dll-t használják. Ez pedig gáz, hiszen tudtommal pont az a dinamikus könyvtár lényege, hogy egy van belőle és ha frissítem, akkor minden program az újat használja anélkül, hogy újra kéne őket fordítani, vagy ahány program használja, annyi mappába át kéne másolni a dll-t.
És nem találtam monodevelop-ban olyan beállítást, amivel ezt a másolgatást ki lehetne kapcsolni.
„ez az ostoba bemásolja a dll-t a project mappájába…”
Vagy inkább nem ostoba, csak nem képes előrelátni az időben, és/vagy a kódolója fejében…„És nem találtam monodevelop-ban olyan beállítást, amivel ezt a másolgatást ki lehetne kapcsolni.”
Nem az ide-ben kell beállítgatni, hanem neked kell úgy kódolni, hogy a futás után (megkeresse és) betöltse a dll-t onnan, ahol lesz… ill. arról az esetről is neked kell gondoskodni, ha a dll nincs meg.
Mielőtt ilyen dologba kezdesz nem árt néhány dologgal tisztába lenni:
1) mi az a dinamikus fgv. könyvtár
2) hogyan működik
(3) az adott file tényleg az (vagy csak a neve olyan)… nem dinamikusat, csak fordítási időben lehet felhasználni)
4) milyen fgv-ekkel lehet betölteni egy dinamikus fgv-t (az adott/használt függvénykönyvtár-betöltő esetén, mert ugye ez „gyártónként” (működésben, függvénynévben) eltérő lehet, még , ha a dinamikus könyvtár ugyanaz akkor is)
5) tudnod kell, hogy mely helyen/helyeken érdemes keresni – a majdan futó program által – a dinamikus könyvtárat (azt/ezeket az elérési utat/utakat kell megadni a függvénykönyvtár-betöltőnek)Feltételezem, hogy a 4. pont kivételével minden pontra ismered a választ.
„Próbálkoztam mindenféle helyen találni ilyet, de sehol nem találtam, hogy lehetne megcsinálni.”
Pl a neten próbáltad. Bár, csak van valami referencia manuálja is annak, amit használsz…„ez az ostoba bemásolja a dll-t a project mappájába…”
Vagy inkább nem ostoba, csak nem képes előrelátni az időben, és/vagy a kódolója fejében…„És nem találtam monodevelop-ban olyan beállítást, amivel ezt a másolgatást ki lehetne kapcsolni.”
Nem az ide-ben kell beállítgatni, hanem neked kell úgy kódolni, hogy a futás után (megkeresse és) betöltse a dll-t onnan, ahol lesz… ill. arról az esetről is neked kell gondoskodni, ha a dll nincs meg.
Mielőtt ilyen dologba kezdesz nem árt néhány dologgal tisztába lenni:
1) mi az a dinamikus fgv. könyvtár
2) hogyan működik
(3) az adott file tényleg az (vagy csak a neve olyan)… nem dinamikusat, csak fordítási időben lehet felhasználni)
4) milyen fgv-ekkel lehet betölteni egy dinamikus fgv-t (az adott/használt függvénykönyvtár-betöltő esetén, mert ugye ez „gyártónként” (működésben, függvénynévben) eltérő lehet, még , ha a dinamikus könyvtár ugyanaz akkor is)
5) tudnod kell, hogy mely helyen/helyeken érdemes keresni – a majdan futó program által – a dinamikus könyvtárat (azt/ezeket az elérési utat/utakat kell megadni a függvénykönyvtár-betöltőnek)Feltételezem, hogy a 4. pont kivételével minden pontra ismered a választ.
„Próbálkoztam mindenféle helyen találni ilyet, de sehol nem találtam, hogy lehetne megcsinálni.”
Pl a neten próbáltad. Bár, csak van valami referencia manuálja is annak, amit használsz…
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz