Programming modem call ups over rs232 with VB.NET

[Kurt]

The program I m writting needs to call up several devices, on certain moments in time, to collect data thats stored in an SQL database. I found a .dll on the net that gives me the possibilty to open a serial port, and to put data to and get data from it, but this .dll goes in the mist every now and then, resulting in errors where no source is available for. Any idea when microsoft will develop a mscomm - alike control for the .NET environment? I would really appreciate a lot any kind of help/information ...

Kurt

 

[Kurt]

Anyone knows a possiblility to use the old mscomm object from vb 6.0 in .NET?

 

[Divil]

A quick Google search yielded two promising results:

http://msdn.microsoft.com/library/d...dnvssamp/html/vbcs_usingthecomportinvbnet.asp

http://msdn.microsoft.com/msdnmag/issues/02/10/NETSerialComm/default.aspx

 

[Kurt]

I found these two pages before, but they are not really satisfying. The best results are actually obtained by installing vb 6.0 and then adding a refference to the mscomm32.ocx ActiveX in the .NET project. I know serial ports are dated technologie, but a lot of industrial devices use them and I really think its a shame Microsoft didnt create a comparable managed class for the .NET framework until now.

 

[Divil]

Those two urls were just a selection of lots that you could put together to figure out how to make your own component. That would be a greal deal better than using an ActiveX control.

 

[Kurt]

I got pretty good results for the moment, but one question: The application runs on my machine because the installation of VB6.0 gave me a developers license for the mscomm32 ActiveX control. On machines where VS6.0 is not installed, the application causes a run time error because the ActiveX isnt licensed runtime. Anyone knows a way to solve this problem? Time issues make it impossible for me to start figuring out about creating my own component.

 

[Divil]

Running the application shouldnt be a problem, mscomm shouldnt require licensing except at design time. Are you sure its not that you havent distributed the ocx and registered it properly? That would be the most likely cause.

 

[Kurt]

Could you give me a short overview of how to do that divil? In the deployment project I used the ocx is mentioned under the detected dependencies. Is there more to do for registrating it on the target machine?
Under the detected dependencies, also scrrun.dll is mentioned. When I build the solution I get a message that I should exclude the scripting runtime dll because its source file is under windows system file protection. Maybe my licensing problem was caused rather by this?

 

[Divil]

Its possible, but unlikely. I have no idea why you have a dependancy on the scripting runtime, you should certainly not be using it in a .NET application.

Im surprised that the mscomm.ocx file was detected at all by your setup and deployment project - Ive never had it find ActiveX controls properly. Still, if it is, well done you Select the file, and in the propertygrid, look at the Register property. I think this should be on COMSelfRegister for ActiveX controls.

 

[Kurt]

Thats ok. Got it working by acutally placing the ActiveX on a form in stead of creating a variable of the type msCommLib.msComm.
Then the ActiveX is indeed self-registered on the target machine. But when after testing I uninstall my project, the ActiveX is unregistered from my machine as well, and I always have to reregister is (with regsvr32) before I can work with it in VS again.