This project is read-only.

Installation Packages & Physical Layout

In the v2.0 RTM release, there are 2 MSIs for the Simulator Service (one that deploys the web application and one that deploys the Console Host) and another MSI for the Service Studio WinForms app.

In terms of the physical layout MockingBird is manifested as follows
  • A virtual directory : This contains the SimulatorService.svc file (the WCF message interceptor) and in the bin folder we have the Interceptor.dll which contains HttpHandler (implemented as a class that inherits the IHttpHandler interface rather than an .ashx). The .svc and the httpHandler both share the web.config and as explained in the technical documentation, there are a number of other .config files
  • A folder (usually installed into Program Files) containing the Console Host application and a testing app (also a console that fires off preset messages to the test endpoints that are hosted in the console app)
  • A folder (usually installed into Program Files) containing the Service Studio GUI application.
  • The datafiles folder containing a configuration subfolder and endpoints subfolder. This is available in both the web app install folder and the console app install folder.

Installation Guide

This is a short description of what you need to get up and running with the tool. The documentation provides all the steps in detail explaning how to setup the system

Get and install the package

(1) Run the setup of the web application which will create a virtual directory (by default). If you wish you can create a separate website and application pool but by default the system will install mockingbird into the defaultwebsite and use the DefaultAppPool.

(2) Run the setup of the console host application.

(3) Run the setup of the service studio.

(4) Extract the datafiles..(Sample path: c:\inetpub\wwwroot\MockingBird\datafiles). This data files folder also contains a ‘sample’ end point which is required to verify the installation (and the verification is done using the Studio app). Once you are proficient with this app and don’t need it, you can delete this sample folder if necessary.

(5) From a Powershell prompt (in the MockingBird directory) run the grantPermissions.ps1 script. This will give full control access to “Everyone” on the MockingBird data files folder. If you are not comfortable with giving such sweeping permissions, then feel free to change the script or manually ensure you give access to Network service or ASPNET user on the mockingbird datafiles folder (Even the service studio user needs permission to these folders as it writes entries to the handlerMap.config file).

Update the configuration files

All the config files have been setup automatically to hold the default production settings, so if you use the defaults (install the web app into a virtual dir in the default website, use c:\inetpub\wwwroot\mockingbird as local path etc), then you wont need to change anything. However, if you have chosen other paths, then you need to edit the config files.

Update your configuration files (found in the datafiles\configuration folder) as described in the installation guide.
The files you need to modify are
  • web.config and app.config : change this to add/modify endpoints for the WCF service.
  • MockingBird.config : contains all system level information including file paths etc
  • Logging Config : This may be either the Log4net.config or EntLibLogging.config depending on which logger you prefer.
  • Studio.config: The app config for the studio module pointing to test data locations etc.

If you are extending the system, then you would need to update the unity.config file as that lists all interfaces and maps them to the chosen implementations.

Changing the logger

The default logger is set to Log4Net. To change this, open the unity.config file, and look for the following line
<type type="ILogger" mapTo="Log4NetLogger">
(This appears in 2 places: at the root level and at the named container level). Replace this with
<type type="ILogger" mapTo="EntLibLogger">

If no logs are written at runtime, this maybe due to the log file being set to read-only. Note that the system always writes log messages to System Trace so by using a tool such as DebugView it will be possible to monitor what's going on.

Last edited Aug 12, 2010 at 2:08 PM by santoshbenjamin, version 12


No comments yet.