Files in a service (WCF) references

The new service reference is persisted in a similar way how the old web reference is persisted in a visual studio project.  All files including metadata file downloaded from the server will be persisted into a single folder, which defines the CLR namespace proxy code lives in.

Files in a service reference is not shown in the solution explorer by default, but it is easy to see them by turning on "Show All Files".

Those metadata file includes all WSDL and XSD files.  DISCO files will be also kept, if the metadata is downloaded from a disco port, although those disco files are never used in configuration/proxy generation.

All those metadata files and code generator operations are persisted in a .svcmap file.  The .svcmap file is the basic unit for the proxy/configuration generator.  We may add multiple metadata sources into one .svcmap file, so the code generator will handle them at the same time.  If the metadata is property prepared, the code generator will generate shared data contracts for multiple service contracts.  This is just one function that you have to get by editing the .svcmap file directly, because it is not exposed through simplified UI.

Besides the .svcmap file, there is a '.svcinfo' file which tracks the configuration added to the app.config/web.config, so that portion can be removed when the service reference is removed from the project.  When we update the reference after the service is updated, we will try to update the app.config file, but not just inject another section of configuration into the file, like what svcutil did.  The format of this file is not designed to read/edit by human, it is better not to mess up this file.

However, currently, the fuction to maintain the app.config is faily weak.  It is certainly better than svcutil, with which you have to maintain the file by yourself. But while the function works fine when you live with the configuration generated automatically, it doesn't work well after you change it.  In most case, it will not take out the configuration changed by you, but will inject the new section side by side with it.  That makes that function less useful in those advanced scenarios.

There are talks about what to do when the injected configuration has been updated, but the extensibility of the configuration in WCF makes it more complex than what can be done in a short product cycle.

.svcinfo file is persisted as one extension file of the .svcmap file. The .svcmap file allows other customized extension files, so actually a customized WSDL importer/policy importer extensions could pick up options from one extension files to control options in code generator. BTW, just like svcutil, those importer extensions are supported in VS.  Without the toolconfig parameter, you need add those extensions in the machine.config or app.config of the project.  The drawback to put those design time configuration into app.config is that you would leak them into the runtime.  In beta 2, it is possible to put those design time configuration in a seperated config file.

So, an advanced user could write an extension to change generated configurations by changing certain values, or remove not needed ports.  It could be done in a general way, and its real behavior can be controlled by an extension file, which could sepecify like which port need be removed, and what binding parameter need be changed, so you don't have to manage the app.config file by hand.