1

I have a solution with multiple Silverlight 4.0 applications, which all reference the same WCF service through a common Silverlight 4.0 assembly. That is each of the Silverlight UserControl applications reference a Silverlight assembly called "ServiceClient", also in the solution, to get their common OperationContract information. These UserControl apps reference that assembly.

When I change the WCF service I must update the "ServiceClient" assembly. This causes a large number of *.datasource files, and ServiceName.xsd, ServiceNameN.wsdl, ServiceNameN.disco (Where N is an arbritrary integer). All of these files are listed as pending changes in TFS. I must then carefully undo maybe hundreds of specific pending changes. Is there a way to limit file generation or at least supress their showing up as pending changes?

Blanthor
  • 2,568
  • 8
  • 48
  • 66

3 Answers3

1

If you do not 'Undo" the pending changes and check-in, what happens?

If the files are checked-in then they were changed. Isn't that what you want?

I sometimes see VS/TFS set files to pending check-in, but when I perfrom the check-in the file list is cleard and the files are not checked-in (because there was really nothing changed in the files).

Maybe you are struggling with a non-issue.

Scott Bruns
  • 1,971
  • 12
  • 12
  • Actually I may have been going about this the wrong way. My ServiceClient assembly's service reference appears as a single checked out object in Solution Explorer. I right-clicked on it and checked it in. All the associated pending changes were checked in with it. This is simpler than what I had in mind. With a large number of developer Workspaces, everyone would have to do this occasionally. I guess that's not really a problem though. I found another link sharing your opinion http://stackoverflow.com/questions/1867285/which-files-under-service-references-belong-in-source-control-visual-studio – Blanthor Jun 10 '11 at 13:31
0

It's not clear why you are undoing the automatically generated changes after a service reference update. When you buy into the VS Service Reference method that's part of the baggage.

If you want more control of the client generation process, you can use the SvcUtil command line utility. You will have to add build tasks to your projects to perform this if you want to mimic the Add Service Reference approach. I'd recommend going with a single project wired to use SvcUtil to produce a client assembly that all the other projects would reference. You still would need to add the WCF config file to each of the projects that reference your client assembly though.

Sixto Saez
  • 12,610
  • 5
  • 43
  • 51
  • I do have that single project wired to use SvcUtil. I called it "ServiceClient" above. But I get ServiceName1.wsdl, ServiceName2.wsdl etc added in pending changes. Every project referencing "ServiceClient" gets a bag full of *.datasource files. Perhaps I generate too often. – Blanthor Jun 08 '11 at 16:08
  • Yes, that's all part of the built-in service handling stuff from Visual Studio. I think those files are there to be able to do data binding against the DataContract objects. Manually constructing the service proxies is a way of removing these files if you don't plan on using the data binding feature. I haven't used TFS in a long time but I believe you can configure it to ignore certain file types & folders. – Sixto Saez Jun 08 '11 at 17:11
  • I was wrong about where the *.datasource files were created. They all exist in a folder holding the service reference in my ServiceClient assembly. – Blanthor Jun 10 '11 at 13:35
0

Could you just reference the library in tfs which has you're service contracts, then use the contract to create a channel to your wcf service. Which would also mean you don't have to use a service reference anymore and also decouples your silverlight application from your service.

MikeRay1
  • 108
  • 7