Update dll in Server - Error in Clients (Win98)

[Nandov]

Hi
I have a dll installed in a Windows 2000 Server at COM+.
I exported the dll to a msi file and installed in clients that are running windows98.
This works fine, but when I update the dll file in server, the clients don't work. I exported again to my clients to resolve this problem.
I would like to know if there is a way to update the dll in server without to export again.
Thaks Nandov

 

[SemperFiDownUnda]

Depends on what you do to your components. This is a feature so your applications perform as you would expect them to. Let me explain further.

When you write a program to use a com component VB grabs the GUID (Global Unique Identifier) for that component. When the program runs it looks in the registry for that GUID to find out what DLL to load. Now when you change a component the GUID may change depending on what do did to the component and what setting you have in the components tab of the project setting.

Lets start with what did you change.
If you just changed the inner workings of the component then the GUID does not need to change (I'll explain this in more detial in a minute). If you added, changed or deleted any Properties, Methods (to include parameters of the method), or Events then the GUID will have to be regenerated to give it a new ID.

Why is this so? Thing of an electric plug and outlet on the wall. Your program is the cord and depending on what country your in you have 2 or more prongs in different configurations. At compile time of your program what you are doing it telling your program (the cord) that you want the plug end to match a certian Wall Outlet and the plug get fixed to the cord. Now if you brought your program from America to England the plug wouldn't fit and that is a good thing. This is because Englands Power system is rated different than America's. If you did manage to get the plug in the socket your appliance would probably blow up as soon as power was applied (this would be like when you create your object.)

Now you can control this situation a bit but you have to understand the effects of the setting.
Under Project Properties there is a component tab
Go down to Version compatibility
No Compatibility - this will regenerate your GUID every time you compile (normally you'd never want to do this)
Project Compatibility - This will keep the guid the same allowing you to change the component during development without the head ache of the GUID being regenerated. Note : each time your component changes your programs that use that component will need to be recompiled with access to the new DLL so that the new interface (features) are known so the program can make the right calls. Also note that if you didn't change any of the public interface then there is no need to send the new DLL to the program being compiled as the component's outward appearance (public interface) has not changed
Binary Compatibility - This has VB look at the last version of the DLL to check if anything has changed in the interface. If it has it warns you before compiling and regenerating the GUID so you know that you have to redistribute the DLL and recompile the programs that use it.

What does this all mean? How can your life be made easier.
DESIGN Yes sit down and figure out what your components need to do before you start codeing them. You don't have to know the code inside them just what Methods, Events, and (god forbid this is a no no in DCOM+) Properties.

Leave the stubs (empty public interface items) without code and start programming. As you need you fill in the component code. This should minimize the amount that you change the component and thinking ahead of time is always a good thing in programming.

 

[Pridu]

Do you have a solution for the same question in VC++? I would really appreciate all the help I can get becoz I am having the same dillema. Thanks.

 

[SemperFiDownUnda]

In VC++ you control the actual GUIDs yourself via the IDL. If your interface doesn't change then don't change the GUIDs.

Just keep in mind that the system works this way for a reason. If you try to circumvent this then you have a large risk that your application may fail.