DCOM Development with Vb

Visual Basic
When i run a COM Application server, is it possible that the clients will just have the interface and then the dlls that i add to the application can be accessed by the clients without having a copy of it on the local machine? Because whenever i cahnge the business logic in the DLL the interfaces looses the compatiblity and i have to re register the dll on the client. and dont even want to change the compatiblity option to binary compatible.

Answer Wiki

Thanks. We'll let you know when a new response is added.

I have not found a way around this problem myself. I have started to use web services rather than dlls to get around the whole maintenance nightmare that is DCOM

Discuss This Question: 1  Reply

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • HappyGene
    Mano, There are several ways to accomplish this. The most applicable right now (if you.re on a robust network) is to run a batch file or wsh script to register the dll.s on the client.s, but pointing to a dll location on a server. That way, whenever you change a dll, it will already be in place for the client to see and is automatically what the gui expects. The gui will load dll.s from the server as it does itself. You could do this periodically and "push" the registration to the client, or have it triggered by the client.s execution of the app. You could make the gui always start with ref.s to a fixed "boot" dll that once testd never changes and then check for changes and trigger re-registration that way if you keep recent versions of the dll.s handy for rollback. I think that is the best way when the app is heavy-use and your workers *should* have it open and be on-task at least 30% of the day. Other than that, you could push the dll.s onto the client and force a silent registration from the batch file or wsh script. I assume that this came up because your BL rule changes and/or maintenance *hot* issues are becoming a daily thing. I have made the fix for similar issues a part of dev/maint and am very pleased with that approach. I strongly recommend you *not* rely on Windows compatibility functions to manage dll.s/lib.s. Due to this latter concern, we have directed some apps (in code and via ini.s) to use dll.s from a server even if they.re already loaded on the client to avoid version conflicts with established apps. There.s a company (http://www.moonlight-software.com/vbpower.htm) that has commercialized a similar approach. Haven.t used it yet, but it.s coming. Good luck and please post your denouement, :) Gene
    0 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: