Version-control: svcmap, disco, xsd, wsdl, svcinfo and datasource files

Question

We have a webservice named, let's say Foo.

So there is a Foo.svc file and a code behind Foo.svc.cs.

We add a silverlight project and wish to use the Foo.svc services so we add a Service Reference and call it's namespace FooBar.

This creates the following files :

• Reference.cs
• Reference.svcmap
• Foo.xsd
• Foo.disco
• configuration.svcinfo
• Foo.wsdl
• Also various *.datasource files.

Over time we update the Foo.svc and add more Web Services (methods and interfaces) and the number of files in the FooBar directory is growing.

I have 26 Foo(nn).xsd files in this directory - where nn = 1 to 26.

My configuration.svcinfo is upto configuration91.svcinfo.

My question is this? Do any of these files need to be version controlled? Can they all be deleted each time you do a build \ deploy (as long as you do an update service reference)?

Filth

I wont put this as answer because I'm not sure. But only the reference.cs file is the most important file to me. Sometimes slsvcutil.exe does not work with vs properly so when I use it to generate a reference for silverlight, only the Reference.cs gets generated. – Danadanae

Thank you! I just saw David's same question on the silverlight forums. With a useless answer of course. God bless Stack Overflow! – Violist

Answer 1

Those xsd files are just metadata of your service that were just used when you created or updated a service reference. You can actually delete them since they were just use when the reference file is being generated. Theres no need to version control those files.

Dynameter

Are any of these files necessary? Or is everything contained in ServiceReferences.config? Is it ok to delete all .datasource, all .diso, all .svcinfo, and even references.cs? – Violist

@DanielWilliams: Reference.cs actually gets compiled, and you could in theory edit it by hand to add or change behavior. It can't be deleted, unless you want to update the service reference every time you build you code, as it is what actually does all of the work. Everything else is in a sense just a step in creating it. – Ornelas

Answer 2

The Reference.svcmap file is practically the definition of the service reference. It contains the different settings as well as source links. Reference.svcmap should definitely be source controlled because it is actually THE service reference in the sense of project items.

Reference.cs contains the generated contracts and proxy against which your code is compiled. Whether to source control or not to source control the file is up to you. Generally, this is part of the project code and should be source controlled, but being auto-generated it can sometimes lead to accidental breaking check-ins.

All of the other files are TEMPORARY files used when generating the contract and proxy code. Together they form the sum of the metadata exposed by the service which includes service contracts (*.wsdl), data contracts (*.xsd) and configuration information (*.svcinfo).

Parterre

Let me test my understanding: The *.xsd files stored locally are temporary files, the SourceUrl in the Reference.svcmap are what matter for the schema definition? – Ornelas

The url in svcmap is where the metadata was queried from when you generated the proxy. The *.xsd files are actually returned from the service's metadata endpoint. – Parterre

I was looking into where the actual end point is stored, looks like for service references that is in the Reference.svcmap in the Address attribute of the MetaDataSource tag. For web references, that is in WebReferenceUrl tag in the proj file. – Ornelas

The actual endpoint is configurable, you can always use the client with any base address, and this is all overridable in code and config. The url in svcmap would usually point to the dev / local service instance. As an example just to make a point, you could also generate the client directly from another project in the solution, in which case you don't need an endpoint at all when developing because the tool can extract the metadata from the source. – Parterre