Relatively new to mvc. I have what I consider a strangely architected project that I inherited after someone left my company. There are two "service layers". The main layer is an MVC 4 project which expects a REST query. Here is how it works:
An asp.net page in another project allows the user to enter a REST query. The same asp.net page calls serviceRequest.DownloadString with the REST query that was entered.
This results in a call to a DelegatingHandler in the mvc 4 project. This DelegatingHandler does some validation of the headers sent with the request. If the data is correct, the DelegatingHandler calls base.SendAsync with the same REST query that was passed in to the DelegatingHandler.
This activates the controller in the mvc 4 project that is called by the REST query. If it is working, the mvc 4 project returns xml.
4, To do much of the work the controller calls methods from a wcf project.
What is happening is that this architecture works fine if run inside visual studio. It also runs fine if the two service layers (the mvc 4 and wcf projects) are deployed to IIS applications on my local machine.
The problem occurs when the service layers are deployed to two seperate machines, one in the dmz and one on a macine inside the firewall. It returns a 500.
I used fiddler and fixed one problem that had to do with connection strings. Once that was done I still got the 500 as a result but no other information. In this case running fiddler again only confirmed that I was receiving a 500. I have tried:
puting trace code in the configs of both service layers
using an existing function in the wcf layer to write some debug information to a table from the controller.
I realize that I might not have put in the trace code in the mvc and wcf config files but it does seem to be simply bypassing the mvc 4 project altogether. I also notice some information on being able to use debug.write. Is this a viable option.
None of these two steps has brought me any closer to solving the problem. I am getting the impression that the mvc 4 code is never getting called at all and the error is occuring when the serviceRequest.DownloadString is called to bring up the DelegatingHandler. However I don't know where to look to see if I'm right. Is there a spot in the code (e.g and event) that I could use to follow the code from when it leaves the asp.net page and tries to go to the mvc 4 project?
What is the best way to debug this? Any help would be appreciated.
Thanks,
Fig0000
I'm not quite sure, but looks like the error returned is not shown because you are not running on localhost. And the error might be for some config files wrong or anything actually.
Can you try to run the application isolated (maybe creating a dummy method in each and if that works, make the internal call (fake / mock) so you can see what's the actual problem.
OR
you can try to let mvc to display all error even on remote. You can do this on web.config :
<customErrors mode="Off">
</customErrors>
Related
I have created a service that has several void/bool methods() and when I refresh the service reference on the client I can see those methods.
The issue is when I add a method with a custom type and supply it with all the correct tags datacontract/datamember, when I update the service reference again on the client nothing gets built not even the existing methods. No errors are spit out and I'm stuck with no clues on where to turn.
I also tried pulling in the service1 that is created as an example in to my client and it didn't get the composite type either.
The client is MVC4. The entire stack .net 4.
EDIT
After further review and testing, the problem is not with the service project or any of the data contracts. It is with the mvc project generating the reference.cS file. It is not generating the file or reporting an error on why it's not creating it. I proved this by opening a brand new empty mvc project and added the service reference and it generated everything perfectly.
Wonder if anyone can help me as i'm getting the following error 'Could not find endpoint element'.
My setup is similar to the following - A main project vb.net (Starts with say a login.exe that in turn uses class libraries to then do things such as set the menu navigation system which proceeds to call several winform class libraries) One of my winform class library calls another class library which contains some logic that will then in turn call a class library that has the service reference to a WCF service and will handle the WCF service reference function calls.
So if i run my winform as a standalone exe rather than a class library contained in the above setup everything works fine with connecting to the web service contained within the class libraries because i have added the <system.serviceModel> reference information to my winforms app.config as per the below thread suggested.
"Could not find endpoint element with name..."
My issue is that once i turn my winform back to a class library and include in my main project to be called it never finds the the <system.serviceModel> reference contained within my winform .dll as i'm lead to believe by again by the above linked post it will use the main project app.config not my winforms configuration.
What im trying to get at is I don't really want to add the <system.serviceModel> information contained in the app.config of my winform dll to the starting login.exe(being the program that starts the chain) as that just seems messy and just strikes me i must be doing somthing wrong in the first place. Is there a way to use the setting from my winform class rather than going all the back back through to the main project??.
I hope that makes some sort of sense any help would be greatly appreciated as really stuck as a wcf newbie, thanks in advance
Personally I don't think it's messy, that is generally how these things are done there is an application configuration file for your main you only have one copy of your main and usually your application is installed only once meanwhile you could have lots of copies of your DLL used by many apps... The configuration file will usually always contain settings that pertain to that one application meanwhile a DLL could be used by multiple applications. In short you should use the main app.config.
In any case to answer your question you could read in the app.config of the DLL in like any normal file parse it and programmatically setup the end-points as described here:
How to: Create a Service Endpoint in Code
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.
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.
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