Supporting Visual Studio 2005 extensions for .NET Framework 3.0 (WCF)...

a_pasha — Fri, 29 Dec 2006 02:51:00 GMT

I don't think that 'support' should block anyone from using the extensions to adopt WCF, as any projects created using the extensions will continue to work with Orcas. The only difference is that Service references created using the extensions will be treated as normal folders that can no longer be updated. The project should compile and continue to work. The proxy class will be treated as any other code file. This should work because the .NET Framework 3.0 has been released and is fully supported in Orcas.

Only if the service is being modifed, would I recommend re-creating a Service reference in Orcas. This will help in managing the proxy class, as well as the configuration, as the service is updated.

To do this you should:
1. Delete the proxy code file for the Fidalgo Service Reference - OPTIONAL
2. Update the App.config file by removing the relevant ServiceModel sections - OPTIONAL
3. Add a Service reference to the service. If you didn't delete the proxy class/config, the conflicts should be resolved automatically.

Note:
- We cannot support the Visual Studio 2005 Extensions as they were only meant to be an early technology preview. They were our means to get tools out to the community quickly to help early adoption of the product. Therefore, longer term concerns were shelved in favor of getting the tools up to quality and out the door as fast as possible. They, consequently, do not meet the bar required for products that we plan to support longer term. The code, nevertheless, that the extensions generate for WCF on the 3.0 framework will definitely work on Orcas and is fully supported, as Orcas fully supports targeting the .NET Framework 3.0.

- We evaluated the costs of automatically migrating Fidalgo Service references (as a part of the upgrade wizard) in the Orcas timeframe against other features and decided that the costs/benefit vis-à-vis other features did not make the bar.

- Feb CTP will have the first drop of the new Orcas Service Reference features. The planned feature set in Feb CTP is far superior (quality-wise) to the features released in Fidalgo. I plan on releasing a list of the CTP features once we ship the Feb CTP. Unfortunately, I can’t recommend relying on the Feb CTP for production as we plan on changing .svcmap file (contains the information about the Service reference) in the future to accommodate new features planned in the following months. Therefore, it is not guaranteed that the Service reference (or even the project) can be upgraded between CTP, Betas, and RTM.

Ali

Visual Basic Issue with Types that are generated using svcutil.exe (WCF)

a_pasha — Thu, 21 Dec 2006 22:30:00 GMT

If you generate a WCF VB proxy that contains a DataContract type using svcutil.exe, calling a method that returns the type will always incorrectly return an uninitialized type. This works correctly for C#.

John Stallo, a peer of mine, spent some time investigating this issue. Here's the resolution:

The problem is a namespace mismatch issue that involves the /Rootnamespace compiler switch (on by default in VB projects).

The important line of code that svcutil generates with this switch is an explicit namespace argument for DataContractAttribute. (This information is usually pulled from the service’s WSDL – the namespace below is the default one that’s generated if a namespace isn’t explicitly specified on the data contract on the server side):

System.Runtime.Serialization.DataContractAttribute([Namespace]:="http://schemas.datacontract.org/2004/07/")> _

Partial Public Class DataContract1

Apparently svcutil.exe doesn’t generate the explicit namespace argument by default. So when the generated proxy is added to a VB project, the Data Contract type now falls under the VB project’s root namespace (e.g. ConsoleApplication1.DataContract1). Without the explicit namespace argument, WCF has trouble finding the Data Contract type at runtime because the project’s root namespace throws a spanner in the works, which is why you then end up with uninitialized fields. This doesn’t repro with C# because C# projects don’t have an implied root namespace.

Workaround:

Run svcutil with the following switch: /namespace:*,MyNamespace

…where “MyNamespace” is the namespace of your choosing that you want the proxy to be generated in.

Note that this will not be an issue with the Service Reference feature that will be available in the Feburary CTP of Visual Studio Orcas.

Cheers,

Ali

Ali Pasha's WebLog... : WCF

Supporting Visual Studio 2005 extensions for .NET Framework 3.0 (WCF)...

Visual Basic Issue with Types that are generated using svcutil.exe (WCF)