I have a VS2010 Lightswitch application which uses a number of services which I've developed in a separate DLL and added to the application as WCF RIA Services.
My problem is that some of these service calls include string parameters that can contain angled brackets which are illegal for the default request validator.
I cannot seem to disable this request validation. I've tried all of the following without success:
1) Setting requestValidationMode="2.0" in the ServerGenerated web.config ()
2) Setting a custom requestValidationType in the WCF RIA DLL's app config ()
What's peculiar is that when I use Fiddler, I don't even see a call being made to the service. It is as if the lightswitch client is intercepting the call.
Everything works fine if I just replace the parameter that contains the angled brackets with one that does not.
Related
We have an existing wcf service, and I created a new project. I want to use it. I hit add service reference, pop in the URL, press OK, and it adds it as a service reference but there is no config generated.
I also tried svcutil.exe /language:cs /out:GeneratedProxy.cs /config:app.config [url] but no config is generated, only the proxy cs.
I'm using VS 2013 / .NET 4.0
My question is, is this a sign that the SVC itself has some missing data that is required to build the contracts, or is the problem with adding the service reference?
For the record I have tried unchecking the reuse types option which some questions on here have reported as fixing the problem.
Bonus question, do you think if I can't get this working that manually adding some generic default bindings and endpoint code to the web config will work?
First, the reason that why the Adding service reference generates nothing is that the WCF service is rest style service. By default, the proxy-based invocation of rest style WCF services is complex.
https://en.wikipedia.org/wiki/Representational_state_transfer
https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/wcf-web-http-programming-model
Calling the WCF rest style service with the client proxy is uncommon. Generally, we construct an Http request by using an HTTP client library to call the service, such as HttpClient, WebClient.
How to fix "ERR_ABORTED 400 (Bad Request)" error with Jquery call to C# WCF service?
Besides, calling the WCF rest style service with the client proxy is feasible. Please refer to my previous link.
WCF: There was no endpoint listening at, that could accept the message
Feel free to let me know if there is anything I can help with.
In my VS solution, I created a console project, which I'm using as the client, and an empty project for the WCF service.
I then created the WCF service (created my contract and service type and manually constructed the app.config), and added a reference to the WCF service project in the client project.
However, when I called ServiceHost.Open() in the client, the endpoints weren't loading. I eventually determined that I needed to put all of the config information in the Client's app.config, rather than the service's app.config.
I'm not sure if this is normal, or if I'm doing something wrong. In the past, when I've used the WCF project template, this wasn't the case.
Yes, that is normal. Each .NET application (client, service, web site, etc.) has it's own configuration file. To be precise, there's a hierarchy of them, but the bottom end of that hierarchy is unique to the application.
This makes sense if you think about it -- the client would need to contact the service to ask for it's configuration, but it needs to know the endpoint information in order to even try to do that. So yes, the normal process is that client and service both have very similar information in their configuration files.
If you use Visual Studio's built-in tooling to do everything for you, it will automatically create and/or edit the configuration file for your client when you add a Service Reference to the project, copying from the metadata endpoint that WCF exposes for that purpose. Alternatively, you can use the WCF configuration editor tools to edit your client application.
Also, note that nothing actually enforces that your client and server have compatible settings; e.g. you can change the maximum sizes of many buffers/graphs/etc on one side, and not the other, and see some strange behavior. It's up to you to make sure both ends are working with mutually usable settings.
i m new in WCF.
Currently i m trying to upgrade my current asmx service project in to WCF.
-->I developed one dummy client (windows application) in .net 2.0.
--> Then i developed one asmx service for that client. It works without any issue.
--> After this i upgraded current asmx project in to WCF (with backword compatibility) without changing method definations.
--> Now m trying to access WCF service methods by changing URL from clients app.config file.
--> When client calls service methods it goes to correct method on server but server taking all parameters as 0 . Also client getting null even after server returning valid result.
Please help ...
Thanks
Your code may be very helpful.
Also, please start from verify that your parameter names on the methods are same (include case) as in your service contract definition.
I have some basic questions related to the conversion of Web Service (.asmx) into WCF. We have a running website which use tons of Web Services. These web services use a common dll that has the business logic. We are planning to convert the web services into WCF. Since there many web services, we are planning to convert one at a time. So to begin with there will be one WCF and many web services (asmx) residing on the production server. I have some confusion on how to make the website run with both - WCF and ASMX residing at one place. I would appreciate if someone can answer my queries:
Can I share the same web.config file for both .asmx web service and WCF service? If yes, then what all changes do I need do to to make sure both works at the same time. Adding ServiceModel tag is enough to the existing web.config?
Can I use the web.config to store some configuration parameters that can be shared between the two services - WCF and .asmx? How to call it?
Currently, the common dll (business layer) is using HTTPContext.Current to cache some values. How can I make sure that the code works for both WCF and .asmx calls? What is the best way to convert the code similar to:
xslt = (XslCompiledTransform)HttpContext.Current.Cache[fileName];
string XslFilePath = HttpContext.Current.Server.MapPath(#"~/xsl/" + fileName);
What is the WCF equivalent?
Finally, how can I deploymy WCF changes in production server? Do I just need to copy the service dll and the .svc file?
I know, I have so many questions, and these may look simple to you guys but I am finding hard to figure them out.
1) Can I share the same web.config file for both .asmx web service and
WCF service?
Yes, absolutely - the WCF config lives in the <system.serviceModel> section (mostly), so that's no an issue at all.
2) Can I use the web.config to store some configuration parameters
that can be shared between the two services - WCF and .asmx?
If you create your own custom configuration section or section group - yes, sure. Both the ASMX web service as well as your WCF code can read that custom config section - that's all standard .NET stuff, really (See: How to: Create Custom Configuration Sections Using ConfigurationSection)
3) Currently, the common dll (business layer) is using
HTTPContext.Current to cache some values.
You can turn on the ASP.NET compabitibility mode on your WCF services, and doing so, you a) tie yourself to IIS forever, and b) get access to all the usual HTTP context and stuff like that. See: WCF Services and ASP.NET for more info.
4) Finally, how can I deploy my WCF changes in production server? Do I
just need to copy the service dll and the .svc file?
Copy the service DLL(s), the SVC file, make the config changes - that's it!
I need to upgrade our web services to use WCF instead of ASMX. If the signatures of the web services stays the same, will existing clients that already call the ASMX service have to change anything on their end? Is there anyway to still use WCF but not force them to change anything?
Option 1 :
Using the current ASMX's WSDL, generate the client using svcutil.exe
Grab the generated interface and create a WCF service based on this interface
Output : One new WCF endpoint configured with basicHttpBinding. Clients need to update the URL at which they're sending the messages.
Option 2 :
Refactor your ASMX code. Move all the logic into a separate DLL.
Create a WCF service and use the logic in the refactored DLL.
Output : 2 endpoints, one for ASMX and another one for WCF
If you use the BasicHttpBinding for your new WCF service, and implement the same methods with the same message structure, existing callers should be able to call into this new WCF service without any change on their part.
There's also an AspNetCompatibilityRequirements attribute in order to get around some potential compatibility issue - see the MSDN documentation on it.
Marc