It seems that there are two methods for auto generating web service proxies in VS2008 from a wsdl.
wsdl.exe
Adding a web reference/service reference from the interface
I've been using wsdl.exe because I like having access to the class - and when I add a reference, I haven't been able to find the generated proxy code. Is there a benefit of just adding a reference that I may be overlooking?
Adding a service reference is the way to go. As pointed out to me on another thread, it is prudent that I strongly encourage you to avoid using wsdl.exe unless you have a very good reason to be using it. For your reference, the VS option Add Web Reference is a wrapper over wsdl.exe and creates proxies for .NET 1.1 or 2.0 clients. Add Service Reference is a wrapper over svcutil.exe and is used to create .NET 3.0+ clients.
Related
I have just installed Visual Studio 2013, created an MVC Web Application project and noticed a new file in the project template called Startup.cs.
What is this, how is this different from Global.asax.cs and are there any good best practices on what to use this for?
Every OWIN application has a startup class where you specify components for the application pipeline.
If you start a new Visual Studio project, you'll see pieces of OWIN in it.
OWIN is a specification that defines an API for framework and servers to cooperation.
The point of OWIN is to decouple server and application.
For example, ASP.NET Identity uses OWIN security, SignalR self hosting uses OWIN hosting, and etc., the examples all use OWIN,
therefore they all need to have a startup class, that is defined in "Startup.cs" file.
The Global.asax, the ASP.NET application file, is an optional file that contains code for responding
to application-level events raised by ASP.NET or by HttpModules.
For more details:
OWIN
http://www.asp.net/aspnet/overview/owin-and-katana
Global.asax
http://msdn.microsoft.com/en-us/library/1xaas8a2(v=vs.71).aspx
You can find more ideas about why OWIN in the following article:
http://www.asp.net/aspnet/overview/owin-and-katana/an-overview-of-project-katana
The file seems to be related to SignalR. Quoting the VS 2013 release notes:
Built on OWIN
SignalR 2.0 is built completely on OWIN (the Open Web Interface for
.NET). This change makes the setup process for SignalR much more
consistent between web-hosted and self-hosted SignalR applications,
but has also required a number of API changes.
MapHubs and MapConnection are now MapSignalR
For compatibility with OWIN standards, these methods have been renamed
to MapSignalR. MapSignalR called without parameters will map all hubs
(as MapHubs does in version 1.x); to map individual
PersistentConnection objects, specify the connection type as the type
parameter, and the URL extension for the connection as the first
argument.
The MapSignalR method is called in an Owin startup class. Visual
Studio 2013 contains a new template for an Owin startup class; to use
this template, do the following:
Right-click on the project
Select Add, New Item...
Select Owin Startup class. Name the new class Startup.cs.
In a Web application, the Owin startup class containing the MapSignalR
method is then added to Owin's startup process using an entry in the
application settings node of the Web.Config file, as shown below.
In a Self-hosted application, the Startup class is passed as the type
parameter of the WebApp.Start method.
The Startup class is the convention that Katana/OWIN looks for to initialize the pipeline. When your app starts, the code inside of the Configuration function is run to set up the components that'll be used. In the MVC 5 templates, it's used to wire up the authentication middleware which is all built on top of OWIN.
If you want to use dependency injection with OWIN, check out this project on GitHub: DotNetDoodle.Owin.Dependencies
We currently have two different applications consuming our OData, WCF Data Service
We want to add a third application, but this one, rather than being a website, is another WCF Data Service. It is effectively a subset of functionality, exposing some methods from the internal service to as a public api.
As soon as I add a reference from one WCF Data Service to another, I end up in a conflict between System.Data.Services in the GAC and Microsoft.Data.Services implementations of DataService.
Is there a proper way to create an OData WCF Data Service wrapper for another OData WCF Service?
This is the error
Error 1 Reference.datasvcmap: The type
'System.Data.Services.Client.DataServiceCollection`1' is ambiguous: it
could come from assembly 'D:\source...\bin\Microsoft.Data.Services.Client.DLL' or from
assembly 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Data.Services.Client\v4.0_4.0.0.0__b77a5c561934e089\System.Data.Services.Client.dll'. Please specify the assembly explicitly in the type
name. App_WebReferences/WcfDataService/
Not sure it has to do with the wrapping (may just be a side-effect from the way you set it up in Visual Studio). Try removing the reference to System.Data.Services.Client.dll, I believe the OOB NuGet packages are favored.
I am new to the world of WCF and MVC. Currently I have a MVC3 ASP application and a WCF service app exposing some services. I want access this service from MVC3 ASP app. As I know either this can be done by adding the Service Reference to ASP project or by generating proxy class from WCF service and add proxy class to ASP app.
My question: Is it the right way I am going (as said above). If so which method is better (adding service reference or generating proxy class and adding it manually)?
It is a lot easier to use add service reference. Add service reference basically means that you are asking visual studio to do the job that you would have done if you were generating it manually with default settings.
If you don't have any reason not to go the easier way, then my advice is to use add service reference.
I've an ASP.NET MVC 3 project and have been tasked with implementing a few UI controls. I need to call a few web services and bind the data to the UI controls. The problem is the web services host (we have no control over them) requires me to first implement a UsernameToken class (WSE 2.0) to authenticate the user and generate a security token. I understand WSE 2.0 is superceded by WCF in 2006. I don't want to switch back to VS 2005 to be able to use WSE 2.0. What are my options?
Thanks for any help!
Just add a Service Reference to your ASP.NET MVC application and point it to the web service WSDL. This will generate a strongly typed WCF client which is compatible with WSE. Here's an article which covers the different interoperability scenarios
I'm afraid the approach Darin Dimitrov didn't work. What I have ultimately done is installed WSE 2.0, then added dll reference to Microsoft.Web.Services2.dll found in the WSE installtion directory (c:\Program Files (x86)\Microsoft WSE\v2.0\Microsoft.Web.Services2.dll). I also modified the Reference.cs file of the service to inherit from Microsoft.Web.Services2.WebServicesClientProtocol. I was able to find the UsernameToken class and able to authenticate successfully.
I'm not an expert in this area so I'm not sure if this is the correct way of doing this, but it worked nonetheless.
I'm using a Visual Studio generated proxy class to access a web service (added the web service as a web reference to my project). The problem is that the function the web service exposes expects a CDATA element, i.e.:
<Function><![CDATA[<Blah></Blah>]]></Function>
Unfortunately, when I pass in "" into the proxy class, it calls the web service with this:
<Function><![CDATA[<Blah></Blah>]]></Function>
This appears to be causing problems with the web service. Is there any way to fix this while still using the proxy class generated by Visual Studio?
Can you provide a code sample of how you're calling the webservice? If it's a web service with a published WSDL I don't know why you'd even have to address this level of implementation detail, so I have a suspicion that you're calling it wrong somehow.