I've just started to use VS2010 and with it comes c# 4.0.
I have since been using the default values for some of my methods, which has allowed me to remove some overloads that performed this operation.
My problem is as follows:
I have a library project that has several classes that I use for various things throughout several other projects. The default values work well here.
Another project is a web service that I use to perform some tasks on a remote server. No errors are shown (or warnings) when I compile this project that the above methods won't work. It compiles fine.
However, when I add this service to another project as a Service Reference, it doesn't seem to see that the method has default values and so complains I am not supplying enough arguments.
I re-deployed my service and updated the service reference, but it is still the same. I also just noticed that a previously working method that uses an 'out' argument (i.e.e MyMethod(out String arg1, String arg2)) doesn't seem to work either now.
Any suggestions? I'm not aware that I have changed any config settings that would do this, so I assume it must be C# 4.0. Having said that, the out argument was working with 4.0 last week :S
Thanks for any help offered...
Cheers
Neil
I wouldn't be surprised to hear that default values specified in a web service aren't reflected in the proxy code generated by Visual Studio. You could create your own proxy layer of course, which would be very simple - but you'd need to update it every time you changed the web service.
If you have a look at the WSDL for your service, does that indicate the default values? It could also be that there's a switch somewhere in the generator to generate optional parameters or not (for compatibility with C# 3).
The out parameter is potentially a different matter entirely - what error are you getting?
Related
I am trying to connect to a Soap Web service. I am very familiar with C++ , but this is the first time I try anything related to the web. I would like to use visual studio. Can anyone explain how to do it?
Can anyone explain how to do it?
Some notes (this is not a complete list/howto, but more of a guideline):
First, you need to choose a SOAP client library for C++. The best out there (or not the best - that's debatable) seems to be gSOAP.
For gSOAP (the library I am familiar with):
Second, (with gSOAP) you can generate a code base particular to the SOAP endpoints you need to connect with.
Third, add a project in Visual Studio ("project A") that links against this generated code, and hides it's interface behind it's own (A's) interface. This is not mandatory, but it is good practice, ensuring that changes to the generated code, do not force you to recompile your entire code base.
DO NOT EDIT the generated code. That would ensure you can no longer regenerate it, or that when you regenerate it you will have to apply all your edits again. If you have any workaround or processing to be done on requests/responses, implement those in Project A.
Then, write your code based on your Project A.
I have developed a WebService in PHP using SoapDiscovery class made by Braulio José Solano Rojas but with some adjustments made by me in order to support complex types.
The problem is that I can use the webservice in PHP client, but not in VS 2012. When adding the Web reference, Web Service methods are detected and I can add the reference correctly, but when I try to use it, intellisense does not show it, so that I cannot instantiate it and do nothing. I can, however, use a Webservice that does not use complex types.
The WSDL is at: http://feriados.servicios.desytec.com/feriados?wsdl
Please advise me.
I am building webparts and self hosted apps for sharepoint 2013, I want to consume the Query String filters that the user sets up, the process should be as simple as specified here on this microsft site.
Unfortunately I dont get the option to send values to 'my web part' but I do for other stock webparts that come with sharepoint. Which leads me to believe I need to implement IFilter or equivelent in my webpart, I have found information into IFilterConsumer interface and IFilterProvider interface on msdn which seems to be exactly what I need, however the documentation has one snag:
NOTE: This API is now obsolete.
So My question is, what is Microsofts new intended way of doing this with Sharepoint 2013.
Ultimately I need to read query variables in the HostWeb request inside my AppWeb code.
Edit: Apparently IWebPartParameters is the new interface for this.... trying to implement now.
I have also tried whats suggested here:
Passing parameters through sharepoint sitepage to web part Still not working, at the moment I have implemented IWebPartParameters, IWebPart, IWebPartRow and none of my functions that implement these interfaces are being called. I must be missing something in the manifest or features file maybe?
Thanks in advance
Crash
Ok the answer to this question is simple, firstly you can only do this in a dev environment with sharepoint installed, as you need access to the sharepoint.dll.
Then this thread answers the question http://www.manning-sandbox.com/thread.jspa?threadID=19791, with the following code solution which is here http://www.markitup.com/BookCodeSamples/TestingWebPartConnections.zip
I have ported over some code from a Windows application to Monotouch.
It is using ASMX Web Services to talk to some API.
The code fails on Monotouch 5 because the method
System.Web.Services.Protocols.SoapHttpClientProtocol.GetWriterForMessage()
is never called.
I have seen that in Mono you will even get a NotImplementedExeption but not in Monotouch. It simply gets ignored.
I need to find a way around this. I have to add custom headers to make the solution work.
Any workarounds or maybe is there even a chance that this will be fixed soon?
(I also filed a bug report, but I'm asking here because I am desperately looking for a workaround).
EDIT:
I found kind of a workaround but it is very annoying to use.
In the auto generated reference file you will have to decorate each and every method with
[SoapHeader( "SessionKeyHeader", Direction = System.Web.Services.Protocols.SoapHeaderDirection.InOut )]
Then implement the custom soap header class but skip the GetXmlWriter() method.
A bug has been filed at Xamarin about this issue.
The situation:
We have a library project that houses much of our code for the various integrations we work on. Many of the integrations consume web service apis, and my supervisor doesn't want 5 gazillion web service references added to the project.
What we generally do, then, is add a reference to a new project and copy the References.vb to the solution and just call the generated code. Not terribly convenient if changes are made to the service, but it works.
Recently, I ran into a problem where we have to use 3 web services for the same integration. 2 of these contain the same class definitions, however, they're in different namespaces because they belong to different services. This became a problem for me because one of the services searches a user based on user ID, and the other pulls back blocks of users. Both return an object, or list of, that is exactly the same semantically. And I need to process the data the same, whether it came from one service or the other.
My solution, was to strip out the duplicated classes in the service and replace them with classes inherited from common base classes. This allowed me to work with both objects as if they were the same, however, it required modifying the generated web service proxy. Therefore this change will need to be made every time I need to regenerate the proxy.
I'm curious what you all might think a better solution to this would be.
You're going to regret playing games with copying Reference.vb and editing generated files.
Switch to WCF and you'll be able to tell it you want to reuse the types, instead of having multiple types that are more or less the same.
BTW, they would be "less" the same if not all of the web references are updated at the same time after a server change.
The other option would be to build an abstraction layer over top of the web service pre-generated proxies, such that when you make to the calls to the abstraction layer you can always use the same objects, as they are squeezed into (and out of) the web service proxies in the abstraction layer. This would also allow for unit testing :)
I think you really should be looking at WCF for 3.5+, but for .NET 2.0 look at something like WSCF (Web Services Contract First), which defines the contracts in XML and generates a set of libraries reusable across services. E.g You define a MyComany.WS.Common namespace and use that namespace in multiple projects. The code generation then builds a shared library of types which get used across all the web-services. We use this extensively in our .NET 2 solutions and it's great. We had to do some additional work around the code generation to get it to fit into our build process, but once that was done we never looked back.
We're migrating to .NET 3.5 over time, so the WSCF will become obsolete
Heres the link to the thinktecture site for WSCF.
wsdl.exe using the /sharetypes switch allows the same types to be used across multiple service definitions, provided the wire signatures are not correct. I was unable to use it in my situation, though, because the various wsdl contracts were carelessly namespaced.