Jag vet att detta har varit inlägg om detta tidigare men jag är väl kanske lite trögtänkt.

Jag håller på med en applikation som innehåller ett huvudprojekt och till proj-gruppen är jag knutit mina 5 st ActiveX DLL'er. Om jag nu gör uppdateringar/ändringar i ActiveX projekten och kompilerar och därefter skickar uppdateringen (DLL'en) till min kollega som testkör applikationen får han ibland, inte alltid, fel liknande 'ActiveX Object can't create object' eller 'Class name not found'. Vad beror detta på?

Jag har 'Project Compability' inställt för ActiveX projekten. Är detta rätt eller är det bättre att använnda 'No Comp'/'Binary Comp'?

Min kollega har inte VB installerat och applikationen är installerad via setup från P&D manager.

Om du kompilerara om en dll får du inte förändra några av klassernas gränssnitt för att behålla binär kompabilitet. Binär kompabilitet krävs om existerande kompilerade exe skall fungera med en dll kompilerad efter att exe är kompilerad.

OK. Låt säga att jag ändrar antal värden jag ska skicka med till dll'en då bibehåller inte binär kompabilitet och måste jag kompilera om både exe och dll i den ordningen?

När används project kompabilitet?

//Fredrik

Om jag inte är helt ute och cyklar så kommer varje ny kompilering vid "no compatibility" resultera i en "ny" dll, den får unika egenskaper. Varje COM-DLL har ju en unik GUID som ligger lagrad någonstans i registret och denna genereras om varje gång och DLL-erna kommer att betraktas som olika.

Projektkompatibiliteten bevarar detta GUID mellan kompileringarna. Det får effekten att man i ett större utvecklingsteam får mycket färre referensproblem om alla har samma kompatibilitetsfil (eftersom detta GUID lagras i VBP:erna). Project Compatibility resulterar säkert också i mindre skräp i registret.

Binärkompatibilitet är nog det du är ute efter, och om jag minns rätt så tillåts det faktiskt en del förändringar så länge förändringarna görs i slutet av filen. Däremot får du inte ändra på signaturen hos en befintlig publik funktion. Skapa i stället en ny funktion och lägg den sist. Jag är inte hundra på detta men jag vill minnas att jag testade detta en gång.

För din del så behöver du antingen köra med binärkompatibilitet, eller alltid kompilera om både exe-filen och dll:erna. Slutligen har du ju alternativet att köra late-bound så försvinner problemet.

Jag testar med binär kompabilitet.
Tackar för hjälpen!

Om du ändrar bar värden. T.Ex. Konstanter, strängar kod inuti funktioner i klasser och sånt kommer den att bibehålla binär kombabilitet.

Däremot om du t.ex. ändrar argument på en class lägger till och tar bort metoder och egenskaper, som är del av det gränssnitt din dll exponenra, som det påverkas.

Hur funkar det med registreringen av dll-filer. Dom registreras vid installationen men därefter är det fritt fram att lägga till nya klasser så länge man bibehåller den binära kompabiliteten genom att kompilera om?

Du bibehåller den binära kompabiliteten genom att inte förändra befintliga klasser's gränssnitt. Vet inte om du kan lägga till klasser och behålla binära kompabilitet.

Tanken med binär kompabilitet är att redan skriven kod garanterat skall fungera. Alltså borde man kunna utöka klasser och lägga till klasser utan problem, så länge man inte gör någon förändring av det redan befintliga gränssnitttet.

Hej..

Man inte bara "bör kunna"... Man kan! Niklas har helt rätt...
Det jag däremot märkt är att om man kompilerar om på en annan maskin kan denna kompabilitet brytas... Fastän man har den kompatibla dll:en registrerad på "rätt plats".

Lurigt, lurigt...

Ja GUIDn är stark. Den kollar exakt tid, några serienummer och lite sånt.

Jag har fått rekommendationen att inte referera till den registrerade DLL:en som kompatibilitetsfil, utan att i stället ta en kopia på den, döpa om den till *.cmp (eller något annat) och sen spara den i samma mapp som vbp:n (även i SourceSafe). Fast jag vet inte VARFÖR jag gör så :-)

Jag får alltid det meddelandet när mina dll:er inte registrerats korrekt...

Även om du registrerat en tidigare version av samma dll så räcker det inte med att lägga dit en ny version på samma plats utan den måste också registreras korrekt.

På det företag jag jobbar är det ibland ute hos kund problem med registreringen av
dller via installationsprogram och de måste då registrera dllen manuellt och då försvinner felmeddelandet.

Detta gäller även om det är binärkompabilitet mellan versionerna...

...och avregistrera alltid den gamla DLL:en innan ni registrerar den nya, så slipper ni problem och skräp i registret.
<code>
regsvr32 /u [filename]
</code>

Finns det inte möjlighet att skapa en setup.exe i t.ex P&D manager som enbart installerar (registrerar) aktuell dll och samtidigt ser till att ev. befintlig dll avregistreras innan.

//Fredrik