Htio bih napraviti statičku biblioteku u C#-u (analogija: LIB u C++u) no koliko čitam na net-u to nije moguće? Želim određeni code sakriti i da se implementira u aplikaciju pri compiliranju a ne da se poziva izvana (dll).
Statička biblioteka za C# i VB.NET?
- poruka: 17
- |
- čitano: 3.101
- |
- moderatori:
Lazarus Long, XXX-Man, vincimus
- +/- sve poruke
- ravni prikaz
- starije poruke gore
Kako ćeš ju sakriti? Ionako će biti vidljiv kod kroz reflector ili slično.
Pogledaj http://blogs.msdn.com/b/junfeng/archive/2005/02/12/371683.aspx i http://research.microsoft.com/en-us/people/mbarnett/ILMerge.aspx
Pod "sakriti" mislim isto što i kod dll-a. Dati nekoj aplikaciji prototipe eksportabilnih funkcija koje se mogu koristiti i to je to. Programer nema direktan uvid u code a omogućeno mu je da ga koristi. Samo što ja u ovom slučaju ne želim vući dll sa aplikacijom pa mi je poželjna statička biblioteka.
Imaš nešto što se zove merganje assemblyja, znaći ako imaš program.exe prvi.dll, drugi.dll. Taj utiliti sve spoji u jedan Program.exe. Što je slično statičnom linkanju.
Potraži aspnet_merge.exe; ILMarge ili u Google upiši .NET assembly merging. Postupak je malo drugačiji nego u native kodu. Prvo napraviš assemblyje i onda ih spojiš
Nikad to nisam koristio pa bih bio zahvalan ako javiš kako je prošlo.
I sam sada čitam da je ILMerge najbliže što se može doći tom rješenju. No, nisam siguran da ću biti zadovoljan time jer klijenti mi nisu svi super programerski potkovani a ovo se čini poprilični pothvat.
Za sada sve radi direktnim kopiranjem coda kojeg im ja dam, ali upravo zbog toga da smanjim količinu coda u njihovim aplikacijama i da smanjim mogućnost pogreške njihovom modifikacijom mog coda pokušavam to nekako zapakirati. Prethodno sam već sve napravio u dll-u no preko 80% njih ne voli to nužno imati uz aplikaciju, dok i sama sigurnost je tada problem pa moram dodatno provjeravati hasheve dll-a itd. Sve u svemu - komplikacija.
Šteta. Nadam se da će se u .NETu ovakvo nešto uskoro omogućiti.
Mislim da od toga ništa neće biti. Po mom mišljenju, stvar je u tome da se .TEXT i import table u PE file-u u kojem je .NET aplikacija ne može mergati (kod linkera patchati) kao kao native PE.
Možda možeš, ako želiš izbjeći greške kod kopiranja koda, napraviti patch file kojeg bi korisnik mergao s več postoječim sourceom tako da izbjegneš greške kod editiranja koda.
Lp.
Nemam s time baš iskustva... Na što točno misliš?
Pa npr. Subversion i neki drugi alati, ne moraju biti Source Control Versioning, mogu napraviti patch file u kojem su zapisane razlike u datotekama. I taj patch file može iskoristiti netko drugi ( klijent ), da mu se ažuriraju datoteke. Tako da se izbjegne scenarij u ovoj datoteci u ovoj funkciji promjeni ovo a, u ovoj ovo. Nego se sve obavi automatizirano. Nakon toga ostaje samo pokrenuti build skriptu.
EDIT: Mislim da TortoiseDiff i WinMerge imaju tu mogucnost
Budem još malo istražio pa ću vidjeti što je najjednostavnije.
Ako im mergea kod, može biti prilično nezgodno izvoditi merge kod konflikata. Tracer, zašto nebi ti sve spajao u jedan DLL koji ide s aplikacijskim ostatkom? Znači da sve što im ti daješ ide njima kao vanjski lib, a sve što oni u njihov. Na taj način imaš samo dvije datoteke, što se ne čini problemom, a njihova će aplikacija uvijek uzimati kod koji je najsvježiji, onaj iz DLL-a prisutnog u rootu aplikacije.
Već sam tako bio napravio i neko vrijeme je išto, no dva su "problema". Prvo, riječ je o nekim osjetljivim funkcijama zbog koje se stvar komplicira pa je onda potrebno vršiti dodatne (hash) provjere samog dll-a prije poziva tih funkcija. Prosječnom programeru je to opet dodatni posao kojeg ga želim riješiti. Drugo, klijentima je nezgodno da moraju uz svoju aplikaciju vući i taj dll jer su im aplikacije najčešće stand-alone (u smislu da je samo osnovi .NET framework potreban za rad). Zato, pokušavam to izvesti najjednostavnije moguće, a to je copy-paste (kako trenutno radi). No, pošto coda ima cca 100 linija mislio sam to nekako importirati poput davanja LIB-a u C++u. No, očito nije moguće (bez osjetnih komplikacija).
No svejedno, neka bude c/p. Nije greda niti tih 100 linija coda ako već baš mora biti.
Ne znam zašto je problem jedna dodatna datoteka, no svakako, imaš MEF koji možeš putem interfejsa ugraditi kao dinamički plugabilni model. Možeš i distribuciju vršiti putem 1-click deploya. Ručno dijeljenje preskoči.
Nažalost, nisu svi klijenti istih programerskih (pred)znanja pa moram gledati na najjednostavnije jer ne želim noći provoditi odgovarajući na stotine support mailova. Ovako im dam plain source i neka ga ugrade. Samo sam mislio da se i to može pojednostaviti no već smo ustanovili da to nije tako jednostavno.
Možeš li reči zašto ti klijenti imaju potrebu "programirati", o čemu se ovdje uopce radi ?
U krajnjem slucaju se možeš naučiti koristiti neki sustav verzioniranja (preporučujem GIT),
te deploy-ati aplikaciju sa nekim alatom tipa Capistrano ili Fabric.
Radi se o implementaciji datoteke mog custom formata. Taj code je potreban za IO operacije s tom datotekom.
Ali ako osobe imaju znanje programiranja, code repo je rješenje #1. Ako im nudiš to kao svoj proizvod, nema smisla ne prihvatiti dobro rješenje kakvo je tvoj lib (DLL). Ako Ako su krajnji korisnici, također. Distribucija koja se sama raspakira ili 1-click deploy koji funkcionira besprijekorno, odlična su rješenja.