У нас есть веб-сервис с именем, допустим, Foo.
Итак, есть файл Foo.svc и код позади Foo.svc.cs.
Мы добавляем проект silverlight и хотим использовать службы Foo.svc, поэтому добавляем ссылку на службу и вызываем это пространство имен FooBar.
Это создает следующие файлы:
С течением времени мы обновляем Foo.svc и добавляем больше веб-сервисов (методы и интерфейсы), а количество файлов в каталоге FooBar растет.
У меня есть 26 Foo (nn).xsd файлов в этом каталоге - где nn = от 1 до 26.
My configuration.svcinfo имеет конфигурацию91.svcinfo.
Мой вопрос в этом? Нужно ли управлять одним из этих файлов? Могут ли все они быть удалены каждый раз, когда вы выполняете сборку \deploy (пока вы выполняете ссылку на службу обновлений)?
Эти xsd файлы - это всего лишь метаданные вашей службы, которые использовались только при создании или обновлении служебной ссылки. Фактически вы можете удалить их, поскольку они просто использовались при создании ссылочного файла. Нет необходимости в контроле версий этих файлов.
Файл Reference.svcmap является практически определением справочной службы. Он содержит различные настройки, а также ссылки источника. Ссылка .svcmap определенно должна быть контролируемой исходным кодом, потому что она на самом деле является ссылкой службы в смысле элементов проекта.
Reference.cs содержит сгенерированные контракты и прокси, с которыми скомпилирован ваш код. Независимо от того, следует ли контролировать исходный код или не контролировать исходный файл, этот файл зависит от вас. Как правило, это часть кода проекта и должна контролироваться источником, но, будучи автоматически генерируемой, иногда может привести к случайным нарушениям.
Все остальные файлы - это ВРЕМЕННЫЕ файлы, используемые при создании контракта и прокси-кода. Вместе они образуют сумму метаданных, предоставляемых службой, которая включает в себя контракты на обслуживание (*.wsdl), контракты данных (*.xsd) и информацию о конфигурации (*.svcinfo).