[.Net] Overloads Functions zijn niet COM Visible

[F-Tim]

Aloha allemaal,

ik ben bezig met het schrijven van een DLL, echter moet deze DLL ook vanuit andere applicaties aan te roepen zijn. Om dit te realiseren moet ik mijn DLL dus Com compatible maken. Ik maak echter ook gebruik van Overloads en Shared functions. In .Net zie je dan dus bij het gebruik ervan "New() 1 of 3" staan als voorbeeld.... en dan kun je de gewenste parameters aangeven, en .Net selecteert de juiste functie of procedure.

Ik heb hiervoor gekozen omdat Optional parameters niet goed door C# gebruikt zouden kunnen worden. Vandaar deze overloads.

Echter zodra ik ze COM visible wil maken, dan staan deze procedures niet er tussen

Mijn vraag is nu, is het mogelijk om een overloaded (shared) function of procedure Com visible te maken of moet ik dan toch echt verschillende namen gaan gebruiken voor de functies en procedures? Google levert me nl. geen concreet antwoord of relevante informatie op.

[whoami]

Geef je die methods zelf een Guid ?

[H!GHGuY]

er staat in de MSDN duidelijk omschreven dat statische methoden niet over COM-exposed kunnen worden.

wat overloaded betreft zou'k de MSDN er zelf ook even op moeten naslaan.

Ook constructors met parameters zijn in COM niet toegestaan. Default contructor gebruiken dus.

[F-Tim]

whoami schreef op woensdag 19 april 2006 @ 17:22:
Geef je die methods zelf een Guid ?

De methods niet apart, maar de overkoepelende class wel. Dit werkt in zoverre dat ik de niet overloaded shared functions wel via COM kan aanroepen. De overloaded shared functions kan ik echter niet zo makkelijk aanroepen via COM

HIGHGuY schreef op woensdag 19 april 2006 @ 18:00:
er staat in de MSDN duidelijk omschreven dat statische methoden niet over COM-exposed kunnen worden.

wat overloaded betreft zou'k de MSDN er zelf ook even op moeten naslaan.

Ook constructors met parameters zijn in COM niet toegestaan. Default contructor gebruiken dus.

De constructors met Parameters worden ín een andere functie aangeroepen, dus niet via de Com interface. Bovendien is er ook een standaard constructor zonder parameters, wat dat betreft heb ik daar niet zo'n last van. Maar de functies die je dan wel gebruikt, hebben wel direct parameters.... en dan mag het wel gewoon (Om ff een idee te geven waarom de constructor niet echt nodig is vanuit de buitenwereld, dan is dat omdat dit gewoon een DLL is die kan communiceren met een NTP server, zodoende kan alles intern gehouden worden van constructors omdat de Socket toch niet nodig is in de hoofdapplicatie).