|
|
 | Reference til dll
Fra : Christer Østergaard |
Dato : 13-01-02 23:51 |
|
Hej alle!
Jeg er forholdsvis ny i VB, og sidder lige nu med et mindre projekt, hvor
Word VBA tager brug af en selvudviklet dll. Til at registrere dll'en bruger
jeg regsvr32. Det er min idé, at .dot filen skal enable interface (menu
osv., men at dll'en som sådan skal indeholde core-delen af løsningen.
Hver gang jeg laver en opdatering af dll'en, afregistrerer jeg den med /u,
for så at genregistrere den når jeg har opdaterer dll'en fra VB. Problemet
er, at den reference jeg sætter i VBA projektet til dll'en er ugyldig efter
genregistrering.
Jeg er i tvivl om følgende ting: Er brugen af regsvr32 den korrekte måde at
registrere dll'en på i dette tilfølde. Og hvordan kan jeg undgå at miste
referencen i fremtiden, især med henblik på, at løsningen skal ud til andre
brugere end mig.
Jeg søger at komme så tæt på en smertefri installation som muligt, helst
hvor man bare smider .dot-filen i Offices startup dir og registrerer dll'en.
Men med ovenstående problemer får jeg jo et hyr hver gang jeg evt. skal
sende en opdateret dll ud, da alt tyder på at referencen vil blive væk for
..dot filen :|
Nogen som kan give mig lidt retning her? På forhånd tak!
Mvh.
Christer
| |
 Carsten Suurland (14-01-2002)
| Kommentar
Fra : Carsten Suurland |
Dato : 14-01-02 01:02 |
|
Hej Christer
Det du skal gøre for at få det til at virke, er at gøre din DLL binær
kompatibel med tidligere versioner... (hvilket den tilsyneladende ikke er
nu)
Fremgangsmåden er følgende:
Kompiler din DLL og lig den i et underbibliotek i din projektmappe.
Gå derefter ind i DLL projektets egenskaber, find fanebladet hvorpå du kan
angive kompatibilitet og sæt denne til binær kompatibilitet... sørg samtidig
for at du udpeger den DLL du lige har kompileret.
Endeligt kompilerer du din DLL én gang til, denne gang ikke til det
oprettede underbibliotek med til selve projektmappen.
Den DLL der ligger i selve projektmappen, er den du skal distribuere.
Den der ligger i undermappen er den der anvendes som reference i forbindelse
med den binære kompatibilitet. Denne kan du opdatere efterhånden som du
tilføjer nye funktioner til din DLL.
Problemet opstår da der bliver tildelt nye GUIDs til din DLL (med
underliggende klasser) hver gang du kompilerer med mindre du angiver en
binær kompatibilitet... Alle andre programmer anvender disse GUIDs som
reference til din DLL... ikke blot filnavn og placering.
Fremover (når du programmerer) vil du få en advarsel hvis du prøver at bryde
den binære kompatibilitet. Dette gør du hvis du ændrer eksisterende
unktioners interface, eller helt sletter dem.
Derfor: Sørg ALTID for (som udgangspunkt) at anvende binær kompatibilitet i
dine DLL'er.
/Carsten Suurland
| |
Christer Østergaard (14-01-2002)
| Kommentar
Fra : Christer Østergaard |
Dato : 14-01-02 14:38 |
|
Hey!
Tak for dit hurtige svar... jeg har findet stedet hvor jeg angiver binary
kompatibilitet, og glæder mig til at teste det... jeg har dog nogle
uddybende spørgsmål til det du skriver...:
"Carsten Suurland" <carsten@suurland.dk> wrote in message
news:lep08.14256$aS.1949238@news010.worldonline.dk...
[snip]
> Fremgangsmåden er følgende:
> Kompiler din DLL og lig den i et underbibliotek i din projektmappe.
> Gå derefter ind i DLL projektets egenskaber, find fanebladet hvorpå du kan
> angive kompatibilitet og sæt denne til binær kompatibilitet... sørg
samtidig
> for at du udpeger den DLL du lige har kompileret.
> Endeligt kompilerer du din DLL én gang til, denne gang ikke til det
> oprettede underbibliotek med til selve projektmappen.
> Den DLL der ligger i selve projektmappen, er den du skal distribuere.
> Den der ligger i undermappen er den der anvendes som reference i
forbindelse
> med den binære kompatibilitet.
Check! Den er jeg helt med på, men...
> Denne kan du opdatere efterhånden som du tilføjer nye funktioner til din
DLL.
Hvorfor og hvornår vil man det? Jeg mener, er det ikke ok, at man har den
allerførste udgave liggende? Eller vil man kopiere en senere udgave herned,
når man tillægger funktionalitet?
Jeg forstår det sådan, at jeg laver en 1.0 udgave og sender den ud. Når jeg
laver 1.x versioner (optimeringer mm., men ikke egentlig videreudvikling),
skal jeg lave binær kompatibilitet imod 1.0 versionen. Vil jeg på noget
tidspunkt kopiere en 1.x version ned i det underliggende bibliotek, og i
fremtiden lave reference til denne?
> Problemet opstår da der bliver tildelt nye GUIDs til din DLL (med
> underliggende klasser) hver gang du kompilerer med mindre du angiver en
> binær kompatibilitet... Alle andre programmer anvender disse GUIDs som
> reference til din DLL... ikke blot filnavn og placering.
Okie...
> Fremover (når du programmerer) vil du få en advarsel hvis du prøver at
bryde
> den binære kompatibilitet. Dette gør du hvis du ændrer eksisterende
> unktioners interface, eller helt sletter dem.
Men ikke når jeg tillægger nye funktioner? Og det er måske her, man vil lave
den nye version til den, som fremtidige versioner skal referere til?
> Derfor: Sørg ALTID for (som udgangspunkt) at anvende binær kompatibilitet
i
> dine DLL'er.
Allrighty... har du en reference til et sted på nettet, hvor jeg kan læse
noget om konkret design af dll'er? Konklusionen af ovenstående må jo alt
andet end lige være, at man skal være varsom når man designer interfaces til
en dll, og ikke bare slamkoder derudaf... det kan jo have indsnævrende
konsekvenser, hvis man ikke giver det lidt omtanke.
Tak for din hjælp!
Christer
| |
 Carsten Suurland (14-01-2002)
| Kommentar
Fra : Carsten Suurland |
Dato : 14-01-02 16:03 |
|
Hej Christer
> Hvorfor og hvornår vil man det? Jeg mener, er det ikke ok, at man har den
> allerførste udgave liggende? Eller vil man kopiere en senere udgave
herned,
> når man tillægger funktionalitet?
Det er ikke helt nok at have den første udgave liggende. Hver gang du
tilføjer til DLL'ens interface (dvs. tilføjer nye klasser eller rutiner) så
bør du opdatere den DLL der anvendes som reference. På den måde er du sikker
på at der altid refereres til en aktuel version og ikke noget gammelt...
ellers er du næsten lige vidt.
I forbindelse med design af DLLer m.v., så er den bedste kilde MSDN... det
vil sige de to-tre CD'er der fulgte med Visual Studio. Har du ikke dem (...
 så se at få fat i dem, og sørg for at installere hele pakken! IKKE kun
det til VB. Der står forholdsvis lidt om de mere spændende ting.
Ellers prøv på http://msdn.microsoft.com
/Carsten Suurland
| |
Christer Østergaard (14-01-2002)
| Kommentar
Fra : Christer Østergaard |
Dato : 14-01-02 16:32 |
|
"Carsten Suurland" <carsten@suurland.dk> wrote in message
news:rrC08.14374$aS.1966697@news010.worldonline.dk...
> Hej Christer
> Det er ikke helt nok at have den første udgave liggende. Hver gang du
> tilføjer til DLL'ens interface (dvs. tilføjer nye klasser eller rutiner)
så
> bør du opdatere den DLL der anvendes som reference. På den måde er du
sikker
> på at der altid refereres til en aktuel version og ikke noget gammelt...
> ellers er du næsten lige vidt.
Allright...
> I forbindelse med design af DLLer m.v., så er den bedste kilde MSDN... det
> vil sige de to-tre CD'er der fulgte med Visual Studio. Har du ikke dem
(...
> så se at få fat i dem, og sørg for at installere hele pakken! IKKE kun
> det til VB. Der står forholdsvis lidt om de mere spændende ting.
> Ellers prøv på http://msdn.microsoft.com
Den er jeg på...
Tak for hjælpen!
Christer
| |
Christer Østergaard (14-01-2002)
| Kommentar
Fra : Christer Østergaard |
Dato : 14-01-02 21:06 |
| | |
Tomas Christiansen (14-01-2002)
| Kommentar
Fra : Tomas Christiansen |
Dato : 14-01-02 22:51 |
|
Carsten Suurland skrev:
> Kompiler din DLL og lig den i et underbibliotek i din projektmappe.
....
> Den DLL der ligger i selve projektmappen, er den du skal
distribuere.
> Den der ligger i undermappen er den der anvendes som reference i
forbindelse
> med den binære kompatibilitet. Denne kan du opdatere efterhånden som
du
> tilføjer nye funktioner til din DLL.
Hvad er det lige at du opnår ved at lægge kopien af DLL'en et andet
sted (og referere til den) end dér, hvor nye DLL'er bliver dannet?
Jeg kan selvfølgelig se én ting: VB har det med selv "låse" DLL'en, så
man, hver gang man vil danne DLL'en påny, lige skal lukke projektet og
åbne det igen. Dette sker formentlig ikke, hvis man arbejder to på
kopier af DLL'en.
-------
Tomas
| |
Carsten Suurland (14-01-2002)
| Kommentar
Fra : Carsten Suurland |
Dato : 14-01-02 23:43 |
|
Hej Tomas
Det jeg bruger den ekstra dll til, er til mine "release-versioner".
Så når jeg laver en ny release af en dll, så sørger jeg for at opdatere min
reference dll.
På den måde ved jeg, at mine nye dll'er altid er kompatible med det kunderne
har.
Det giver mig en sikkerhed, da jeg hele tiden sammenligner med noget
kunderne har. Det vil jeg ikke gøre hvis jeg bare lavede en binær
kompatibilitet mod den samme dll som jeg kompilerede oveni.
/Carsten Suurland
| |
Tomas Christiansen (15-01-2002)
| Kommentar
Fra : Tomas Christiansen |
Dato : 15-01-02 00:07 |
|
Carsten Suurland skrev:
> Det jeg bruger den ekstra dll til, er til mine "release-versioner".
> Så når jeg laver en ny release af en dll, så sørger jeg for at
opdatere min
> reference dll.
> På den måde ved jeg, at mine nye dll'er altid er kompatible med det
kunderne
> har.
Okay. Jeg kan se pointen.
Gør man IKKE som du, kan man let gå hen at glemme, at man rent faktisk
har brudt den binære kompatibilitet for 5 (test) versioner siden.
Med din metode bliver man hele tiden (dvs. hver gang man genererer en
ny DLL) mindet om det, hvis den binære kompatibilitet er brudt.
Et udmærket lille trick, tak.
-------
Tomas
| |
|
|