Well, this .svcmap file is editable, and Xml Intellisense actually works here, so changing it is not that difficult.  Certainly, we are not interested to change those options which can be changed easily through the configuration dialog.  Here are something you can do with editing this file, but otherwise not doable:

1, You can enable sharing service contract types:

   by adding ServiceContractMapping in the ServiceContractMappings section, you will force the code generator to use a shared service contract type defined in a referenced assembly (you cannot share a type defined in the current project.)  The service reference will still generate configuration to the app.config file.

2, you can define complex collection mappings:

  the configuration dialog only support some limited options. Adding CollectionMapping in the file, you get similar function you can get by using svcutil command line.

3, namespace mappings:

  it works like /namespace option in the svcutil command line

4, you can add additional MatadataSources!

  actually, you can reference two services in one service reference, and share the data types. Adding additional MetadataSource to the file by hand is the only way to do that today.  Once you added, it will be maintained, and it will not be lost, when you update the service. (Actually, you don't need add MetadataFiles by hand.  Just add a MetadataSource into the file, save it, and Update the reference, all metadata files will be downloaded automatically.

5, add additional Metadata files

  It is possible to add additional metadata files to a service reference, just copy them to the folder, and add additional MetadataFile node in the .svcmap file to reference them.  They will be used in the code generator.  All MetadataFile without a SourceId will not be automatically updated, so they will stay even when you update the service reference.

6, add private configuration file

 You can add a special extension file with name = "Reference.config" (very similar to configuration.svcinfo).  With the configuration file, you can add additional extensions to the code generator. (Unlike adding them to the machine level configuration, things in the Reference.config only affect the code generator in one reference.  Special security settings to enable downloading metadata files from a secured server is also possible through a such config file.

7, additional extension files

  The additional code generator extensions can locate those extensions file registed in the Extension section. It is possible to set additional options through those files.

1, there will be a brand new schema designer built into VS.  However, because of schedule issues, it is not in Orcas, but will be released off-cycle;

2, the two old designers depend on some old components of HTML designer.  In Orcas, the HTML designer is replaced, and those components are gone/replaced.  It becomes too costly to maintain them, especially when a new designer comes out soon.

3, the old schema designer also depend on a designer surface implemented in an old COM package, which is about to be removed.

Currently, there is no plan to build a new data grid editor, which view/edit an XML file in a data grid.  The old designer only targets data set files, and it is very limited.  It will be interesting to see whether people need it before spending time on it.

Svcutil command line	VS service reference (.svcmap)	VS UI
/out	(always delivery from the name of .svcmap)
/config	(always the config file of the project)
/mergeConfig	Always true
/noConfig	Not supported
/dataContractOnly	Not supported
/language	Always based on the project
/namespace	<NamespaceMappings> But *-> ReferenceName is always added
/messageContract	<GenerateMessageContracts>	Yes
/enableDataBinding	<EnableDataBinding>
/serializable	<GenerateSerializableTypes>
/async	<GenerateAsynchronousMethods>	Yes
/internal	<GenerateInternalTypes>	Yes
/reference	<ReferenceAllAssemblies> <ReferencedAssemblies> <ReferencedDataContractTypes> <ServiceContractMappings> Can pick up existing reference assemblies of the project automatically	Limited
/collectionType	<CollectionMappings>	Limited
/excludeType	<ExcludedTypes>
/noStdLib	Through <ReferencedAssemblies>	Yes
/serializer	<Serializer>
/importXmlTypes	<ImportXmlTypes>
/targetClientVersion	Based on the project
/t:metadata	Not supported
/validation	Not supported
/t:xmlSerializer	Not supported
Multiple url/file	<MetadataSources>
/svcutilConfig	<ExtensionFile Name=”Reference.config” />

 Essentially, the svcutil is built for several tasks like exporting metadata, validating the service.  But the service reference is built for generating proxy/configuration only.  However, in the proxy/configuration generating scenario, the function of the service reference and svcutil are overlapped.  The service reference supports most options svcutil supports in its command line.  However, to access those options, editing the .svcmap file is necessary  (only limited options are exposed through UI.)  By saving the options in a file, however, it is easier to repeat the process, when the service is updated.

 The advantage to use the service reference is clear when using the IDE.  We don't lose most ablility of the svcutil tool, but gain some convenience: options like the language/targetPlatform don't have to be chose again, but will be picked up from the project system automatically.  The result config is also automatically merged, and previous injected configuration will be tracked, and removed when the reference is removed or updated, so it won't inject lots of duplicated items. (That function is limited in this version if binding in the configuration is editted.)  The IDE also supports better experience when the service is secured.

First, for who is using the event-driven model, there is no reason to turn on the Begin/End pattern methods, because only one of them should be used.  For many users, the event-driven model is also easier to use.

For those who still need use the Begin/End pattern methods, it is still possible to turn on a project level option to get them back:

To do that, we need unload the project from VS, and edit the project file directly in an editor. (Please backup one in case we do something wrong.)

In the first section of PropertyGroup, you will see many properties like:
<ProjectGuid>{F4DC6946-F07E-4812-818A-xxxxxxxx}</ProjectGuid>
<OutputType>Exe</OutputType>
...
Don't change any of those, but do add an extra property just like the OutputType into that section like:
<WebReference_EnableLegacyEventingModel>true</WebReference_EnableLegacyEventingModel>
Ignore the warning from the xml editor, save the file, and reload the project into VS.

After that, you have to regenate all proxy code (by updating the reference, or running the custom tool on the .map file)

Note: it is only for old web reference proxies.  For old service references (WCF proxies), the Begin/End pattern async methods will be generated when "Generate async method" is turned on for that reference. (That is beta 2 feature.)  The methods for another pattern (event model) will not be generated in beta 2, but will be added in RTM when the project is targetting the new 3.5 framework.

Those extensibility points include:

1, a set of VSIP APIs to allow third party feature to list and manipulate WCF references inside a project;

2, allow a third party project system to enable/disable the feature, and how to store the information in the project system;

3, a way to extend the current “add service reference” dialog to help finding services;

4, support and extend standard WCF extensibility model, including support WSDL/Policy importer extensions, and allow extra settings of the extensions to be persisted in the reference.

Those new samples could be found at https://www.microsoft.com/downloads/details.aspx?FamilyID=d9000e2c-bd3f-4717-a181-723960814e16&displaylang=en

The problem is that the instance of the dataTable on the client side is created by framework directly. It is impossible to change the namespace without changing generated strong type dataset code.  To work around this issue, the server side need copy data to an independent dataTable before passing it to the client.

That affects both .Net 2.0 web services and 3.0 Windows communication fundation services.

We might want to continue using old style web reference for those web services.  Unfortunately, "Add Web Reference" menu is disabled by default in the projects, unless you already had such reference in the project.  In beta 1, there is no way to find this command.  We have to downgrade the project to target 2.0 platform to add one web reference and upgrade the project again to add the first web reference.  It is very ugly workaround.  In CTPs after beta 1, the command can be accessed through the dialog popping up when we click the "advance" button on the "Add Service Reference" dialog.  It is not an obvious place to find it, but the menu should be enabled after that, so it only need be done once.

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.

For service reference, there are two kind of type sharing:

1, reuse type pre-defined in a class library in proxy code  (do not generate new type in proxy)

2, share type between services (generate new type only once for different services)

The SDK tool svcutil supports the first kind of type sharing.  The WCF feature in the Visual Studio provides same level support for this kind of type sharing.  However, it becomes easier to use, because the generator in VS could automatically extra types in depedent assemblies of the project.  We do need remember to add reference to the assembly containing pre-defined types, but don't have to pass it as a parameter as we use svcutil.  The feature in VS also provides more refined control to the user, so it is possible to share types in a small set of assemblies or disable it.

The type sharing is actually done by the DataContract importer extension, so the type sharing in VS inherits the same limitation of the feature in svcutil.exe.  Basically, if you are only using new DataContract in service contracts, it works well.  But it doesn't support sharing some xml serializable types.  Sharing dataSet is supported, but somewhat limited.  The problem is that the data set type must be defined in exactly same CLR namespace in both server and client before the type sharing can work.  It should not be a problem if we want to share a same data set between client and server, but could be a problem if we only want to share the type between clients.  Of course, since data contract types are generated by extensions, it is possible to improve that by adding new or customized extensions.

One limitation which could not be resolved by adding extension is that the shared type must be defined in a library, but can not be defined in the same project consuming the service.  Considering that the type must be used by the proxy generator, and the proxy is a part of the project.  Reusing type in the same project could somehow cause a recursive logic in the current way how the generator works today. We may have to live with that limitation.

The second style of type sharing is supported by wsdl.exe.  svcutil.exe also allows to have two metadata source URL in its command line, although it works only if there is no conflict in metadata from the two sources.  That works if the wsdl files are hand crafted, but doesn't work well when the metadata is generated automatically, because we often get duplicated schema files from difference sources.  The WCF consumption feature in VS works in a very similar way as svcutil, although it would try to remove duplicated schemas.

(BTW, the type sharing is not supported in beta 1, but CTPs after that)

Based on the document, the problem happens, when a thread (so often the main UI thread) is working on something and doesn't pump message for 60 seconds.  In that period, if a background thread tries to make a remote call to the thread, it could be blocked for more than 60 seconds, and the problem will be raised.  If the application uses COM, (maybe directly or indirectly -- for example one control is built this way), it could be a problem.  Even the application doesn't use multi thread directly, and we don't feel that we make any remote call.   The problem is that most managed application depends on the GC to release COM marshalling object,  and the GC is running in a background thread and it could run at any time.  So, when the GC tries to release a COM object when it finds no one is using that, it will make a call to the STA thread.  If the STA thread ever does something longer than 60 seconds, it becomes a problem.

It could be worse, if we create a background STA thread.  It is almost impossible to stop that thread, because if GC hasn't cleaned up all COM objects created in that STA thread at that point.  It would end up in the ContextSwitchDeadlock, because no way to call into a dead thread.  Of course, we couldn't control GC to clean up those objects before we stop the thread. Unless you can control the life of those ReleaseComObject, it is better to create MTA background thread instead.

ReleaseComObject itself could be a nightmare.  Unless you own the both side, the code could be broken easily if the COM object written in native code is updated to managed later.  The internal count is increased in any native-managed boundary, so we need know the exactly boundary, which is not really detectable in code.  'IsComObject' does not provide much value, because an object could be implemented in half managed and half native code.  For those objects, IsComObject will return true, although the call doesn't go through native/managed boundary.  Or even the half managed half native object is passed through a such boundary, its internal count never increases. The first time when you call ReleaseComObject, the native half of the object will be released, and the whole thing is now broken.