Hvala na linku, no nije mi baš od pomoći. Znam za OpenCV.NET no on mi je beskoristan s obzirom na ograničenje funkcija koje daje.

Kao sto je taj student napravio svoj managed C++ wrapper za OpenCV, tako ces i ti morati da napravis sebi (sem ako neko to vec nije uradio) preslikavajuci sve funkcije koje ti trebaju. Nazalost ne mozes da napravis wrapper direktno iz C#-a jer interop radi samo sa COM bibliotekama i ne ume da pretoci C++ .h i .lib u upotrebljivi assembly. To radi managed C++ koji moze da se linkuje za unmanaged code sa jedne strane a da publikuje .NET assembly metadata sa druge.

E, cek :)
Da li to znaci da je moguce napraviti neku vrstu proxy dll-a? Ovako nesto:
Winamp ima podrsku za plugin-ove i potrebno je da taj plugin bude .dll koji ima odredjene c++ funkcije (kao Win32 API).
E sad, da bih izbegao rad u c++u, ja bih da napravim Plugin.dll koji je .net class library i koji bih radio u vb.net/c# i tu sve sto treba i jedan Proxy.dll koji ce biti u c++u a koji ce samo da prosledjuje pozive / vraca vrednosti izmedju Winamp-a i Plugin.dll-a

Sorry na offtopic-u, ali vec sam postavljao pitanje o tome ali niko mi nije odgovorio nista konkretno...

^ Mislim da je mmix pisao za obrnuti slucaj, kada unmanaged uvlacis u managed ali da nije COM, znaci native dll, sa C++-om. Inace pitanje je dosta interesantno, ne znam da li postoji neko resenje ali pretpostavljam da ako bi moglo da se resi onda bi opet bio C++ upitanju, samo ne znam da li je moguce raditi sa C++/CLI a da se kompajlira native dll.

Zapravo, moguce je i obrnuto kroz .NET tehnologiju koja se zove "thunking" koju managed C++ koristi svaki put kad switchuje kontekst iz unmanaged u managed. U principu C++ kompajler napravi "thunk" pred-funkciju koja obavlja switch za sve managed metode/funkcije koje se pozivaju iz unmanaged koda i za sve dllexport funkcije. ako je dllexport onda jos adresu tog thunk-a stavi u DLL exports



Ovo parce koda je preuzeto iz Can DLLs export managed functions to native clients? gde ima malo pojasnjeno i data neka ogranicanje koriscenja ove tehnologije.

Hah, nadjoh, ovako nesto mi je trebalo - http://support.microsoft.com/default.aspx/kb/828736 samo sto mi treba .dll a ne .exe, ali taj je princip.
S' tim da nisam mislio da ide preko COM-a, ali ako u MS-u kazu tako, valjda ne moze direktno.
Samo ne znam je l' neophodan ovaj strong name...

PS. prebacicu kasnije ove offtopic poruke u temu koju sam prvobitno kreirao za ovo jos ranije (samo da je nadjem ).

Jesi probao nacin sa ovog linka koji sam okacio?

COM je moguc i verovatno preporucen od MS-a (iz prostog razloga sto je jedini nacin na koji se exportuje metadata u tlb), ali sigurno nije jedini nacin.

Nisam, jer koliko vidim, on samo koristi managed code u toj funkciji a ne poziva iz managed .dll-a (il' nesto bas nije u redu sa mojim vidom) a ja blage veze nemam kako se to poziva (to je ono sto i pitam jelde :)). Posle bih to samo koristio kao sablon i menjao imena funkcija.

Kao sto zove Console.WriteLine tako moze da zove i tvoje managed funkcije.

Pazi, managed DLL ne postoji, to je jos jedna zbunjujuca zabluda koju MS siri naokolo. Svi DLLovi su unmanaged i njihova struktura se nije menjala od pamtiveka, samo sto pure C# DLL na primer nema native exporte u sebi vec ima samo metadata blok. Nista u strukturi DLLa te ne sprecava da imas i native exporte i managed metadata block, i onda imas dva scenarija:

1. Kad DLL vezujes iz native klijenta (npr kad se WinAmp kaci na njega) vidi native DLL exporte a ignorise managed metadata jer ne zna sta bi sa njima radio
2. Kad DLL vezujes iz managed klijenta (npr VB.NET ili C#) onda klijent vidi managed metadata a ne vidi native exporte jer ne zna sta bi sa njima
3. Kad DLL vezujes iz managed C++-a vidis oba

mmix i ja smo se dogovorili da zajedno napravimo primer ovog. Ja sam (naravno) uradio laksi deo - .net class library:


Kompajlirani dll je u attachment-u.

Ok, eve ga

Prikacen je solution sa tri projekta:
- FirstManagedVB sa datom klasom, cist managed code
- SecondNativeWrapper - pomenuti wrapper koji marshaluje pozive od native pozivara u gornju managed klasu
- ThirdNativeCaller - mala C++ aplikacija, Win32 native koja se kaci na SecondNativeWrapper.dll i poziva Add(int, int)

Ako se pogleda exports sekcija SecondNativeWrapper.dll vidi se da ima native export iako je managed C++
[att_img]

Dumpbin prijavljuje export u SecondNativeWrapper.dll:


Dumpbin prijavljuje taj export kao import za ThirdNativeCaller.exe


Kad pozoves Win32 aplikaciju, ona lepo podigne wrapper, koji podigne .NET klasu i sabere brojeve:


voila..

Perfect !