As a IT guy, a Software Developer, a Microsoft technologies developer (from C++ to .NET ) with over 24 years development history, I still have to face to some awkward (embarrassed ? ) situations such as job interviews. I left school so many years, but some interviews still needed me to give correct answers for some basic computer and programming acknowledges, such as: What is C# ? What features does OO have ? or I was asked for writing code to give a good performance program to implement a scanning or searching case based on stack or queue ….
Microsoft announced they open sourced WCF which targets .NET core yesterday.
The main target of opening WCF is for supporting cross platforms, because it is the main target of .NET core also.
Currently the opened WCF project on GitHub is a subset of the full WCF product, this is because due to the .NET Core plan.
We have had several posts about WCF vs Web API:
3: WCF or Web API;
Today we read another great article “WCF or ASP.NET Web APIs? My two cents on the subject” which was from Ido Flatow’s Blog, here we got more clear answers:
1: Does WCF support Web API ?
Before Web API changed the name from WCF Web API to ASP.NET Web API, we could say WCF supported Web API, but, WCF Web API was not enough to support Web API; We used WebHttpBinding to support Web API; but now, if you want to use Web API, you maybe have to use the new tech called ASP.NET Web API without WCF, because the new ASP.NET has more features that supports Web API;
2: WCF mainly provides SOAP services, WCF WebHttpBinding provides non-SOAP service over HTTP (called RESTful services), the new Web API provides HTTP Services (Only);
3: WCF is NOT dead because in many cases you have to choose WCF other that ASP.NET Web API:
“If you want to create resource-oriented services over HTTP that can use the full features of HTTP”, choose Web API;
“If you use fast transport channels such as TCP, Named Pipes, or maybe even UDP (in WCF 4.5), and you also want to support HTTP when all other transports are unavailable”, you can use WCF with SOAP-based bindings and WebHttp binding.
We found another nice post about REST vs SOAP, the original page is on ASP.NET forum, the poster’s name is bruce sql work dot come, but ASP.NET forum always change, so for avoid the original link broken, let us copy part of content as following:
“REST and SOAP are competing protocols. SOAP uses a xml payload and usually supports wsdl files to define the valid xml (often called a contract). REST is a simple http protocol that uses the http verbs get,put,post,delete instead of method names. it is payload neutral (ithough xml & json are the most popular).
WCF is a soap hosting technology for .net. It defines contracts for serializing .net object to SOAP messages and back. while its been extended to support REST/JSON functionality its not a pretty picture, as there is no formal contracts with REST
WebAPI is a new .net framework in MVC4 designed to support REST apis, without the complexty WCF adds.
WCF/SOAP is best used for typed messages over SOAP. Its ideal for both .net and J2EE because they are simularly typed languages and have tooling for the wsdl.
We posted 3 guides about Deploy a web application which includes WCF, SilverLight and ASP.NET , for simplified all steps, here provides a “quick guide”:
1: Make sure you have installed IIS successfully, at least you can visit http://localhost and see a default web page;
2: Open IIS Management (7 and above), right mouse click Sites\Default Web Site and choose “Add Virtual Directory”, here we create a virtual directory using a physical Widows path (you can make a new path here such as C:\ConspecWeb without leaving away IIS management tool), and give an alias name such as ConspecWeb;
3: Right mouse click the virtual directory that you just created in step 2, and choose Add Application, here we create a web application, we choose another physical path or create a new path, normally we will create a new sub path under the path that we created in step 2, for example: C:\ConspecWeb\WebTerminal, we give an alias name WebTerminal, and select Application Pool as ASP.NET 4.0;
4: Now copy the Website files (not WCF service files) to C:\ConspecWeb\WebTerminal folder, and try to visit http:/localhost/ConspecWeb/WebTerminal, you should see the website home page (but just Silverlight page do not work since we have not set WCF yet), if no, then there must be some error places which you have not set correctly;
5: Go to the folder which you put the WCF service files, open the web config file, if your WCF hosted in a Windows application, the config file name should like xxxx.exe.config; scroll down to Services section, most of content have already set for us, we just need to change the endpoint address to our real address:
— First, we set baseAddress as our WCF service root path, for our case, it is http://xxx.xxx.xxx.xxx/ConspecWeb/Services/;
— We have an endpoint for Client Access Policy file for the cross domain handling for Silverlight application, the address should be empty, means it uses the base address which we set above;
— We have basicHttpBinding endpoint to provide services to Silverlight clients, the endpoint address we set to “SL/”;
— endpoint for Meta Data Exchange, we set to “SL/mex”
so the final endpoint addresses will be set like following:
<services> <service name="ServiceApp.Services.TerminalService" behaviorConfiguration="TerminalServiceBehavior" > <endpoint address="" behaviorConfiguration="webHttpBehavior" binding="webHttpBinding" bindingConfiguration="" name="PolicyEndpoint" contract="ServiceApp.Services.IClientAccessPolicy" /> <endpoint address="SL/" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ConspecService" contract="ServiceApp.Services.ITerminalService" name="TerminalServiceSLEndPoint"/> <endpoint address="SL/mex" binding="mexHttpBinding" contract="IMetadataExchange" /> <host> <baseAddresses> <add baseAddress="http://192.168.1.230/ConspecWeb/Services/" /> </baseAddresses> </host> </service> </services>
Sometimes when you use “localhost” and use another port number which is not 80, you might use the config similar with the following:
<services> <service name="CCService.Services.CCServices"> <endpoint address="http://localhost:8732/" behaviorConfiguration="webHttpBehavior" binding="webHttpBinding" bindingConfiguration="" name="PolicyEndpoint" contract="CCService.Services.IClientAccessPolicy" /> <endpoint address="" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ConspecService" contract="CCService.Services.ICCServices" name="TerminalServiceSLEndPoint"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> <host> <baseAddresses> <add baseAddress="http://localhost:8732/MyServiceAddress/CCServices/" /> </baseAddresses> </host> </service> </services>
after you done above, please try to visit the service URL, you should see the service information, if you can not see, there must be some wrong you have not set correctly yet;
About WCF and Web API, we should have a longer blog, but this time we just put several links, they are also great article about WCF vs Web API, you should get to know whether choose WCF or Web API after you reading them.
I posted the previous 2 parts of our case deployment in 2012:
Today I post the 3rd part: Deploy the case on a server which installed Windows Server 2008 R2.
The main point which we should be very careful is the different between in cases of you deploy the ASP.NET with Silverlight on Windows Server and on Windows XP / Windows 7, which is that we should consider more security settings on Windows Server version, it means we might never met some troubles on Windows 7 but they are normal on Windows Server.
OK, let us check the first problem: if you deploy the case on Windows server, when you done all steps which were mentioned in previous 2 posts, you will find all Silverlight web page still not work, for example, you will only see the empty page, not any Silverlight page content display.
The reason is about Security.
In previous part 2, after you unzip SLApp.xap, and changed Silverlight Client side configuration file, and zipped whole folder files into a new SLApp.zip file, The Windows Server system actually changed the file security information, this is the big difference with when you do the same procedure in Windows 7.
Please check the following screen shot, the new SLApp.zip file has a different icon with old SLApp.xap file.
Right click the file and check the properties, click Security tab, you can see the different security settings:
So now we now the new zipped file missed some security information. Let us just add missed group or user names which are IIS_IUSRS, Usuarios and TrustedInstaller, you might not have to add all missed roles, for example, you might ONLY need to add the IIS_IUSRS user. (In our case, we added IIS_IUSRS and Usuarios)
After you added missed security information, you will see the web page visiting works again.
About our case’s deployment, I have posted the part 1 here. This article is the part 2.
We have done the discuss for Web Server settings and WCF configuration. Here we start from the 3rd part: Silverlight project configuration.
C> Silverlight project:
The Silverlight project or application also need to be set since it communicates with WCF services. you have to specify your right WCF service URL to Silverlight project or application. However, our smart Microsoft does NOT provide a similar config file with WCF or other applications, there is NOT a configuration file for Silverlight. All configuration information were involved in a binary file, which is a .xap file, Normally, you can find it under ClientBin folder.
So what you should do is try to find a way to change the config information in this .xap file. There are also some solutions on the internet to tell programmer to use other ways to set information for Silverlight application, but by now I have not found a ideal solution. Maybe we need to research more about this.
OK, let us come back to try to set for Silverlight. actually, the way is simple, the .xap file is actually a compress file, it is a true .zip file !, so, my friend, the magic is here! Haha… Just change the extension name .xap to .zip (or for more safe, just like me, copy the .xap file to a .zip file), and unzip using your normal way to expand it.
Bingo! now you can see the expanded folder which includes lots of secret files!
What we need to care about is the ServiceReferences.ClientConfig file only, so we can ignore all other files here. Please use any text edit tool such as notepad to open this file, you can see the content is like the following:
Now I think smart you know what should do, yes, just use a correct WCF service address to replace the above green box wrapped content, our case is http://www.yourdomain.com/WebStage/ConsWCFServices which mentioned in part 1. and save it. and close the editor tool.
OK, you fixed the Silverlight configuration, one more step: please DO NOT forget to recover the .xap file !
What we should do is just compress all the folder to a zip file again. and change the extension name to .xap file, that is.! But, please DO NOT compress the files out side of the files’ folder, but inside the folder please! so that you can get a compress file which does not include the folder itself. otherwise your .xap file will not work.
Maybe I need to teach you more details here even though it is a very simple step:
Make sure you are inside of the files’ folder; and choose all files in this folder, and then right mouse, choose a compress way due to your compress tools installed, for Windows 7, you just simply choose “send to” a compress file. Again: you should make sure you are inside the folder, so that the generated zip file will NOT include the folder itself. This is also very important!
Finally, Change your .zip file to .xap file using the original file name. that is! The configuration for Silverlight done!
D> Website Project:
The most simple part is website in our case, we do not need any configuration for our website project since most of settings have already done on previous projects.
All we need to do is copy all web files including Silverlight project content (Web developer should prepare a complete website deployment package first. the package include website and Silverlight project, you should do the Silverlight part configuration just like what I told above), We should copy the content to the virtual folder on IIS web server which we created in the part 1, in our case, the URL is:
If you have finished all configuration successfully, and you have started the WCF Service, and you have copy all website files on IIS web server, now you should be able to visit your website.
Let me leave for other stuff. I might come back for more support information, in case of I find more.
We have a web application which developed using ASP.NET 4.0 (Web Forms), Silverlight 4.0 and WCF 4.0.
Brief information about our application:
1: We use WCF to provide all data to clients, some data are from database, another part of data are from a real time data resource;
2: We use self host for the WCF service, which host the WCF on a standalone WPF application, the real time data resource is exactly from the WPF application;
3: All clients are the web pages which using Silverlight, Silverlight content hosted on ASP.NET web form pages.
Here I am going to talk about deployment of our web application, we deploy it to our different customers.
I will introduce the whole deployment to 4 different parts:
A> Web Server; B> WCF project; C> Silverlight project; D> Web site.
A> Web server (IIS):
Actually we should not too worry about the settings on web server (IIS), because most of time the customer should arrange their own network administrator (or call other name but just an administrator) to handle this part.
What I suggest is that using IIS 7 or above, which matches and supports well most of ASP.NET web applications especially new ASP.NET techs.
And, we need to create 2 Applications (on IIS 7, the “Add Application” is different from “Add Virtual Directory” ) on IIS, the one is for WCF service, another one is for Web site.
(Update: Actually, for WCF self host mode, we do not need to add an application for WCF, because the WCF service URL has been already set in the host program. So please know we ONLY need one application folder for website project below.)
You can check the following image, for our case, we created 2 virtual folders on our IIS server:
ConsWCFServices virtual folder is for our WCF service project; (Update: Do NOT need this one)
WebTerminal2012 virtual folder is for our Web site project;
B> WCF project:
Before we put our WCF project content on the corresponding virtual folder which I introduced above, we need to set the WCF configuration, to let WCF work correctly.
If you choose other WCF host mode but not self host. for example you choose web server host mode, you have to copy your final WCF service content to IIS web server finally. However, please know in our case, we use WCF self host mode, so we actually DO NOT need to put any generated WCF conten on our IIS, what we should do just set right URLs to “image” our WCF service to IIS web server
Because we use a WPF application to host WCF, so we should open the WPF config file, which named xxxx.exe.config (xxxx is WPF project name, if you choose web server host, you need to find a config file maybe named web.config):
We should set 2 parts for WCF Service with the self host program:
The first part is for database: here you need to change the database connection string. Put your database server name, your database name and your database user account information. But Please DO NOT change the connection string name! (for example, the following connection string’s name is SysDBConnString, then please do not change it.)
The second part is for WCF services:
Please check the following settings,
I have mentioned above, we need 2 virtual folders on IIS web server, but we just need to care about the WCF virtual folder here. Look at the following 2 URLs which wrapped by green boxes.
The first URL is for the the “famous WCF and Silverlight trouble” – The “Cross Domain issue”. (Yes, if you want to know what it the cross domain trouble, you can check the link, I have posted a blog before about it).
Actually, you don’t need to know what the cross domain trouble is, just set a right URL here, please make sure the URL is the root virtual folder which your WCF service content will be located in. for example: suppose we are set a WCF service with a web server host mode (not like ours self host), we should created the web application folder such as ConsWCFServices on our IIS, which you can see in above IIS part. the root URL is just “http://www.yourdomain.com/WebStage/ConsWCFServices”, it is a root virtual folder. This is very important, otherwise you will meet the famous cross domain trouble.
Update: For self host mode, we still need to a root virtual folder (web application root folder on IIS), but you just set it in the web configuration file, you DO NOT need to create an physical folder on IIS for a self host mode WCF service.
I can set (map) my WCF service content in the root folder, but I can choose NOT. Just like our case, the second URL is just our real WCF folder, we put (map) our WCF service program in the second URL. But please know you have to choose a sub folder under the root WCF virtual folder which you have set in the first URL. in our case, we choose a sub folder named “TerminalService/SL/”, actually this sub folder is NOT exists on IIS server (and you do not need to create it either). but when you set this sub folder, you should make sure later you can get WCF service information through this sub folder, the full URL is http://wwww.yourmain.com/WebStage/ConsWCFServices/TerminalService/SL/ in our case.
OK, the WCF part set done. all you need to do now is just starting the WCF service on your hosting project.
After you done WCF config, please use a web browser to try to visit your WCF service, using the sub folder URL which I mentioned above: http://wwww.yourmain.com/WebStage/ConsWCFServices/TerminalService/SL/
In our case, we can get the WCF web service result, just like the following showing:
If you can not see the similar page, that means you have not set correct configuration for your WCF service project. Please double check your settings, and even have to contact with the web server administrator.
OK, let use pause here. so that we can make sure our WCF is working. See you guys on the part 2.
Most of content in this post from Microsoft and related websites:
Firstly, we start from the simplest thing: The relationship of WCF Web API and ASP.NET Web API is WCF Web API is now “merged” to ASP.NET Web API, “ASP.NET Web API is effectively the next version of WCF Web API. There will not be a separate release for WCF Web API and we will retire all WCF Web API content by the end of 2012” :
Announcement: WCF Web API is now ASP.NET Web API! ASP.NET Web API released with ASP.NET MVC 4 Beta. The WCF Web API and WCF support for jQuery content on this site wll removed by the end of 2012.
(from WCF project)
We are happy to announce that ASP.NET Web API has now shipped with ASP.NET MVC 4 Beta!
ASP.NET Web API represents the joint efforts of the WCF and ASP.NET teams to create an integrated web API framework. You can get the bits and find articles, tutorials, samples and videos on the new ASP.NET Web API home page. We have also setup a Web API forum on the ASP.NET site where we will monitor customer questions and discussions.
What is WCF Web API ?
WCF Web API allows developers to expose their applications, data and services to the web directly over HTTP. This allows developers to fully harness the richness of the HTTP as an application layer protocol. Applications can communicate with a very broad set of clients whether they be browsers, mobile devices, desktop applications or other backend services.
What is ASP.NET Web API ?
ASP.NET Web API is a framework for building and consuming HTTP services that can reach a broad range of clients including browsers and mobile devices. It’s also a great platform for building RESTful services. ASP.NET Web API takes the best features from WCF Web API and merges them with the best features from MVC.
There is very important information which you might recognize something you need:
Why change the name? Web APIs have a foot in two worlds: the world of service orientation and the World Wide Web. We decided to align ASP.NET Web API with the rest of the Microsoft web platform, so we went with the brand that communicates this alignment. From a technical perspective we also decided to go with a new HTTP specific dispatcher instead of trying to carry forward the WCF dispatcher, so there is virtually no WCF code in the new stack.
About more information between WCF and ASP.NET Web API, Ido Flatow has a very good article here: WCF or ASP.NET Web APIs? My two cents on the subject:
What is the purpose of the WebAPIs?
When WCF was conceived back in its Indigo and .NET 3 days, the main goal was to support SOAP + WS-* over a wide variety of transports. However, over time it became clear that although SOAP is wide spread and supported on many platforms, it is not the only way to go when creating services. There is also a need to also support non-SOAP services, especially over HTTP, where you can harness the power of the HTTP protocol to create HTTP services: services that are activated by simple GET requests, or by passing plain XML over POST, and respond with non-SOAP content such as plain XML, a JSON string, or any other content that can be used by the consumer. Support for non-SOAP services was very much needed in WCF back then, mostly because some clients, such as web browsers, were not that suitable to handle SOAP messages (plenty of XML parsing and DOM manipulation).
About detail content, Please read above all articles which I provided Links.