I'm calling a WCF operation and was running into the classic circular reference issue where my primary object (Persons) included a reference to another object (Reminders) which I need to contain a reference back to Persons. I fixed this using ReferencePreservingDataContractFormatAttribute (documented well online if you Bing it). And the fix works great for calling my service from my website project. When I attempt to call it from WCFTestClient, however, I get a Stackoverflow Exception. If I take off my .Include("Person") in my service operation then it works just fine in both. Does anyone have any ideas why this might happen? I compared the serviceModel sections of the config files to be sure there were no significant differences. Thanks for any ideas you can provide.
Keeping in mind that it works from your website project but not from your test client there are 3 possibilities:
You have not updated the service reference in your test client (9 times out of 10 that is the problem)
There is some other bug in your test client
The call from your test client uses different parameters and is therefore returning different data.
Related
I have a Silverlight 5 app. This app has been in development for 18 months. This app calls back to a WCF service. I just had a support request.
Before today, the service would return ObservableCollection<T> results. However, now all of the sudden, out-of-the-middle of nowhere, it starts returning T[] results after I updated the service reference in the Silverlight app.
My question is, what could have happened that would cause this change? This has caused approximately 70 errors due to type conflicts. Am I overlooking a basic setting?
Thank you!
If you're using a service reference to communicate with the service, make sure the Data Type hasn't been changed. Right click on the service in the Service References folder, select Configure Service Reference..., and look at the Data Type - Collection type:. If it's System.Array, then this may be your problem. Change it to ObservableCollection and see if that helps.
Ok, let me first state some facts:
This is a web service that has been working. There are several .svc endpoints all of which worked. Right now though there's one that is not, meaning I can make method calls to it when I consume the service through another project but I keep getting null back as a result.
The code for the methods in this service that continually sends back null HAS NOT CHANGED
I did mess around with the endpoint configuration pointing it to a couple different servers. I tried the original server it was pointed to also. No matter what I can update the service fine but even if I set it back to the old endpoint path, I still get null back from my unit tests when testing calls to this service. The unit tests are running in the project that's consuming the service of course
I've checked the app.config and web.config for the service itself. As far as I can see everything looks fine...but again I'm new to WCF
I know this is pretty general but I'm looking for some guidance on where to start looking to see why I'm getting null back all of a sudden. The stored proc behind these methods have not changed. Again these method calls were working at some point in time in the past week but now it isn't.
This is very general, but a few things to try...
Try updating your service reference to ensure you have the most recent version of your proxy objects
Have you tried debugging inside your service and seeing if the expected return value is being returned from the service prior to the client getting it?
Do you catch all exceptions in the service and then return a result object or do you let exceptions fall through? If you let them fall through, the WCF channel might be getting faulted.
Try using Fiddler and seeing if the endpoints you think should be getting called are and if the response object is indeed null.
Use an old-school trick and write the result to a file on the server just before you return to the client. This will help you know whether or not it is a server-to-client serialization issue. You may even need to write to file right as the service gets the call to make sure your client is connecting.
What you really need to do is start by debugging inside your service and stepping through the code there. Make absolutely certain the SPROC is returning what you expect and then there isn't an environmental bug introduced.
When you have weird problems with WCF, the fist thing to do it configure WCF tracing. It's a very powerful tool. You can even see the content of messages.
Here is the official doc on this: Configuring WCF Tracing
I have a WCF web service that I am working on and I built it and was delighted to find that I could use complex types in it. I added some and then realized that they were still not useable as those types on the client end. This is an internal web service so these types are known on both sides. Anyway, that's not the problem, as I took the complex types out, but I think it may have left some residual issues.
When I then changed my additions to all be base types (string, date, int, etc) then added the web service to the client project, I got a "[enumtype] is already defined" error. It occurred in the reference.cs file so I opened it up. Sure enough there were duplicate enums. Plus there were a bunch of helper (serializing) functions. The duplicate enum was from code that had been in there before I picked this web service up to work on. It had not caused an issue previously.
I opened up the reference.cs for the previous (successful) service reference. It did not have the duplicates or functions and also I noticed a difference between the entries that were in there. The reference.cs that was failing to compile had this additional attribute in several places:
[System.ServiceModel.XmlSerializerFormatAttribute()]
I also see that my new failed code was using string[] and the old was using ArrayOfString. I did not intentionally change this, but must have somehow set something differently in the process.
Does anyone have a few clues?
Thanks!
Have you tried deleting the service reference from the project and re-adding it? You may have to manually remove some (or all) of the serviceModel contents too. If that is the only Service Reference then definitely remove the serviceModel element contents too.
Once its all gone, re-add the Service Reference. If you're still having problems then it may be that the service metadata is generating invalid WSDL causing the duplicate enums.
UPDATE: Just for verifying the WSDL is not valid, you could try creating the service proxy manually using the SvcUtil command line utility. It generates your proxy code like Visual Studio does and may give you more troubleshooting info.
After a lot of experimentation this is what I found out:
Our web service up to this point was using the Request / Response classes for input and output. There were required in 1.0, and were a carry over from that. I attempted to create a simple entry point that sent in a string and returned a string. This compiled ok, but:
Although you can use regular types for input and output, if you are using Request / Response types exchanges for other entry points, then you cannot.
Mixed method of request / response and regular types will compile, but it will not successfully import (at least into Visual Studio 2008). What ends up being created seems to be an attempt to create input and output classes for all of the functions to translate them to their complex types, along with the Request / Response types which creates duplicate entries and will not compile.
This then also means that you cannot send in a request object and return a string (which is how I found out that this was not allowed) – this generated an error in the unit test, which started me down this path.
So if you have a request / response web service, all functions must follow that protocol.
I have a WCF web service deployed on azure. When I consume it using WCFClientTest, I successfully get return data after invoking my methods.
But when I try to consume it through WP7... it returns nulls (collections of objects are expected, either empty or filled with objects of course).
I've read over the internet that lot of people had such problems, but couldn't find a straight fix to this, I restarted Visual Studio to get rid of the well known warning related to the web service reference while developing for WP7 but it didn't help at all, and my code has no warnings left.
I guess it's a problem with serialization or maybe security... I really don't know
Did anybody run across such an issue already ?
Any directions to solve it ?
PS: I deploy on emulator
Edit:
In order to back up my question, I'd like to let you know that I've just tried using a method that returns a simple string and this works. So the problem is with collections.
I have an existing asp.net application that talks to load balanced wcf services (iis hosted, in app pool running under account configured as servicePrincipalName, etc.). The wcf services return a few custom faults, all defined with FaultContract(typeof(x), ProtectionLevel = ProtectionLevel.None) -- these services are not exposed to the public. The client uses the 'service reference' generated classes to access the services.
This has worked fine but now, with the latest code base, we are getting "The primary signature must be encrypted." exceptions on the client when the service returns one of these faults. The service code and configuration is unchanged (at least the legacy parts that generate the faults). The client side service reference generated code appears the most changed (it often gets removed and recreated).
The security configuration is unchanged for over a year. All the updates are pretty current. We've tested this in three environments and as soon as we deploy the new code base, the faults start generating exceptions. Seems like it has to be in the generated classes but they are generated by Visual Studio so it is very perplexing.
Does this sound familiar to anyone? Any suggestions?
Update: Removing the ProtectionLevel attribute and allowing it to default makes the problem 'go away', but I am curious why specifying None causes it to fail. Perhaps it conflicts with the default level of the operation contract or service contract, but those values have not changed in the past year so that doesn't explain why what had worked now doesn't.
Update: For what it is worth, this change in code gen happened between 2.0.50727.3053 and 2.0.50727.3082 (according to the runtime-version comment in the generated code).
I haven't experienced this problem myself, but my questionn is: why on earth do you specify a "ProtectionLevel=None" in your fault contract? Any particular reason for that?
If not, I'd strongly recommend not specifying that at all - the default is ProtectionLevel=EncryptAndSign and that's usually your best bet all around. Try it, unless you have a very strong and explicit reason against it.
Marc