dotNETportal.cz

Dobrý den,

rád bych se poradil jakým způsobem realizovat umístění knihoven do samostatného adresáře v aplikaci.

Pokud ji umístím přímo do adresáře aplikace a přidám referenci je samozřejmně vše OK, ale nevím jak postupovat pokud vytvořím pro určité knihovny samostatný adresář.

Předem děkuji

Jaký máte důvod pro umísťování DLL do jiné složky než té s EXE souborem? Není k tomu naprosto žádný důvod pokud se nejedná o zásuvné moduly, které budou dynamicky načítány za běhu aplikace. Pokud to chcete udělat pouze z důvodu že "tak by se mi to líbilo víc" tak to je zhovadělost, protože jednak se to tak nikdy nikde nedělá a jednak byste to musel zbytečně komplikovaně načítat odněkud pomocí Reflection. Pokud jsou to knihovny které sdílí více aplikací, pak je pro ně místo v Global Assembly Cache kam je dáte pomocí nástroje Gacutil.

Šlo mi o to některé knihovny logicky uspořádat.

Dále také budou některé knihovny skutečně dynamicky načítány až za běhu aplikace, ale to by patrně neměl být problém (s umístěním jinde). Nebo se mýlím ?

Pokud to vyloženě nejsou knihovny představující zásuvné moduly, které jsou dynamicky načítány za běhu aplikace pomocí Reflection (neplést s obyčejnými knihovnami nebo unmanaged knihovnami!), tak znovu opakuji že jejich umístění jinde NEMÁ ABSOLUTNĚ ŽÁDNÝ SMYSL (ale jde to pomocí Reflection a úsilí k tomu vynaložené se nevyplatí).

Pokud píšete vlastní zásuvné moduly, případně používáte k tomu určenou infrastrukturu v .NET 3.0 (System.AddIn.*, používá vlastní strukturu složek) tak to smysl má. Inspirovat se můžete článkem http://vbnet.cz/clanek--81-jak_rozsirit_...

Jinak soubory knihoven se nejlépe logicky uspořádávají podle doporučení Microsoftu - jako je to např. v .NET Frameworku: Společnost.Produkt.Subsystém.dll

Funguje to jak píšete. Velmi jednoduché.

Tomáši mnohokrát Vám děkuji

a přeji pohodové svátky

Zhovadělost to rozhodně není, dejte mi příklad která aplikace to dělá tak, že cpe DLL do jiné složky. Pokud jsou všechny assemblies pojmenované podle stejného schématu tak je to rozhodně přehlednější než všechno rozestrkávat do složek.

Kromě toho jestli jsem to správně pochopil, tak po zadání té cesty do konfiguračního souboru budou požadované assemblies hledány právě v této složce, tím pádem všechny DLL budou muset být právě na tomto místě a to potom absolutně ztrácí jakýkoliv smysl ("bordel se přesune z místa A na místo B").

Funguje to tak, že když chci některé dll separovat prostě je vložím do samostatného podadresáře.

Například mám samostatně dll pro grafy, a samostatně definice objektů. V adresáři aplikace mám hlavní dlls.

Stačí pak jen říci, pomocí příkladu výše, které podadresáře se mají projít (stačí jen jejich názvy oddělit středníkem).

Opravdu velice jednoduché a přehledné. Přesně toto jsem hledal.

Proč by to mělo ztrácet smysl? Právě naopak, dosáhnete tím toho, co chcete (tedy vy asi ne, ale tazatel ano). Pokud otevřu složku programu a vidím jeden exe soubor a adresář Bin ve které je 20 dll, které k používání aplikace nikdy přímo nevyužiji, tak tomu osobně říkám zpřehlednění.

Navíc nikdo neříká rozstrkat dll do 50ti složek, navrhuji maxilně Bin a Plugins, aby bylo na první pohled jasné kde co hledat. A jestli autor přistupuje k programu často, tak ho může přítomnost hromady dll zdržovat, což chápu.

Jasně, ze základu by do těchto složek uživatel vůbec neměl lézl, proto se to také moc často neřeší, ale jestli autor přistupuje k programu často (nebo je program povahou vyzívá k častému zásahu do svých adresářů), tak ho může přítomnost hromady dll zdržovat, což chápu. I ve firmě, kde pracuji, tak tuto metodu používáme.

Teď jsem to například viděl u komunikátoru QIP a to právě z důvodu, že se jedná o "kopírovací" program, kde si exe pouští uživatel ručně. Je to víc user friendly.