C#: Regasm,GAC,C++,.C# NET,VB 6.0 referanser :)

[OleM80]

Hadde tidligere en tråd der jeg jobbet med å lage en C++ CLR wrapper mot en C++ ABI dll. Med en C# dll på toppen som jobbet mot C++ wrapperen. Dette gjorde jeg for å aksessere en native C++ dll fra C#.

(Tråden her: https://www.diskusjon.no/index.php?showtopic=1253182)

 

Så langt har alt gått fint.

 

Helt på toppen skal jeg nå ha en eldre VB 6.0 applikasjon som skal bruke C# dllen. I dag brukes denne C# dllen fra VB 6.0 ved:

1. Kompilere C# dllen med COM støtte og strong key
   
2. Registrere C# dllen i GAC med gacutil
   
3. Kjøre regasm på C# dllen for å lage TLB fil til VB 6.0 applikasjonen
   
4. Registrere og bruke komponenten i VB 6.0
   

Dette er også måten vi har gjort det på ved andre komponenter da jeg har en eldre VB 6.0 applikasjon som ikke kan fases ut så legger jeg til nye komponenter utviklet i C#.Net

 

(Med fare for å gjenta meg selv her Så er avhengighetsrekken slik

C++(Native, ABI grensesnitt) - C++(CLR støtte) - C# - Visual Basic 6.0)

Problemet er at native dllene ikke kan registreres i GAC mens C# dllene må (?) registreres i GAC for at de skal kunne brukes fra VB 6.0 applikasjonen

 

Merk at jeg også har forsøkt å legge C# dller i VB 6.0 programmets exe katalog. Dette fungerer ikke og ut fra hva jeg har lest meg frem til må dllene legges i GAC.

 

Ser for meg at det må finnes en lur løsning på problemet. Kan .Net dllene (som legges i GAC) kanskje referere til native dllene på annet vis? Så kan heller disse legges i en annen katalog?

 

Har en følelse av at en viss flittig ildsjel her inne har svaret på nettopp dette

[GeirGrusom]

Er det meg du tenker på?

Vel, etter det jeg vet er GAC til å registrere moduler som skal brukes på tvers av mange forskjellige programmer. Dette skal ikke egentlig være nødvendig for deg hvis .NET DLL-ene samles sammen med .exe filen som bruker dem.

 

Mulig jeg tar feil dog for jeg har aldri forsøkt dette som du driver med nå.

Du kan jo også lage en wrapper rundt VB6 programmet istedet for å gjøre det andre veien (altså wrappe .NET DLL-er i VB6) så vil jo ihvertfall oppførselen være som vanlig.

 

Men dette med GAC kan også ha noe med sikkerhet å gjøre, så sjekk om noen policies er relevante for COM->.NET overgangen.

[OleM80]

Er det meg du tenker på?

Vel, etter det jeg vet er GAC til å registrere moduler som skal brukes på tvers av mange forskjellige programmer. Dette skal ikke egentlig være nødvendig for deg hvis .NET DLL-ene samles sammen med .exe filen som bruker dem.

 

Mulig jeg tar feil dog for jeg har aldri forsøkt dette som du driver med nå.

Du kan jo også lage en wrapper rundt VB6 programmet istedet for å gjøre det andre veien (altså wrappe .NET DLL-er i VB6) så vil jo ihvertfall oppførselen være som vanlig.

 

Men dette med GAC kan også ha noe med sikkerhet å gjøre, så sjekk om noen policies er relevante for COM->.NET overgangen.

 

hehe Var nok en viss Grusom jeg håpte skulle svare. Du har en tendens til å løse problemene mine kjapt Og setter veldig pris på det!

 

Skjønte ikke helt hva du mente med å wrappe i VB 6.0. Så vidt jeg vet så MÅ de dllene ligge i GAC ved bruk av TLB filer. Dette er ihvertfall det jeg har lest meg frem til så langt. Og har har også verifisert dette gjennom enkle testprogram. I så fall vil jo en ny VB 6.0 dll (VB 6.0 wrapper som du nevner også måtte laste disse fra GAC.

 

Imidlertid kom jeg på en alternativ løsning som jeg håper løser problemet(skal teste dette i morgen)

• C++ APIet, C++ wrapperen, samt en generisk C# dll legger jeg i en mappe i et sted på PCen jeg vet banen til.
  
• C# dllen implementerer et interface fra en dll jeg registrerer i GAC. Denne dllen lastes og refereres i VB 6.0
  
• C# dllen i GAC inneholder generiske klasser og interfacer et sett "providere" skal implementere. Blant annet C# dllen i første punkt. Disse skal bygge opp modellstrukturer i generelle klasser. Hver provider har støtte for en spesiell type filer. I dette tilfellet C++ APIet
  
• C# dllen i GAC laster C# dllen i første linje via reflection da den får vite stien til hvor APIet og wrapperen etc ligger. Instansiere objectene den trenger via reflection og caster disse til et interface den har liggende i sin egen dll. GJennom dette er hele C# provideren, c++ wrapperen og C++ APIet løskoblet og lastes dynamisk ved bruk. Tror dette kan være en fin løsning. I tillegg blir programmet veldig løst og fint koblet.
  

 

SKal gi beskjed når jeg har testet i morgen om dette fungerer

[OleM80]

Jeg nærmer meg men fremdeles litt småproblemer men som jeg tror er mer håndterbare for de med litt mere C++ erfaring.

 

Slik fungerer det nå.

 

VB6.0 kaller C# dll i GAC. C# dll instansierer C# dll i en "vanlig" katalog på PCen via reflection(so far so good).

 

C# dllen i denne katalogen skal laste C++ wrapperen som igjen er koblet mot C++ ABI dllen.

 

Hvis jeg lar være å registre C# dllen i GAC og kjører den som en exe fil som gjør alt over med reflection etc så går alt fint.

 

Hvis jeg bruker den som en dll i GAC via VB 6.0 applikasjonen går alt bra til og med instansieringen via reflection i "katalog" dllen. Men da krasjer programmet når jeg skal bruke C++ biblioteket.(Slik tolker jeg det ihvertfall)

"Could not load assembly xxxxxxx or one of its dependencies"

"Exception from HRESULT:0x800736B1"

 

Det jeg antar er at når den kjøres fra VB6 så blir det noe kluss med hvor den leter etter C++ dllene av en eller annen grunn.

 

Har prøvd å legge dllen i:

• Samme mappe som selve provideren i den løse katalogen(dette fungerer når jeg kjører "hoved" dllen som en exe fil)
  
• Exe katalogen til hovedprogrammet
  
• System32(ikke spør hvorfor )
  

 

Antar problemet kan leses med å sette noe innstillinger en plass eller register innstillinger eller noe. Men vet ikke helt hvor jeg skal starte.

 

Programmet fungerer men bare i gitte settinger og det virker som om den prøver å laste dller fra feil plass av en eller annen grunn.

[OleM80]

Glem det jeg skrev over.

 

Problemet er KUN C++ relatert og noe jeg har gjort galt ved kompilering. Har laget et enkelt program som bruker C++ dllen uten GAC og uten bruk av reflection.

 

Programmet fungerer fint på utviklings PC men krasjer på alle andre PCer.

Får "Exception from HRESULT:0x800736B1"

og på en Vista PC får jeg at "programmets sidestillingskonfigurasjon er feil"

 

Nå må jeg da nærme meg Tipper Geir Grusom kjenner til et eller annet jeg må sette opp i prosjektinnstillingene

[OleM80]

Glem det jeg skrev over.

 

Problemet er KUN C++ relatert og noe jeg har gjort galt ved kompilering. Har laget et enkelt program som bruker C++ dllen uten GAC og uten bruk av reflection.

 

Programmet fungerer fint på utviklings PC men krasjer på alle andre PCer.

Får "Exception from HRESULT:0x800736B1"

og på en Vista PC får jeg at "programmets sidestillingskonfigurasjon er feil"

 

Nå må jeg da nærme meg Tipper Geir Grusom kjenner til et eller annet jeg må sette opp i prosjektinnstillingene

 

Fungerer tydeligvis å prate med seg selv

 

Langt om lenge fant jeg ut at jeg manglet Visual C++ 2008 redistributable package! Hallelujah

[GeirGrusom]

Hehe. Jeg hadde ikke egentlig mer å komme med.

Men fint du fikk det til da.