.svcmap file
After we add a WCF service reference into a Visual Studio project, a .svcmap file will be added to the project, and it contains most information of the service reference. Actually, it is the only essential file of the reference. In most case, we can remove all other files in the service reference, and still can pull down all the files from services by updating the service reference. By default the .svcmap file is hidden in the solution explorer unless we turn on "show all files..." option.
Do I need understand the .svcmap file? No, you don't have to, if you just want to play with the new WCF feature, just like you don't have to know much about command line options of the svcutil tool before you start to use that. Actually, the file contains options for the proxy code generator, makes it equlivent to those command line options in many cases. However, when we need deal with some slightly complex scenarios, like consuming an old web services, sometimes without turning those options, we don't get useful proxy code. That is when we need look into this file.
Some common code generator options are exposed through a "service reference settings" dialog (not in beta1). But many of them are not exposed through any UI. To change those options, we will have to open and edit the .svcmap file inside a service. Fortunatly, the format of the file is fairly simple, and the schema of that file is shipped with the Visual Studio, so the Xml Editor will provide intellisense when we edit the file.
Although the most options in the .svcmap file works exactly the same way as command line options of svcutil tool, there is some difference between them. For example, when you turn on type sharing in existing assemblies, the svcutil will share service contract types as well as data contract types. But the code generator in VS will only share data contract types. Service contract types will not be shared automatically. A white list must be added in the .svcmap file to make service contract type sharing to work.
Other than the code generator options, there are some interesting things we can do when we edit the file directly. One sample is that there is a MetadataSource section in the file, which contains where to download metadata file. By default, there is always one MetadataSource when the service reference is created through UI. It doesn't have to be this way. For example, if the metadata is not exposed by the service, but you get them through other way of communication, like through an email. We can copy all metadata files into the service reference folder, and reference them directly in the .svcmap file, and delete all MetadataSources. The result will be a service reference, which generates valid code, but will not try to download files from a server. Another possible is to add two sources, so the metadata will be pulled into one reference, and code will be generated together. It is similar like providing two URLs in the svcutil tool.
We can also apply things similar to '/toolconfig' in the svcutil command line. That will allow us to add/remove WSDL/Policy importer extensions. The easiest way is to add those tool configuration in the web.config/app.config of the project. However, that solution has two problems. First, we usually don't want to ship those design time options in the product. The web.config/app.config is a part of the product, so we do mix the design thing and runtime thing in the same place. Second, if we have two service references, and we want different importer extensions for them, there is no way to do so. Fortunately, it is possible to give every service reference a seperated tool config file. The way to do this is to add a Reference.config file in the service reference folder, and reference that file as an extension file in the .svcmap file, just like how .svcinfo file is referenced.