VODVPN in windows service - WeOnlyDo Discussion board

VODVPN in windows service (wodVPN)

by Ruslan, Saturday, December 03, 2011, 12:21 (4499 days ago)

My attempts to get to work in VPN Service Inside windows not uvenchalis success.
when using 3.5 framevork error ...... framevork 4.0 events in the facility are not called ......
Are there any ideas how to get VPN to work in the service?

Re: VODVPN in windows service

by wodDamir, Saturday, December 03, 2011, 13:41 (4499 days ago) @ Ruslan

Hi Ruslan,

I'm not sure how much I can help since you didn't provide any details on what exactly you're trying to do.

However, please note that there is no blocking done in wodVPN. In other words, component methods are called, and immediately executed without any wait for methods to actually complete. What I believe you're having issues with is that service stops before wodVPN even trying to do anything.

In other words, you'll probably need to call wodVPN in a separate thread, and place some loop into main thread in order to keep service from stopping.

Hope this helps.

Regards,
Damba

Re: VODVPN in windows service

by Greg Buerk, Saturday, May 26, 2012, 00:02 (4325 days ago) @ wodDamir

THe way to get htis to work in a service is to Spawn another thread. Then on that new thread do a Application.Run(Addressof YourTunnelControl)

When the YourTunnelControl method returns the Application.run will finish and the thread will be done.

The application.Run is needed because it creates a Message Pump that is needs to fire the events from the control.


A Question for Damir, If you use the Fast Notification interface do you need a message pump?? Cause the docs make it sound like you do not and these event will be called instead of the events.

Re: VODVPN in windows service

by wodDamir, Saturday, May 26, 2012, 00:06 (4325 days ago) @ Greg Buerk

Greg,

Yes. Implementation in both cases needs to be same. Although component will fire methods instead of events, message pump is still needed since nothing will be able to *keep service alive* since methods aren't blocking.

Regards,
Damba