28

I am new to both WPF and WCF, and have a WPF app that has a service reference to a WCF one. I have all sorts of files created under Service References/MyService. I am not so sure which need to go into source control and which don't.

I have a .disco, a .datasource, a .wsdl, 3 .xsds, 2 configuration.svcinfos, a Reference.cs, and a Reference.svcmap.

I assume most are generated, yet I don't know which belong to source control and which do not.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
Kurt
  • 4,477
  • 2
  • 26
  • 34
  • 2
    @Kurt, the only file that I *know* you need at build time is Reference.cs. In fact, I've gotten completely away from having Visual Studio generate my service references. I now write the client-side code manually, which is **much** easier than it would appear. Watch this video for details: http://www.dnrtv.com/default.aspx?showNum=122 – Matt Davis Dec 08 '09 at 15:00
  • 2
    @MattDavis That's because you are using .NET => .NET and have access to the contract class. If you do not have the interface assembly or are working with a WSDL file, you cannot do this. I would never advocate generating client proxies if you know you're talking to .NET and have access to the contract assembly. – Travis Mar 02 '12 at 16:27
  • Possible duplicate of [scvmap, disco, xsd, wsdl, svcinfo and datasource files](http://stackoverflow.com/questions/2444753/scvmap-disco-xsd-wsdl-svcinfo-and-datasource-files) – Oyvind Jul 02 '16 at 21:04
  • 1
    Note that I flagged this question as a duplicate. The other duplicate has more relevant and useful answers than this one. Link: http://stackoverflow.com/questions/2444753/scvmap-disco-xsd-wsdl-svcinfo-and-datasource-files – Oyvind Jul 02 '16 at 21:06

3 Answers3

11

Put all of them under source control, why not?

It's part of your code and it's needed to compile the project. If you use an automated build system, then you don't want that script to generate this code again, right?

As a bonus you'll get a history of changes to your service interface, could be useful too.

Gerrie Schenck
  • 22,148
  • 20
  • 68
  • 95
  • 1
    One of the main reasons for NOT wanting this, is when working with multiple developers. Especially the .xsd files are a real annoyance when merging. – Oyvind Jun 30 '16 at 11:05
  • @oyvind so lock the files on checkout – John Saunders Jun 30 '16 at 13:52
  • @JohnSaunders: That sounds TFS-specific. Also, it does not really solve the issue with annoying "junk" files; all developers in the team needs to adopt disciplines. – Oyvind Jul 02 '16 at 20:52
  • @oyvind what are multiple developers doing that causes a problem? Don't think of files; think about your processes. Maybe break up your service contracts into smaller units? – John Saunders Jul 02 '16 at 20:53
  • We had them checked in. Now, we had to rename our parent namespace and dlls/executables, which makes these datasource files stale. We chose to remove them from our projects and repository for now. We might need them later, but we will probably not be checking in datasource files. – Ozair Kafray Oct 27 '20 at 08:30
2

All of those files are source files, so they all belong under source control.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • 1
    I was under the impression that the only one that is actually *compiled* is the Reference.cs file and that the others are used in case you need to update the service reference later. – Matt Davis Dec 08 '09 at 14:55
  • 1
    I consider them "source" files in the sense that they are not the result of compilation or other processing. – John Saunders Dec 08 '09 at 16:01
  • They ARE indeed a result of processing; most of the files are generated when updating the service reference, and are not used for building. – Oyvind Jun 30 '16 at 11:07
  • @oyvind I should have said "other compile-time processing". – John Saunders Jun 30 '16 at 13:50
  • @JohnSaunders most of them are not compile-time processing either; as Matt points out above, the only file relevant to compilation is the generated .cs files. The rest of them are metadata used at the point when updating the service reference. You can easily test that by temporarily removing all the other files. – Oyvind Jul 02 '16 at 20:57
  • @oyvind you are focused too much on the files. Focus instead on what is happening that causes the files to be a problem. Why are many developers working on the same services? – John Saunders Jul 02 '16 at 20:59
  • @JohnSaunders: the files are all about what this question is about ? It's quite normal that several developers works on the same projects. Services are being expanded, new functionality added. When adding functionality, we create new branches, and merge when done. A very common scenario. – Oyvind Jul 02 '16 at 21:17
  • @oyvind what's common is to separate functionality so that fewer developers are working on the same thing. Use separate service contracts, for instance, with separate data contracts. If they're being developed on separate feature branches, that suggests the use of separate contracts: `IFeature1`, `IFeature2`, ..., `IFeatureN` for separate branches FeatureBranch1, ..., FeatureBranchN. The same service can implement many service contracts. That way, when you merge, the merge will be clean. – John Saunders Jul 03 '16 at 00:54
  • @JohnSaunders: That would create additional mess. In some cases, we add just one method, that complements existing ones. Creating a new interface for that would just be messy and unnecessary If the goal is a clean merge. I suggest focusing on the actual question, which is really about keeping a clean repository. – Oyvind Jul 03 '16 at 10:30
  • I like the perspective, that since they are source files, they belong to source control. In, our team though we have chosen to ignore these files specifically and in general files generated by tools. We had them checked in. Now, we had to rename our parent namespace and dlls/executables, which makes these datasource files stale. We chose to remove them from our projects and repository for now. We might need them later, but we will probably not be checking in datasource files. – Ozair Kafray Oct 27 '20 at 08:34
-9

How about adding all of them to the source control in the first instance and then remove those that never change later?

Raj
  • 1,742
  • 1
  • 12
  • 17