Contents - Index

What's the difference between Sheriff 2 and Sheriff 3? Sheriff 3 utilises client/server architecture, which differs from Sheriff 2 where a shared file was located on the server. In other words, with Sheriff 3 there are separate Sheriff client/server applications whereas in Sheriff 2 the Sheriff applications only ran on the client. Please read Sheriff Help topic 3.4 for further details. Is Sheriff 3 compatible with all versions of Windows since Windows 95 or are there some restrictions on either the client or the server o/s? Both the client and server should work with all versions since Windows 95, however we only support Windows 2000, XP, Vista & Windows7. The service only works with Windows 2000, XP, Vista, Windows 7 and all versions of Windows Server. Do the same evaluation Product IDs and Secret Codes still work Yes. Is the registry path still "HKEY_LOCAL_MACHINE\SOFTWARE\ACUDATA\SHERIFF\PRODUCTID"? Yes Will my upgrade be as simple as using your new header files and replacing "SlsApi.dll" with "SlsLocal.dll" ? Yes, that is correct. In other words, I don't have to distribute and deal with your server exe's? Yes, that is correct. And, of course, my new 3.0 application will recognise existing 2.8.7 licenses on customer machines? Yes. Where is the slsapi.lib file located? There are now two versions of header files named slsLocal.lib and slsRemote.lib located in \API\DLL\Local and \API\DLL\Remote The inc and lib directories have local and remote subdirectories. What is the difference between local application and a remote application? A local application is what used to be called "standalone application" - an application running on a local machine. A remote application is also called a "network application" which talks to a Sheriff license server running on a remote server. Is the old method of issuing standalone licenses still supported? That is, can I still access local licenses as files or does all traffic have to be directed through the SlsSevice? Yes, the old method of issuing standalone licences are still supported in the same way as it use to be and with the same API functions. All you need to do is to link your app to SlsLocal.dll All of our products have a network license option. This would seem to indicate, then, that I would need to know in advance whether I need SlsLocal.dll or SlsRemote.dll. In other words, I'd need a registry key or something similar to tell my app whether to load the local or remote flavor, and go from there. The only other option would be to install the SlsService on all the machines and direct the SLS_Connect command at localhost. Is this correct? Yes, that is correct. We assume that your software knows the type of the licence, network or standalone. You can indeed treat a standalone licence as a network licence by running SlsServer on a local machine and direct SLS_Connect to the localhost. We have several cases where users have a mix of network and standalone licenses. The main application license may be network, but specific libraries may be standalone. Is it even possible to support this case? Can I use both SlsLocal and SlsRemote at the same time? Is the SlsRemote DLL capable of talking to multiple servers? It is possible to support both standalone and network licensing at the same time. One way to do that is to treat the standalone licence as a "local network licence". By doing so, you only need to use SlsRemote. The other way would be to dynamically load SlsLocal.dll or SlsRemote.dll at the run time depending on the type of the licence: you load up SlsLocal if the licence is local, SlsRemote if the licence is network. When am I supposed to call SLS_Connect? The documentation does not say anything about this. SLS_Connect is called to connect the client to the Sheriff server, i.e. you only need to call it for a networking licence. SLS_Connect should be the first call before any other API can be called. I don't seem to be able to call SLS_Remove when I am not connected. I call this to clear out the registry entries when something goes wrong sometimes, and if something has gone wrong, I will not be connected. For network version (SlsRemote.dll), SLS_Remove removes registry and/or files on the server. If that is what you intend to do, then you have to run it locally on the server machine in cases where the connection is broken. If the server is set to a different port, do I have to set the Clients to that same port when I connect? This will be an additional piece of information needed at setup time. Yes. Like any client/server application, the client has to know where the server is. If the licence files are written to by the server application, do the clients still need to know the path to the licence files? If so, then presumably the SLS_Registry routine will still need a path string? It would be nice if we didn't have to specify this, as it is sometimes a source of confusion for our customers. No, the client does not need know where the licence files are. In the network environment, functions like SLS_Register, SLS_Remove are called to administer the server not the client. This may be a bit confusing for people who are used to Sheriff 2 where everything is local - even the so-called network licence file in Sheriff 2 is kind of local to the client. Please remember, with Sheriff 3.0 and a network licence, everything is remote on the server. All API functions actually work on the server. So the clients no longer need write access to the licence file? That is right. There is no need to have the shared folder either. The client does not need to have any direct access to files on the server. It is a true client/server framework.