cancel
Showing results for 
Search instead for 
Did you mean: 

Dlls in .NET

Former Member
0 Kudos
150

Hi!

When accessing the COM objects via UI or DI using the InteropServices the Visual Studio creates some kind of "wrapper-dll".

From my point of view there might be some problems with distributing the AddOns, which use these dlls, e.g. with different paths to the base library, different releases of SBO, updates, etc.

Has anyone discovered any problems or does anyone have further information as far as these dlls are concerned?

thanks in advance,

Martin

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi all:

is the SDK still not supported on windows 2003?

I've created some NT services for windows2003, but they are throwing this error:

Error 13: QueryInterface error for the interface SAPbobsCOM.ICompany

I'm developing with Visual Basic .NET, framework 1.1 And the error does not happens with my desktops applications.

any ideas??? I believe is a security problem, but I dont know wich permission should be granted.

thanks in advance.

Former Member
0 Kudos

The SDK is now officially support on Windows 2003 for SBO2004 (6.7) and up... as always be very aware of COM security issues on windows 2003 and XPSP2

Former Member
0 Kudos

Martin,

The following link gives a nice intro to .NET Interop:

http://www.google.com/search?q=cache:ep4CHRAi1EIJ:radio.weblogs.com/0124037/doc/COM%2520Interop.doc.netinterop&hl=en

For the most part, Interop's wrapper class is simply creating a map from unmanaged COM binaries to .NET's Common Language Runtime. Like old Visual Studio COM references, it binds to a registered COM component's ProgID by default. This simplifies the problems of versioning as long as the ProgIDs are consistent, which the SBO SDK's are. The default COM class will automatically be loaded for a given ProgID.

You won't have to worry about paths as long as your wrapper dll is shipped with your .NET exe. The wrapper defies .NET convention and looks up COM libraries with the registry.

That being said, we have run into a few problems with the DI. When both 6.2 and 6.5 are registered on a machine, our addon works correctly 80% of the time. For the other 20%, it throws a COM QueryInterface exception when trying to instantiate the Company object. Our clients haven't needed both libraries so we simply unregister both libraries and re-register 6.5 to get things working.

Windows 2003 is a different beast all together. 2003 has tightened security on COM and has created some real headaches for us. Both Windows Services and Web Services run under special users that have trouble getting the permissions required to instantiate DI objects. Even when these services are configured to run as named users, they are unable to use the DI properly. In the case of Web Services, certain methods and properties throw errors while Windows Services receive the QueryInterface exception before any method or property can be used.

As a note: The SDK is not officially supported on Windows 2003. SBO 2004 contains a DI Server that manages 2003 permissions for you. If you're using the UI, you shouldn't have the same problems because the libraries are being referenced by the user logged on to the machine.

Hope this gets you started. We'd be interested in hearing your experiences when you get further along.

Good luck,

Corbin

Former Member
0 Kudos

Thanks you for the information. Unfortunately I'll have to develop AddOns running on Windows 2003.

We'll see...

Of course I will share my experiences when I - hopefully - get along.

Martin

Former Member
0 Kudos

Hi Corban,

You have pretty much summarised exactly the problem I am having. I am running SBO and IIS on the same box and have some webservices running using the DI API, if I run these from the server (windows 2003) only some of the objects will work (can't create a sales order), however if I run the webservices from a separate PC (XP PRO) and point the company object to the SBO install on the 2003 server it will work fine.

I was thinking impersonation may fix the problem in the web.config, or the processModel element in the machine.config, but even setting it to Administrator in these did not work.

Did you manage to get around the problme? If so I would be very interested to hear how!

Thanks,

Daniel