В общем случае управление версиями веб-службы - это больше, чем просто имена методов контроля версий и имена файлов .asmx. В идеале интерфейс к веб-службе (его WSDL) должен быть постоянным контрактом и никогда не должен изменяться. Одним из последствий этого будет то, что клиентам, которым не нужны измененные функциональные возможности, никогда не потребуется изменять, и, следовательно, никогда не потребуется повторное тестирование.
Вместо того, чтобы нарушать существующий контракт, вы должны создать новый контракт, содержащий измененные операции. Этот контракт может «наследовать» от существующего контракта, то есть вы можете «добавить методы в конец». Однако обратите внимание, что вы также должны поместить новый контракт в новое пространство имен XML - пространство имен в основном идентифицирует WSDL, и сохранение пространства имен, но изменение WSDL было бы ложью.
Затем вы должны реализовать этот новый контракт в новой конечной точке (файл .asmx). Находится ли это в другом каталоге или даже на другом веб-сайте, не имеет значения. Важно то, что клиенты, которым нужны новые функциональные возможности, могут ссылаться на новый WSDL по новому URL-адресу и вызывать новую службу по новому URL-адресу и быть счастливыми.
Имейте в виду, что одним из последствий изменения существующего контракта является то, что при следующем выполнении «Обновления веб-ссылки» вы будете изменять код клиентских прокси-классов. В большинстве магазинов изменение кода требует повторного тестирования и повторного развертывания. Поэтому вы должны думать о «просто добавлении методов» как о «просто добавлении некоторого клиентского кода, который должен быть протестирован и развернут», даже если существующий клиентский код не использует новые методы.