Wrapper for C# plugin development!

[Osler]

Just an FYI: the wrapper does not work with .Net 4.0

I think I saw problems at start-up that were similar to what JonFo and Richard were seeing when I had .Net 4.0 installed. Moving back to 3.5 or 3.5 with SP1 fixed the problem.

Osler

[mholtkamp]

Same problem, removed .net framework 4.0 and housebot is working again.
Is there a solution jet?

[allanstevens]

I also had the same issue, HouseBot crashed on startup due to the c# plugins. Then realised a Microsoft update installed framework4. So I uninstalled and all working fine. Phew!

[Steve Horn]

This issue began over in another thread dealing with migrating HB to Win7 64. The net result of that somewhat painful exercise is that it seems the HBDOTNETBRIDGE.DLL does not run under .NET 4, which is what was obviously stated earlier in this thread. The workaround at the time was to revert to .net 3.5. That's all well and good until you go to WIN7, which is not supported by 3.5. Knowing nothing about the genesis of HBDOTNETBRIDGE but reading thru all the previous posts, it seems that it needs to be recompiled or modified for .NET 4. As more HB users move beyond XP, anyone using this "wrapper" (is that the correct term?) will find that things that used to work don't under WIN7 and presumably 8.
Do I understand all this correctly?

[dlmorgan999]

FYI - it's not a true statement that Win7 doesn't support .NET 3.5. I just ported my system to a freshly installed Win7-64 over the weekend and haven't installed anything yet except Windows updates/patches and HB.

In looking at the registry (per this MSDN article), the system has .NET frameworks 2.0, 3.0 and 3.5 installed. I wonder if MS lists .NET 4.0 as a recommended upgrade? I generally only install critical and security updates.

I wrote two plugins using the bridge. One of them was causing "Automation Server" errors on startup so I removed it from the plugins folder and the problems went away. The other plugin is working just fine though on my Win7 64-bit server.

Unfortunately, I haven't had an HB software development environment set up for several years. I still have all the source code in my Subversion server though. If I get some time in the next month or two I'll see if I can do some testing against .NET 4.0 and see what happens.

Since I didn't originally write the bridge though, I make no promises that I'll get anywhere.

[Steve Horn]

Thanks. I need to start over on the K8055 problem, based on your replies. I'll report back once I get into it again.

[dlmorgan999]

Sounds good! If there is anything I can do to help, let me know.

[Steve Horn]

reporting back...
I started from scratch:
1) removed all traces of the K8055 device from the HBDATA back end tables.
2) Following Raptor's instructions at viewtopic.php?f=1&t=855536&p=449615&hilit=K8055#p449615, verified that:
HB k8055-vm110.dll in C:\Program Files\HouseBot\Plugins\Devices
HBDotNetBridge.dll in C:\Program Files\HouseBot\Plugins\Devices
HBDotNet.dll in C:\Program Files\HouseBot
Restarted HB and it crashes. I saw the dotnetbridge device module load in the startup, but not the K8055. BUT, I went back to the old working HB server and launched HB and didn't see the K8055 device module load msg there either, so that may be a red herring.

I can delete the dotnetbridge dll from the Housebot....Devices directory and HB start fine. (Of course I get an error msg about device K8055 not found.)

Thinking that it might be a .NET issue I went into control panel and uninstalled/repaired the .net framework 4 Client Profile. No help.

I'm at a loss.

[Steve Horn]

I'm trying to understand how all this is supposed to work. What I have so far is:
1) The Velleman K8055D.DLL cannot be directly called from VBSscript, as it is not a COM. (Whatever that means... )
2) To do that, you need a "wrapper" to act as middleware (my words) between the HB VBScript and the K8055D.DLL.
3) Somehow HBDOTNETBRIDGE.DLL and HBDOTNET.DLL figure into that... although I don't know how. Are they the wrapper functions?
4) And of course... why can I not get this to work on a Win7/64 box? And is anyone else use the K8055 with Win7?

Elsewhere (here: http://forum.velleman.eu/viewtopic.php? ... 93&p=11372) I found where someone had posted some VB6 source code that, once compiled, I read to perform that wrapper function. Looking at the code, it appears to function as an interface between the K8055D.DLL and whatever (VBScript, but don't know how that is done) is used to call the VB6 functions. If that's the case, just getting that VB6 code compiled does the trick? So... what roles do the hbdotnetbridge and dotnet DLLs play.

(This is more thinking out loud than anything, but if anyone can clear this up, please do.)

[Osler]

This will be a bit of work, but you are going to have to create a COM interface for your old .dll file.

See here:

http://www.codeproject.com/Articles/758 ... ibrary-for

I had to do the same thing to allow me to use the UPnP.dll in vb.net.

Osler

[Steve Horn]

Thanks. But after reading the intro to that article I came away with the need to purchase MS Visual Studio .Net. In this instance it's not worth the money, time or effort. I can abandon use of the K8055 altogether, toss it in the rubbish bin, and use an Arduino as an I/O interface.... And not have to buy any software or learn yet another language. In reading a lot of K8055 related threads, the inability to be able to easily interface to it is a common complaint.
I do want to try one or two more things before I go that route though. The old HB server box (XP) is still functional and I'm sure that it can still talk to the K8055, as nothing has changed there. I thought I'd try uninstalling all the K8055 stuff (device, drivers, hbdotnetbridge, etc.) and then reinstall it, same as what I did on the Win7 box. Something is different between the two boxes. Is it only the win7-64 issue or did I miss something when I installed all the K8055 stuff on the new server. Dunno.
Anyway, thanks for the reply.

[markd]

Hey Steve- pretty sure you can use the free versions of the MS tools to build this stuff, in whatever language you want.

http://www.microsoft.com/visualstudio/e ... op-details

[Steve Horn]

Hmmmm. Thanks, I'll look into it.... Now that I can't use cost as an excuse.

[markd]

Sorry?

[Steve Horn]

I'm revisiting this "Non-functioning-K8055-in-Win7" DLL issue one last time before I bin the card and use a different I/O card altogether... one that actually comes with code that can be called from something as simple as Hyperterminal (and therefore can be accessed via a generic serial interface within HB).

That said, is there any way to get that K8055 DLL to work either directly from VBScript or some way that does not involve me: a) learning yet another language, or b) spending much $$, or c) both? I've reread the previous posts on this and quickly concluded that the solutions suggested were over my head. Any ideas?