I have to call a webservice published in the same website the caller aspx is.
When I try to "Add a Web Reference" the editor does not show the webservice methods from the generated namespace.
Do I have to use the "Add Web Reference" or is there another way because the webservice is in the same website?
Visual Studio 2005, C#
Thanks,
Eduardo
I used the way that Andy Rose wrote in comments:
Instantiate the webservice class and call the methods directly because it is accessible inside the project (no need to add web reference).
There are ways to trick it... You can deploy the app with the web service, then add reference to the deployed location.
Another idea is to just start it using ctrl-f5 so as to not start the debugger as well, then add a reference to your localhost:/.asmx
This will get all of the configuration information created in your web.config which, of course, you can modify later as necessary.
The Webreference itself is just a proxy implementation so that VS can pretend it knows how your webservice will react to calls to it (so you can compile), you can actually code without them (though it is much harder :)).
You have a few of options, that I can think of, if you want to do this:
Create your webservice as a separate project, but deploy it to the same location. You will get mixed binaries in the bin directory, but otherwise it should work fine. In this way you can deploy each separately as needed.
Consider pulling them apart into two separate applications. This might not be available for whatever reason.
Create a stub webservice in your main project, which only has the function definitions (return type and parameters) and deploy that, then generate your webservice against that. You can then begin your development against the prototype and fill it in as necessary
Do the two-step shuffle as Chris suggested. First create a approximate representation of your webservice, deploy it. Second create your proxy against it, create your web app, deploy it and test. Repeat as necessary.
Once your proxy is created you can change the URL it points to in the proxy bindings.
Related
I could have sworn I saw this done somewhere, but I guess maybe it was a DLL, not a web service. I was originally doing this as a DLL, but now need to use a web service.
I have a service file (DataService.svc). I have class Foo and class Bar. Both have the same methods (Load, LoadAll, Insert, Update). I know that a web service doesn't support overloading, but I thought that since these were in separate classes it might be possible. Is there a way to configure this so that in my client, I could do this:
DataService.Foo.Load();
or
DataService.Bar.Load();
Thanks,
Andrew
Ok so I have built my WCF service and its functioning great! However, I am starting to implement it into our pre-existing piece of software now and I am instantly running into the question, do I only use the proxy generated code and get rid of the dll that I used initially? Or do I keep both, and make distinctions between the two very obvious?
What I mean by keeping distinctions is, having a ServerUser and a LocalUser property that represent the same user object. However, my LocalUser property would be filled via the dll that the app initally ran with, if the application service is unavailable.
My main reasoning for this thought pattern is that if I remove my dll, I have a single point of failure. If for some reason my ServiceHost is just not up and running, but the DB server is, I would want my users to still be able to do their job. The features that the new WCF implementation utilize are not dependant for employees to do their job. It is more of a convenience in what the WCF service provides. Also, building in this kind of logic to the Service would allow service modifications more readily available in a non IIS hosted environment.
Also, is there a way to build in logic on the service so that when I pull down the proxy code for the client that it just knows to access the DB manually if the ServiceHost is unavailable? If this was a possibility, I think about 90% of all my problems would disappear.
Thank you in advance!
From what you describe it sounds like keeping your existing DLL, i.e. direct access to the DB, would best suit your needs. Having a WCF service adds nothing if, when it fails, you'll just use the DLL anyway.
Ideally you would go with the WCF service completly and offer some kind of redundency to deal with any potenial service issues. Plus, using a service will mean you won't have to deal with any DLL upgrades/deployments.
But, from your question, it sounds like there would be some real issues to deal with should the service not be available, so just do with the DLL.
EDIT: Just read the last part of your question and I don't think that is possible. The proxy code for accessing services is generated when you add the reference to your project. The kind of "dynamic" information you're after would actually require a service.
EDIT: As a follow up to my comment below you could test this by creating a DLL and class, lets call it Class1. Then create a WCF service with a method that will return Class1. Create a client application and add a reference to the service. If you look at the proxy-generated code you should see (hopefully...I'm thinking of this as I type :)) that the method returns Class1, but when you compile it won't be able to find Class1. This is because Class1 does not have the DataContractAttribute which would auto-generate Class1 on the client. So, you have to distribute the shared DLL to the client. Now when the method returns and WCF tries to re-create Class1 it will use the local version in the shared DLL. Your other DLL, which will already be on the client, would use the same shared DLL.
I was trying to follow the instructions here but they seem to quickly be getting very specific to Sharepoint, as they go along further. I just want a general tutorial for creating a non-sharepoint SOAP starter projects, and Google is not my friend, at the moment.
It seems that some of the above steps are applicable.
So far I have:
A solution 'WebSite1' created with File -> New Website.
A 'ClassLibrary1' project in C#, with System.Web.Services added to References.
a key02.snk (strongname key file) file node in the classlibrary1.
No code implementing any SOAP server methods yet.
No idea how to add code to the above, and then build and run, and have a soap hello-world type method.
I'd like to implement a simple HelloWorld method that takes at least one parameter. The resulting service could be queried for its WSDL with a url like this:
http[s]://localhost/myfirstsoapserver/helloWorldMethod1.asmx?WSDL
If my guess above is right, the above Url would be usable by any tool that can import WSDL.
My goal is rapid prototyping and mocking up of various other SOAP interfaces that I need to deal with, and I'm hoping that C#+visualStudio2010+IIS is a reasonably easy way to do that.
First create a new project as a web application:
Then add a new item of type web service:
Have you considered using WCF?: http://msdn.microsoft.com/en-us/library/bb386386.aspx
I need to consume a SOAP web service from a C# .Net 4.0 client. I've added the WSDL as a Service Reference in VS 2008 and can now see the XML types as classes so I can construct the SOAP message.
The WSDL Port is defined as an Interface and the two operations defined in the WSDL (UploadMessage and ValidateMessage) are visible methods.
How do you actually use these methods? I thought the Port would be available as a class so you could directly call the methods and that VS would have created the relevant code for sending the SOAP message, but it looks like you have to write code to go in these methods. Is that correct?
I have googled this but can't find a simple example using .Net 4.0 ;-(
When you add your service using Add Service Reference, you should have a new namespace (which you defined in the Add Service Reference dialog box - bottom left corner).
Inside that namespace, there ought to be a class called something like (yourservicename)Client.
If you can't find it, open up the Service References node in your Visual Studio Solution Explorer, and find the Show All Files button in the Solution Explorer's little toolbar - click on it to see all files.
Under your Service Reference, several nodes deep, you should find a file called Reference.cs which contains the code classes generated from your WSDL.
In that Reference.cs, you should find your client class. This is a regular class, which you can instantiate in your code and call methods on. This will call the web service methods on that remote server you want to connect to.
Typically a Service Reference will create a class called [ServiceName]Client that implements the interface you mentioned.
New it up, then call the operations.
Of far greater importance than getting the client and calling it will be your configuration, which will be dependent on the service. This article will help.
When I add a Service Reference to my project in Visual Studio, it autogenerates a proxy to the service called ServiceNameClient. I really don't like that naming scheme. Is there a way to change it to something like ServiceNameProxy?
I can rename the class myself in the autogenerated code, but any time I add new features to the service, and go to UpdateServiceReference, it re-generates the code and changes it back to the old name.
My brief web search uncovered a way to create my own WCF Proxy Generator class, but I'm hoping there is some simple attribute that changes how the class name is calculated.
Like you, I have been dissatisfied with Visual Studio's code generation of the WCF service reference. I never have liked the naming scheme, and I also don't want to change it every time I update my service.
To answer your question, I don't know if there's a way to change it or not. But I had an epiphany after watching this video at dnrTV. Since then, I've been manually coding my WCF client proxies using a naming scheme that fits my project.