[ASP.NET] Probleempje met IO.DLL

[Gurbe de n00b]

Hallo Tweakers,

Ik ben bezig met een kleine webpagina waarmee je een printerpoort kan aansturen;

Nou heb ik het volgende gevonden:
http://www.geekhideout.com/iodll.shtml

En ik heb het gedownload en ik heb de io.dll in mijn bin map geplaatst.
Maar nu lukt het maar niet om die aan de praat te krijgen, Ik krijg contant de error:
Unable to load DLL 'io.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

Ik gebruik Microsoft Visual Web Developer.

Ik gebruik gewoon het bijbehoorende stukje code:

code:

Private Declare Sub PortOut Lib "IO.DLL" (ByVal Port As Integer, ByVal Data As Byte)
Private Declare Sub PortWordOut Lib "IO.DLL" (ByVal Port As Integer, ByVal Data As Integer)
Private Declare Sub PortDWordOut Lib "IO.DLL" (ByVal Port As Integer, ByVal Data As Long)
Private Declare Function PortIn Lib "IO.DLL" (ByVal Port As Integer) As Byte
Private Declare Function PortWordIn Lib "IO.DLL" (ByVal Port As Integer) As Integer
Private Declare Function PortDWordIn Lib "IO.DLL" (ByVal Port As Integer) As Long
Private Declare Sub SetPortBit Lib "IO.DLL" (ByVal Port As Integer, ByVal Bit As Byte)
Private Declare Sub ClrPortBit Lib "IO.DLL" (ByVal Port As Integer, ByVal Bit As Byte)
Private Declare Sub NotPortBit Lib "IO.DLL" (ByVal Port As Integer, ByVal Bit As Byte)
Private Declare Function GetPortBit Lib "IO.DLL" (ByVal Port As Integer, ByVal Bit As Byte) As Boolean
Private Declare Function RightPortShift Lib "IO.DLL" (ByVal Port As Integer, ByVal Val As Boolean) As Boolean
Private Declare Function LeftPortShift Lib "IO.DLL" (ByVal Port As Integer, ByVal Val As Boolean) As Boolean
Private Declare Function IsDriverInstalled Lib "IO.DLL" As Boolean

Hebben jullie enig idee wat ik fout doe ?

Alvast bedankt,

[mistercash]

Denk wel dat je een deel over het hoofd ziet.
Client side een dll aanroepen moet je met axtivex doen.

Ook zal je denk ik die dll moeten importen in uw pagina. Iets van Imports ofzo

[TeeDee]

Zit te denken aan een Imports System.Runtime.Interop.
Desnoods nog een [DLLImport "IO.dll" .... etc.]

Edit:
Heb je het .dll bestand ook als Reference toegevoegd? Afaik is het alleen kopieren van een .dll naar je bin niet voldoende.

[ Voor 75% gewijzigd door TeeDee op 30-03-2006 16:49 ]

[Gurbe de n00b]

mistercash schreef op donderdag 30 maart 2006 @ 16:33:
Denk wel dat je een deel over het hoofd ziet.
Client side een dll aanroepen moet je met axtivex doen.

Ook zal je denk ik die dll moeten importen in uw pagina. Iets van Imports ofzo

Het moet juist server side zijn =)

Ik wil er graag een station van maken die alles regelt in de kamer.
(Via de printerport relais aansturen die dan weer wat anders activeren)

Import is voor bestaande namespaces. (toch¿)

[Gurbe de n00b]

TeeDee schreef op donderdag 30 maart 2006 @ 16:39:
Zit te denken aan een Imports System.Runtime.Interop.
Desnoods nog een [DLLImport "IO.dll" .... etc.]

Edit:
Heb je het .dll bestand ook als Reference toegevoegd? Afaik is het alleen kopieren van een .dll naar je bin niet voldoende.

Hallo TeeDee,

Bedankt voor je reactie.

Kun je dat misschien nog een beetje toelichten ?
Ik ben nu druk aan het google'en op Imports System.Runtime.Interop.

Edit:
Nu krijg ik dat io.dll geen libary bevat...

Eerst even een goede libery opzoeken...

[ Voor 14% gewijzigd door Gurbe de n00b op 30-03-2006 17:00 ]

[MrBucket]

TeeDee schreef op donderdag 30 maart 2006 @ 16:39:
Zit te denken aan een Imports System.Runtime.Interop.
Desnoods nog een [DLLImport "IO.dll" .... etc.]

Edit:
Heb je het .dll bestand ook als Reference toegevoegd? Afaik is het alleen kopieren van een .dll naar je bin niet voldoende.

Nee, je hebt geen interop nodig, want het is geen ActiveX / COM-dll, maar een gewone Win32 DLL.

Uit de link van de OP:

Simply link to the DLL and call the functions. It's that easy.
...
C/C++ Prototypes
void WINAPI PortOut(short int Port, char Data);
void WINAPI PortWordOut(short int Port, short int Data);
void WINAPI PortDWordOut(short int Port, int Data);
(...)

Aan PInvoke moet je genoeg hebben (da's met het DllImport-attribuut). Bijvoorbeeld voor PortOut:

Visual Basic .NET:

<DllImport("IO.DLL", CallingConvention := CallingConvention.StdCall)> _
Public Shared Sub PortOut(Port As Int16, data As Char)
    ' Leave function empty - DLLImport attribute forwards calls to PortOut to
    ' PortOut in IO.DLL.
End Sub

De dll moet dan wel in dezelfde directory als je executable staan (of bijv. in je windows\system32 folder)

[ Voor 22% gewijzigd door MrBucket op 30-03-2006 19:30 ]

[Gurbe de n00b]

Bedankt MrBucket,

Het wil nu

Alleen nu zit ik even te kijken naar de functies, want die geven een waarde terug...

Hoe moet je dat aangeven dan ?

[MrBucket]

U vraagt, wij draaien

Zoals je misschien al hebt gezien hoef je bij het gebruik van het DllImport-attribuut alleen maar een methode-declaratie op te geven; je hoeft 'm niet daadwerkelijk te implementeren (want dat laat je aan de dll over). Het hele eieren eten zit 'm dus in het correct vertalen van elk datatype die in een method wordt gebruikt.

In je openingspost heb je de VB6-declaraties al aangegeven, maar aangezien de datatypes in .NET vaak net even anders heten, kun je het beste de C++ declaraties bekijken (let er wel op dat in c++ de returnwaarde als eerste wordt genoemd; als er 'void' staat, gaat het om een Sub ipv een Function), en de volgende vertaling maken :

code:

C++          VB.NET
char      -> Char
short int -> Int16
int       -> Int32

Bijvoorbeeld:

C++:

int WINAPI PortDWordIn(short int Port);

wordt in VB.NET:

Visual Basic .NET:

<DllImport("IO.DLL", CallingConvention := CallingConvention.StdCall)> _ 
Public Shared Function PortDWordIn(Port As Int16) As Int32
End Function

[H!GHGuY]

even een aanmerking die wsch niet belangrijk is:
.NET gebruikt UNICODE char's die 16bit zijn in tegenstelling tot de 8bit van C++

[MrBucket]

HIGHGuY schreef op vrijdag 31 maart 2006 @ 19:40:
even een aanmerking die wsch niet belangrijk is:
.NET gebruikt UNICODE char's die 16bit zijn in tegenstelling tot de 8bit van C++

Daar zeg je wat... je hebt gelijk, eigenlijk moet je voor de C++ 'char' het .NET-type "Byte" gebruiken, die is wel 8 bits.

De Char-returnwaarden van je DLL-methods kunnen mogelijkerwijs wel verkeerd zijn, omdat .NET verwacht 16 bits aan geldige data in een register te vinden, terwijl de DLL er maar 8 heeft gezet; de andere 8 bits bevatten dan waarschijnlijk nog rommel van eerdere operaties.

[Gurbe de n00b]

Alles lijkt nu te werken,

Alleen als ik het volgende script uitvoer:

Visual Basic .NET:

    'Subroutine 1
    <DllImport("IO.DLL", CallingConvention:=CallingConvention.StdCall)> _
    Public Shared Sub PortOut(ByVal Port As Int16, ByVal data As Char)
        ' Leave function empty - DLLImport attribute forwards calls to PortOut to 
        ' PortOut in IO.DLL. 
    End Sub
    
    'Subroutine 2
    <DllImport("IO.DLL", CallingConvention:=CallingConvention.StdCall)> _
    Public Shared Sub PortWordOut(ByVal Port As Integer, ByVal Data As Integer)
        ' Leave function empty - DLLImport attribute forwards calls to PortOut to 
        ' PortOut in IO.DLL. 
    End Sub
    
    'Subroutine 3
    <DllImport("IO.DLL", CallingConvention:=CallingConvention.StdCall)> _
    Public Shared Sub PortDWordOut(ByVal Port As Integer, ByVal Data As Long)
        ' Leave function empty - DLLImport attribute forwards calls to PortOut to 
        ' PortOut in IO.DLL. 
    End Sub
    
    'Functie 4
    <DllImport("IO.DLL", CallingConvention:=CallingConvention.StdCall)> _
    Public Shared Function PortIn(ByVal Port As Integer) As Byte
        ' Leave function empty - DLLImport attribute forwards calls to PortOut to 
        ' PortOut in IO.DLL. 
    End Function
    
    'Functie 5
    <DllImport("IO.DLL", CallingConvention:=CallingConvention.StdCall)> _
    Public Shared Function PortWordIn(ByVal Port As Integer) As Integer
        ' Leave function empty - DLLImport attribute forwards calls to PortOut to 
        ' PortOut in IO.DLL. 
    End Function
    
    'Functie 6
    <DllImport("IO.DLL", CallingConvention:=CallingConvention.StdCall)> _
    Public Shared Function PortDWordIn(ByVal Port As Integer) As Long
        ' Leave function empty - DLLImport attribute forwards calls to PortOut to 
        ' PortOut in IO.DLL. 
    End Function

    'Subroutine 7
    <DllImport("IO.DLL", CallingConvention:=CallingConvention.StdCall)> _
    Public Shared Sub SetPortBit(ByVal Port As Integer, ByVal Bit As Byte)
        ' Leave function empty - DLLImport attribute forwards calls to PortOut to 
        ' PortOut in IO.DLL. 
    End Sub
    
    'Subroutine 8
    <DllImport("IO.DLL", CallingConvention:=CallingConvention.StdCall)> _
    Public Shared Sub ClrPortBit(ByVal Port As Integer, ByVal Bit As Byte)
        ' Leave function empty - DLLImport attribute forwards calls to PortOut to 
        ' PortOut in IO.DLL. 
    End Sub
    
    'Subroutine 9
    <DllImport("IO.DLL", CallingConvention:=CallingConvention.StdCall)> _
    Public Shared Sub NotPortBit(ByVal Port As Integer, ByVal Bit As Byte)
        ' Leave function empty - DLLImport attribute forwards calls to PortOut to 
        ' PortOut in IO.DLL. 
    End Sub

    'Functie 10
    <DllImport("IO.DLL", CallingConvention:=CallingConvention.StdCall)> _
    Public Shared Function GetPortBit(ByVal Port As Integer, ByVal Bit As Byte) As Boolean
        ' Leave function empty - DLLImport attribute forwards calls to PortOut to 
        ' PortOut in IO.DLL. 
    End Function
    
    'Functie 11 
    <DllImport("IO.DLL", CallingConvention:=CallingConvention.StdCall)> _
    Public Shared Function RightPortShift(ByVal Port As Integer, ByVal Val As Boolean) As Boolean
        ' Leave function empty - DLLImport attribute forwards calls to PortOut to 
        ' PortOut in IO.DLL. 
    End Function
    
    'Functie 12
    <DllImport("IO.DLL", CallingConvention:=CallingConvention.StdCall)> _
    Public Shared Function LeftPortShift(ByVal Port As Integer, ByVal Val As Boolean) As Boolean
        ' Leave function empty - DLLImport attribute forwards calls to PortOut to 
        ' PortOut in IO.DLL. 
    End Function
    
    'Functie 13
    <DllImport("IO.DLL", CallingConvention:=CallingConvention.StdCall)> _
    Public Shared Function IsDriverInstalled() As Boolean
        ' Leave function empty - DLLImport attribute forwards calls to PortOut to 
        ' PortOut in IO.DLL. 
    End Function
    
    Sub page_load(ByVal sender As Object, ByVal e As EventArgs)
        label1.text = PortIn(378).ToString
    End Sub

Dan krijg ik een *tuut* uit de webserver en het script dat blijft gewoon altijd "laden".
Je krijgt geen error, maar ook niet de pagina.

Ook heb ik meerdere functie en routines geprobeerd, maar allemaal helaas hetzelfde resultaat.

In de event viewer is verder niets terug te vinden wat er mee te maken zou kunnen hebben.

Als ik geen subroutine of functie aanroep uit de DLL dan laadt de pagina gewoon prima, maar als ik iets aanroep dan loopt het script vast...

_{<offtopic>
Ik heb nu het printje ook klaar, en met parmon kan ik hem nu aansturen}

[ Voor 7% gewijzigd door Gurbe de n00b op 31-03-2006 21:24 ]

[_Thanatos_]

Even een zijnootje: .NET 2.0 heeft een component SerialPort. Als je de seriële poort dus wil gaan gebruiken, kan dit componentje je heel wat werk schelen... Andere poorten doet .NET helaas niet zelf.

[MrBucket]

Gurbe de n00b schreef op vrijdag 31 maart 2006 @ 21:24:
Alles lijkt nu te werken,

Alleen als ik het volgende script uitvoer:
(...)
Dan krijg ik een *tuut* uit de webserver en het script dat blijft gewoon altijd "laden".
Je krijgt geen error, maar ook niet de pagina.

Ook heb ik meerdere functie en routines geprobeerd, maar allemaal helaas hetzelfde resultaat.

In de event viewer is verder niets terug te vinden wat er mee te maken zou kunnen hebben.

Als ik geen subroutine of functie aanroep uit de DLL dan laadt de pagina gewoon prima, maar als ik iets aanroep dan loopt het script vast...

Blijkbaar werkt het dan toch niet he

Nu is debuggen aan de hand van asp.net niet echt ideaal, omdat je niet precies kunt zien wat er verkeerd gaat. Wat je zou kunnen doen:
- Plaats een breakpoint op de eerste regel code waarin je een aanroep doet naar 1 van de dll-functies. Start je asp.net-project met F5 (of via het menu: debug / start), als het goed is krijg je een nieuw browser-venster te zien met jouw pagina erin. Op het moment dat de regel code op de breakpoint op het punt staat uitgevoerd te worden, keer je weer terug in visual studio en kun je stapsgewijs door de code 'tracen' om te kijken wanneer het vastloopt (met de functies uit het debug-menu: step over, step into, step out*)
- Maak een nieuw console-project aan waarin je de dll gebruikt, en kijk of je programma normaal afsluit. Console-projecten lenen zich over het algemeen goed voor debuggen omdat het gewoon recht-toe recht-aan code uitvoert (en je niet afhankelijk bent van events e.d.).

Kijk ook eens wat de functie IsDriverInstalled teruggeeft. Van wat ik zo uit de documentatie van de dll haal, is dat als je Windows NT/2000/XP draait, dat deze functie 'true' moet teruggeven.

_{* Als dit verhaal (debuggen) nieuw voor je is, is het zeker de moeite waard om er even mee te spelen (al dan niet met gebruik van de dll-functies). Een programma kunnen debuggen is een van de handigste manieren om fouten te ontdekken}

[Gurbe de n00b]

Bedankt voor je reactie,

Nu heb ik even zitten te proberen,
maar ik krijg op mijn eigen pc (WinXP) wel alles juist te zien in de debug mode (F5)

En op mijn server (windows2003) gaat het helemaal verkeerd.

Zou het kunnen zijn dat de dll gewoon incompatble is met het bestuurings systeem ?

[MrBucket]

Gurbe de n00b schreef op zaterdag 01 april 2006 @ 23:17:
Bedankt voor je reactie,

Nu heb ik even zitten te proberen,
maar ik krijg op mijn eigen pc (WinXP) wel alles juist te zien in de debug mode (F5)

En op mijn server (windows2003) gaat het helemaal verkeerd.

Zou het kunnen zijn dat de dll gewoon incompatble is met het bestuurings systeem ?

Wat debug je, een console application of een asp.net pagina? Voor asp.net pagina's spelen er ook een aantal rechten-issues mee (die ik zo snel niet uit m'n hoofd weet), terwijl je bij console applications dit probleem niet hebt. Dus ik kan je aanraden om het iig uit te proberen in een console application, dan weet je zeker dat als het onder WinXP wel werkt en onder Win2k3 niet, dat het aan de dll moet liggen.

[Gurbe de n00b]

Aan die rechten zit ik nu ook net te denken.

Debuggen -> F5 ¿? toch ?