Important Notice from AspDotNetStorefront
It is with dismay that we report that we have been forced, through the action of hackers, to shut off write-access to this forum. We are keen to leave the wealth of material available to you for research. We have opened a new forum from which our community of users can seek help, support and advice from us and from each other. To post a new question to our community, please visit: http://forums.vortx.com
Results 1 to 4 of 4

Thread: Consuming WSI remotely

  1. #1
    Emissary is offline Member
    Join Date
    Sep 2008
    Location
    Florida
    Posts
    60

    Default Consuming WSI remotely

    I didn't find another thread that would help me with this so here is mine.
    I have configured WSI on my e-commerce website and would like to enable distributors to use a customized website I created to manage shipping information for orders I send to them.
    I have consumed WSI within the office with some c# apps I created and it worked great. I also remember having a problem where I needed to fix resource.cs file in order to get it to work right. I think it was not able to see the AspDotNetStorefrontImportWebServiceWse.
    So I can't determine what I need to do to get my web app to be able to use this, because I dont find any reference.cs within my web app.

    Please help. Thanks.

  2. #2
    George the Great is offline Senior Member
    Join Date
    Nov 2006
    Location
    Cleveland, OH
    Posts
    1,792

    Default

    AspDotNetStorefrontImportWebServiceWse is an added section that references Microsoft Web Services 3.0 in order to use the Username Token Management for security purposes. The reference.cs file that you are looking for, can be found in the WSI test application that you can download at http://manual.aspdotnetstorefront.com/wsi.

    Alternatively, adding a web reference to the web service URL will create the reference.cs file for you, but again it will be missing the AspDotNetStorefrontImportWebServiceWse section. You'll have to retrieve that from the reference.cs file from the test application download and merge that section into the one created.
    <a href="http://www.aspdotnetstorefront.com">Shopping Cart Software</a>

  3. #3
    Emissary is offline Member
    Join Date
    Sep 2008
    Location
    Florida
    Posts
    60

    Default Web site vs Web application

    I think I see what is happening...
    In Visual Studio I created a website (not Web Application) and it is this website that I was wanting to build interaction with the e-commerce WSI. Apparently, when I add a web service reference to a Web Application - then I see a reference.cs file becomes part of the solution. But when I add a web service reference to a website, it does not add that file along with the rest to the solution. Is there a way in which we can complete our web site project to work securely with the WSI without making a Web Application?
    Another thought I am wondering about - if we forgo WSE and use clear text instead...does this open us up to potential hacking and abusing of our WSI?

    Is there a standard that we should be following?

    Thanks

  4. #4
    Dusty is offline Member
    Join Date
    Jun 2009
    Posts
    176

    Default

    Visual Studio does actually create the proxies for the service references in both Web Applications as well as Web Sties (though I think you're right that it doesn't add a .CS file for the service reference in a website). When you add a service reference to a Web Site it will generate a namespace with the same of the reference (by default ServiceReference1) which will contain all the proxy classes.

    Any time you forgo encryption you do take something of a risk. How big that risk is depends upon the application. If the application will be communicating across the Internet communicating via cleartext probably shouldn't even be considered. If the application will only be communicating within your internal network the risk is significantly less and communicating via cleartext might not be too unthinkable, dependent upon how heavily secured your internal network is.

    Dusty
    ASPDotNetStorefront Staff