TID102016 (IWS2E009) - Re-register a GUID with WSAInstallService()

From Developer Community

Question:

I'm using WSAInstallService() to install a service. When I do it the first time, it is fine, but when I try and reinstall the same service with the same GUID and other parameters, it still seems to go through fine! Shouldn't it return a WSAEALREADY error code? The reason I check for this is to ensure that I do not re-register an existing service.

Answer:

WSAInstallService() has to fan the request out to all of the name space providers and then pick a reasonable return code based on the several responses. In the providers that Novell coded, the provider just silently accept a re-registration without reporting WSAEALREADY. Any application that does not require a workstation install (and workstation installs are evil) is going to have to call WSAInstallService() every time it runs to make sure the workstation is up-to-date, and will ignore the EALREADY error code anyway.

Question:

In the case of re-registration of the service, lets say the SAP_ID changes from the previous WSAInstallService() call, but the GUID and other parameters remain the same, would there be SAP broadcasts for both services (i.e would they be advertised as different Server Types, although the SAP_ID value in the registry changes to reflect the new one?

Answer:

The GUID is the definative field in the service class info structure. If you re-register a GUID with different class info (the different SAP_ID in your example) then the old info should be discarded and the new info used instead. One thing to consider is that each name space is responsible for its own bits of the the service class info structure. Lets say you register a service with NS_SAP and NS_DNS info. Then sometime later you realize the error of your ways and now you register the same GUID with NS_NDS and NS_SLP info. The SAP and DNS providers must not discard their information just because they are not in the new query set.

[edit]