Contents tagged with WSE

  • C++ support in WSE 2.0 SP2

    No Comments

    WSE 2.0 SP2 adds some support for adding WSE to C++ projects, which had been missing since the initial release last May.
     
    At last, the WSE Configuration Editor, the one that comes up when you right-click in the Solution Explorer and then select WSE 2.0 Settings allows you to enable and disable WSE for C++ project and lets you create policies.
     
     
    Before SP2, nothing would happen when you clicked on the item in the context menu. Unfortunately, other IDE integration, such as automatic generation of WSE proxies in a WSE enabled project is still not happening and probably will never happen in WSE 2 because wsewsdl2.exe does not support generation of C++ code. If you take a look with Reflector, you'll find that for some reason, the tool does not emit the proxy code via CodeDOM, hence it would be really difficult for the WSE team to generate C++ proxy classes.
     
    A general shortcoming of the IDE integration of the configuration tool, that's not specific the C++ projects are the relative references generated for the policy files. When you enable policy for a C++ an application project (not a web service), the tool will add
     
    <policy>
    <cache name="../policyCache.config" />
    </policy>
     
     
    to the application's configuration file. Unfortunately, the relative reference would only valid during development -- if C++ projects behaved like C# projects in the first place. When you deploy the application you most likely will not have the policyCache.config file one directory higher than the application and its config file. To complicate matters a little further, C++ application projects behave differentely than C# of VB.NET projects in Visual Studio. C++ projects don't even copy the app.config file to the output directory. The best solution is to delete the relative path information from the path to the policyCache.config file.
     
    <policy>
    <cache name="policyCache.config" />
    </policy>
     
    and then add a post build event to rename app.config and copy it, together with the policyCache file to the output directory:
     
    copy $(ProjectDir)app.config $(OutDir)\$(TargetFileName).config /Y
    copy "$(ProjectDir)policyCache.config" $(OutDir)\ /Y
     
     
    Changing the path and letting the post build event do the work for you also helps when you build an installer. Simply mark the policyCache.config file as "Content", add "Content File" to the installer project and you're ready to go.
     
    Finally, when you build and ASP.NET Web service in C++ you have to make sure that the policyCache.config file is deployed to the web server.
     

    Read more...

  • ANN: Talking in Austin on 12/13

    No Comments

    I am giving a presentation on Secure Web Services and Secure Office Productivity Solutions based on IBF at ADNUG's December meeting on 12/13. 5:30pm at the Microsoft Technology Center:
     
    About the presentation:
    Web services are making their ways into the enterprise. Yet, Web service technology is continuing its evolution into a mature, full-fledged platform for feature-rich and secure enterprise applications.
     
    This talk presents two second-generation development frameworks: Web services enhancements (WSE) and the Integration Bridge Framework (IBF). WSE adds a number of improvements over the Web services support built into the .NET Framework namely:
    ·  Support for the WS-Security family of specifications
    ·  light-weight Web services without requiring the IIS web serve
    ·  Improved support for message-oriented message exchange patterns
    ·  A declarative, policy driven programming model based on WS-Policy
     
    IBF is an application framework to enhance productivity of information workers by integrating Web services directly into Microsoft Office 2003 documents, such as Word documents or emails displayed in Outlook. Bringing data from other applications directly into office documents eliminates the need of switching between different applications offers and thus streamlines business processes.
     
    Together the two frameworks deliver a secure platform for effective and secure productivity solutions. The talk examines the need for security in a Web services environment and introduces the capabilities of WSE and IBF 
     
    For more details on ADNUG and our monthly meeting schedule please visit http://www.adnug.org.
     
    Hope to see you there.

    Read more...

  • WSE and problems with the C++ compiler

    4 Comments

    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 *)'
     
    When you look up the error in the framework documentation you’ll quickly find:
     
    '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.
     
     

    Read more...