#wcf #c#-3.0 #intellisense #sandcastle
#wcf #c #-3.0 #intellisense #sandcastle
Вопрос:
Я пытаюсь добавить документацию, совместимую с IntelliSense и SandCastle, к моим прокси-классам WCF, которые были сгенерированы с помощью svcutil. Есть ли какой-либо способ сделать это без прямого редактирования сгенерированного кода (поскольку он будет потерян, если он когда-либо будет восстановлен)?
Ответ №1:
В проекте WCFExtras вы можете найти искомую функциональность; экспортер и импортер WSDL, который берет документацию по XML-коду и внедряет ее в WSDL извлекает ее и снова добавляет в виде XML doc на сгенерированный прокси-сервер на стороне клиента.
WCFExtras можно найти здесь:http://wcfextras.codeplex.com / (или в виде пакета Nuget).
—larsw
Комментарии:
1. Это лучшее решение, которое я слышал до сих пор. Я приму ответ, как только у меня будет время его протестировать.
2. WCFExtrasPlus перешел на GitHub. Здесь: github.com/lamronby/wcfextrasplus
Ответ №2:
Ограниченным решением может быть создание документации только по частичным классам, чтобы отразить классы, созданные SvcUtil. Поскольку классы SvcUtil создаются как частичные классы, вы можете воспользоваться этим для документирования класса, но это, вероятно, не сработает для методов или свойств. IntelliSense отобразит комментарии. Я полагаю, что SandCastle также объединит комментарии, но не пробовал. Синхронизировать эти классы с изменениями в службе может быть непросто, если вы хотите пойти по этому пути.
Вот как будет выглядеть класс documentation:
/// <summary>
/// This is a comment
/// </summary>
public partial class YourSvcUtilGenerateClientClass { }
Комментарии:
1. Мне нужно задокументировать методы, свойства и т.д. У меня есть много классов DataContract, для которых я хочу правильно документировать свойства.
2. К сожалению, нет простого способа напрямую добавить документацию /// к вашим методам и свойствам без повторного создания прокси вручную. Я думаю, что есть способ создания внешних ресурсов документации для использования sandcastle, но я не думаю, что это помогло бы с IntelliSense. Для IntelliSense вам понадобится что-то вроде инструмента для внедрения документации непосредственно в скомпилированную сборку.
Ответ №3:
Я думаю, вы можете переопределить способ создания этих классов с помощью шаблона. Вот ссылка на статью, в которой говорится. Они сосредоточены на silverlight, но я думаю, что контекст кода все еще применим.
Ответ №4:
Лично я никогда не использую сгенерированные прокси-классы WCF. Слишком просто создать свой собственный прокси-класс. Это все, что требуется (методы могут быть добавлены для вас Visual Studio при добавлении интерфейса ServiceContract в ваш прокси-класс):
using System.ServiceModel;
namespace My.Namespace
{
public class MyServiceContractProxy : ClientBase<IMyServiceContract>, IMyServiceContract
{
public MyServiceContractProxy() { }
public MyServiceContractProxy(string endpointName) : base(endpointName) { }
#region IMyServiceContract Members
public int AddValues(int val1, int val2)
{
return Channel.AddValues(val1, val2);
}
#endregion
}
}
Если ваш ServiceContract изменится, это выдаст ошибку компиляции, потому что ваш прокси больше не будет соответствовать интерфейсу, но обычно редактирование вашего прокси-класса занимает не более 10 секунд.
Комментарии:
1. Используете ли вы общую библиотеку dll для хранения интерфейса или просто генерируете интерфейс из WSDL (используя svcutil)?
2. Я намеренно избегал использования общей библиотеки dll из-за того, что меньше узнал об управлении версиями WCF.
3. Ах, это звучит как боль, с которой мне не приходилось сталкиваться. Если наличие общего интерфейса не является вариантом, то я думаю, что подход с частичным классом был бы правильным решением.
Ответ №5:
Поскольку маршрут комментариев XML не соответствует вашим потребностям, то Document! Продукт X 2011 был бы выбором. Это не бесплатно, но оно сделает то, что вам нужно.