I was working on an article for one of the MSDN developer centers this week and wrote a little WSE web service in C++. The sample code had the SoapActor attribute attached to the web service, which really shouldn’t be a big deal, but as it turns out, it is.
The rather inconspicuous lines
[SoapActor( "soap://wse.bracketangles.net/secureecho" )]
public ref class SecureEchoService : public SoapService
produce the following error:
d:\christoph\C++\WSEConsoleService\SecureEchoService.h(8) : error C2364: 'System::Uri': illegal type for custom attribute
d:\christoph\C++\WSEConsoleService\SecureEchoService.h(8) : error C3725: 'Microsoft::Web::Services2::Messaging::SoapActorAttribute': cannot resolve attribute overload could be 'Microsoft::Web::Services2::Messaging::SoapActorAttribute::SoapActorAttribute(System::Uri __gc *)'
'type': illegal type for custom attribute
Names arguments for custom attributes are limited to compile time constants. For example, integral types (int, char, etc.), System::Type*, and System::Object*.
And what the error documentation states is true, not only for C++ projects, but for other languages like C# as well. However, if you look at the line of code with the SoapActor attribute again, you’ll agree that the parameter passed to the constructor is indeed a compile time constant of type String^ . Furthermore, look at WSE docs and you’ll see that there is a constructor for the SoapActor attribute that accepts a parameter of the type String^ … well yeah, or how would the Soap Actor attribute work properly with C# projects?
The source of the problem is the C++ compiler sees the constructor overload with a parameter of type Uri, which has a constructor that takes a String^ , and thus picks the wrong constructer overload – the one that takes a Uri – for the Soap Actor. A Uri parameter cannot be a compile time constant because it’s allocated with gcnew and therefore compilation of my web service fails.
Upon further investigation, it turns out that even the C++ compiler in Everett, i.e. .Net 1.1, exhibits the same behavior and there is currently no work-around. The bug will be fixed in an upcoming Whidbey build, but for now, me, and everybody else who wants to develop a WSE Web service with the SoapActor attribute in C++, has to wait for Microsoft to issue a hotfix.