Public / internal accessibility confusion on a web service wrapper?

Question

Hi all,

I've written a simple web service that converts a word doc to a pdf. As part of the Convert method, it takes in a custom settings object that contains info about the doc path, etc. and a DataTable of, er, data.

I am now creating a "helper" class to consume the web service in order to remove the hassle for other developers and, if truth be told, control the consumers of the web service. I don't want anyone diving into the web service (even a developer) and using it willy-nilly.

Let's call my web service WordToPdfWS and my helper class WordToPdfHelper (ugh); WordToPDFHelper has a web reference to WordToPdfWS and can call the Convert(settings) method no problem (it even works!).

When I create a consumer / test app and set a reference to WordToPdfHelper, I find that (as expected) I can create the WordToPdfHelper object and use it as intended. BUT, in my consumer, I can also create my web service (WordToPdfWS) and call it directly - from my consumer!

This is definitely not what I want (e.g. any Tom, Dick and Harriet Developer being able to get at it), is there anyway to prevent it?

Kind regards,

Mike K.

Answer 1

My guess here is that you have your webservice instance on your helper declared as Public. You would want that to be either private or internal.

Answer 2

Interesting problem. The ideal scenario is one where you limit access to the WS proxy stub within the lib, but can also use the auto-generated code. The auto-gen'd code just happens to produce its output as public, and updating that code file is undesirable.

I believe you can find a solution by employing techniques for code access security. You can restrict code access using the Framework's structure for cross-assembly calls.

Implementing the code access security, whether it be on the class or method level, could be accomplished using a partial class that mirrors the auto-generated stub class (by namespace and name).

Your stub class is already a partial class (assuming it was generated with Visual Studio). Creating a separate partial class file and employing code access security could theoretically provide the wrapper restriction you're seeking, plus stay in lock-step with the internal web service stub while staying out of the way of future updates.

I haven't tried this, so your mileage may vary.