The ServerService is provided with the DevForce installation to host the EntityServer as a Windows service.
Deploying the EntityServer as a Windows service is a good choice in intranet and trusted domain environments, especially if you're not familiar with IIS.
You'll often find that it's easier to first test with the ServerConsole before deploying the EntityServer as a Windows service. The ServerConsole configuration and processing are identical to that of the service, yet the console is easier to setup and to diagnose early problems.
The following assemblies are always required:
IdeaBlade.Core.dll
IdeaBlade.EntityModel.dll
IdeaBlade.EntityModel.Edm.dll
IdeaBlade.EntityModel.Server.dll
IdeaBlade.Linq.dll
IdeaBlade.Validation.dll
You'll also need the .config file:
ServerService.exe.config
If you're deploying a Code First model, you'll also need the following:
EntityFramework.dll
IdeaBlade.Aop.dll
PostSharp.dll
You'll of course also need all of your own "server-side" assemblies. These are the assemblies holding your entity model(s), and any custom extensions you've implemented.
You may place the DevForce assemblies in the GAC, although there's generally no compelling reason to do so, unless you have a large number of DevForce applications installed and they are all using the same DevForce version.
You do not need to, and in most cases should not, install DevForce to the target machine. Runtime license information is found in your model assembly and not the registry.
Did you notice above that the configuration file used here is named ServerService.exe.config? This is because the executable is named ServerService.exe and we're following standard .NET config file naming and discovery conventions. (In Windows Server 2003, the config file should be named ServerService.config.)
The config file will contain most of what's in your app.config file in your client application. It's usually easiest to copy that file and edit as needed.
You'll usually need the <connectionStrings> for any databases your application uses. (You can also use <edmKeys> instead of or in addition to connectionStrings, but they may be deprecated in the future.)
Remember the credential information in the connection string: if you include a userid and password you may want to think about encrypting the connection strings section if the server on which the ServerService is running cannot be secured. If you use Windows integrated security, rememeber that the service "log on" account will be the account accessing the database. Using a custom account for the service with only the system and database privileges needed is a good option in this case.
If you are using a custom DataSourceKeyResolver to dynamically provide connection information, you will not need to define connection information in the config file.
You can use the <logging> element to set the file name and location of the debug log, or to turn logging off altogether. You also might want to archive log files. Generally other logging attributes are not needed, or used only for debugging purposes.
A typical config file might contain the following logging information:
XML | <logging logFile="log\DebugLog.xml" archiveLogs="true" /> |
... to create a file named DebugLog.xml in the log folder and archive files automatically.
Also see the Log topic for more information. Remember to secure the folder or file from prying eyes.
You'll generally use the <objectServer> element to configure the service information for the EntityServer.
At a minimum you'll have something like the following:
XML | <objectServer remoteBaseURL="http://localhost" serverPort="9009" serviceName="EntityService" > </objectServer> |
If you've modified any of the defaults for the <serverSettings> element, such as the allowAnonymousLogin or loginManagerRequired settings, you'll also need to include that information here.
The <clientSettings> apply only to the client application.
Note above that we're using port 9009, one you often see in DevForce samples, but there are no DevForce requirements for this port number, and you can pick any free port. You should, however, not change the service name.
Although we show use of the http protocol above, you can also use net.tcp and https. If using https you'll need to create an SSL certificate and map it to the port wanted - see this blog for more information.
As with any DevForce server or client, you can replace the <objectServer> configuration with a WCF <system.serviceModel> section which gives you complete control over the configuration of communications. See the advanced configuration topic for more information.
You must first install the ServerService as a Windows service. Do this as follows:
Once the service is running, your client applications can then communicate with the EntityServer. Remember to make sure that their <objectServer> settings match those of the server.
You've hopefully taken steps to secure your application, even if it will be used only within your organization. You've disabled anonymous access, and authorize user actions. Take a look at the additional steps you can also take.