Develop Reference

Blazor client-side and WCF

I'm trying to use client-side Blazor to display some data, provided by existing WCF service. I was able to add a connected service reference, the proxy is generated. But when I'm trying to invoke it like this:
var client = new SoftConServiceClient();
await client.PingAsync(new PingRequest());
there is a bunch of errors, related to MonoTouch. By digging into the code of Mono, there is an explicit NotImplementedException in the constructor of the System.ServiceModel.DnsEndpointIdentity.
Am I right to assume that there is no way now to call legacy WCF service from Blazor client-side? If that's not the case, can anyone share a guide about how to properly do it?
Bonus question: if that is not possible, what would be the best option to approach this? Modify WCF to become REST-ish or just drop it and implement .net core api service?
Thanks a lot in advance!

Core does not support WCF very well instead of not at all. Especially in terms of authentication and security, such as the service created by using WS* binding. But for services created by using BasicHttpBinding or Restful styles services. We could invoke them normally on Core-based clients, whether using client proxy class or Channel Factory.
Please refer to below official repository.
https://github.com/dotnet/wcf
I suggest you re-construct your server project with BasicHttpBinding or using Asp.net WebAPI to create the backend service.
https://learn.microsoft.com/en-us/aspnet/web-api/overview/getting-started-with-aspnet-web-api/tutorial-your-first-web-api
Feel free to let me know if there is anything I can help with.

WCF is not supported in .NET Core out of the box, however there seems like there is a community project that is working on adding support for it in .NET Core
https://github.com/CoreWCF/CoreWCF
See What replaces WCF in .Net Core? for more info.

Am I right to assume that there is no way now to call legacy WCF
service from Blazor client-side?
Yes, you're right... WCF is not supported in Blazor client-side, and it won't be supported in the future. Microsoft has decided to stop supporting it as from .Net 5.0, and suggest to use Web Api instead.
Depending on how much you are invested in WCF, you may shift to Web API, perhaps gRPC, or go on using WCF, hoping that the efforts of the community to port and support WCF might succeed.

I was able to to put WCF 4.7.2 using techniques found with SoftCore in .Net 5.
I can also work SoftCore Hosted Example Blazor Server.

Building HTTP REST web server with SQL Server database

I am looking for guidance on how to start building a http REST server using C# and a SQL Server database?
Is there a recommended server framework for http web server? The same for REST services?
How should I start? Raising regular server and after that taking care of the SQL Server database?
Thanks.

I'm starting to evaluate REST frameworks for .Net and python. So far I like ServiceStack for .Net the best. It's simple, far easier to config than WCF, supports dependency injection, and seems to be fast.
When VS 11 and .Net 4.5 are completely released, Microsoft is also offering Web API. It can be used to build REST API's as well so it's worth looking into.
I haven't done enough research on Web API to see which would be better but those are some considerations for you.

Use OData. Have a look at Creating an OData API for StackOverflow including XML and JSON in 30 minutes

Consider using the new ASP.NET Web API:
ASP.NET Web API is a framework that makes it easy to build HTTP services . . . ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework.
It is currently in beta but was built specifically for building RESTful HTTP services in .NET, unlike WCF. See SO question WCF vs ASP.NET Web API for more details.
There are samples and video tutorials, and in one they are using Entity Framework models which can be backed by SQL. This SO question specifically covers that example: How to mix Entity Framework with Web API

What's the difference between WCF Web API and ASP.NET Web API

I've done a bit of work in the past using WCF WebAPI and really liked a lot of its features, I'm just playing with ASP.NET Web API at the moment and it seems completely different (IE completely removed from WCF).
Does anyone know which features of WCF WebAPI are included in ASP.NET 4 Web API?

Ive done a little more reading around this and found a few pages by MS people on this:
http://wcf.codeplex.com/wikipage?title=How%20to%20Migrate%20from%20WCF%20Web%20API%20to%20ASP.NET%20Web%20API :
The WCF Web API abstractions map to ASP.NET Web API roughly as follows
WCF Web API -> ASP.NET Web API
Service -> Web API controller
Operation -> Action
Service contract -> Not applicable
Endpoint -> Not applicable
URI templates -> ASP.NET Routing
Message handlers -> Same
Formatters -> Same
Operation handlers -> Filters, model binders
and http://wcf.codeplex.com/discussions/319671
The integrated stack supports the following features:
Modern HTTP programming model
Full support for ASP.NET Routing
Content negotiation and custom formatters
Model binding and validation
Filters
Query composition
Easy to unit test
Improved Inversion of Control (IoC) via DependencyResolver
Code-based configuration
Self-host

From what I've learned, Microsoft did a little bit of naming confusion here.
I'm assuming you know what WCF is all about, this big framework built on top of XML to allow user to build distributed services with a wide variety of technologies (from SOAP to REST to MSMQ etc.).
It's hard as hell to use (for me at least) and requires a lot of bootstrap to have it working, and eventually they realized this and started providing some default configuration for simple http services (WCF REST starter kit anyone?). ASP.NET MVC was gaining momentum and some of the features it provided (automatic arguments matching for example) started to show up in WCF.
Now that's the situation:
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.
http://wcf.codeplex.com/wikipage?title=Getting%20started:%20Building%20a%20simple%20web%20api
And that's better imho.
I'm quite sure it should be possible to host asp.net mvc4 webapi on top of WCF (if you ever need that), but i can't find documentation that can prove me right (or wrong).
UPDATE (can't fit as comment):
Wait, there is a huge different between "moving a subset of communication technology from a library/framework to another" and "replace WCF". I personally think that WCF was designed for some kind of communication concept and it has a rather cool design, but the distributed computing is somewhat moving on to new (and simpler) solutions (look the feature-rich SOAP vs the lean e flexible REST, although many people still use REST in a RPC manner), and i think that this kind of programming patterns better fit into the MVC architecture than the WCF one. Effort was put on designing some simple way of building/consuming web services on top of WCF, but they eventually found out that it was not the right solution.
Not to mention that many developers now use ASP.NET MVC and want to do rest web services for their web app, messing with WCF is often overkill for these kind of things, and I've experienced that on my own skin.
I think that the routing mechanism is awesome and the right way to go, and if you look closely, they included part of it (with different names and types, but the pattern was there) in WCF. So yeah, i think that if MS don't dismiss that part of WCF WE should do it. To strictly answer, no, i don't think you'll ever find WebGet/WebInvoke in asp.net mvc*, it just don't fit in.
Yeah self-host is probably the only bit of WCF contained in ASP.NET MVC4 right now.

It looks like WCF itself is somehow dying or at least becoming much less important then it was supposed to be and because of that it also has much less development effort put into its feature set. New features in WCF itself are more cosmetic.
WCF was designed as transport / protocol independent way for inter process communication. Even the idea was independent abstraction it was mostly build on top of SOAP stack. When WCF 3.5 brought support for REST it was mostly hacked in because REST is all about transport dependency. Using transport independent API to support inter process communication which is done through directly using transport features appeared inconvenient. As result MS first released WCF Rest API Starter Kit which never reached RTM but it was preview of features which was later included in WCF 4 and finally in .NET 4.5 or WCF Web API. Because REST is transport dependent and currently used only with HTTP (even it is theoretically possible to use other transport protocol) the API was moved to .NET part which is more suitable for HTTP processing - to currently very popular ASP.NET MVC.

WCF Web API is replaced by ASP.NET Web API which takes features from WCF Web API and merges them with the features from ASPNet MVC. ASP.NET Web API is a new (02/2012) framework for building and consuming HTTP services and a platform for building RESTful service.
Although not in the original question it seems worth noting that WCF is alive and well and its REST support remains useful when you have existing SOAP (WS-*) services you must support but want to add REST to reach more clients.
Reference
CodePlex: WCF Web API is now ASP.NET Web API
CodePlex: Daniel Roth on the Future of WCF
Chanel9: Dan Roth on the new ASP.NET Web API

The following excerpt found on this MSDN page summarizes this dilemma well.
Use WCF to create reliable, secure web services that accessible over a variety of transports. Use ASP.NET Web API to create HTTP-based services that are accessible from a wide variety of clients. Use ASP.NET Web API if you are creating and designing new REST-style services. Although WCF provides some support for writing REST-style services, the support for REST in ASP.NET Web API is more complete and all future REST feature improvements will be made in ASP.NET Web API. If you have an existing WCF service and you want to expose additional REST endpoints, use WCF and the WebHttpBinding.

Here is good article on Web Service, WCF and Web API http://goo.gl/T29A5B
Web Service
Based on SOAP and return XML Data
Support only HTTP protocol. It support only HTTP protocol.
Consumed by client that able to understand xml SOAP Services.
Can host on IIS. It can be hosted only on IIS.
Easy to Learn and understand.
WCF
Based on SOAP and return XML Data. SOAP is heavy compare then JSON and its overhead over network also.
Enhanced version of web services support multiple protocols like TCP, HTTP, HTTPS, Named Pipes, MSMQ via configuration.
More reliable when both client and server have .Net.
Its implementation and configuration is complex
Consumed by client that able to understand xml SOAP Services.
Self-hosting, IIS and using windows services.
Web API (Web API 2.0)
Design specifically for building HTTP Restful Services on .Net Framework.
Web API easily readable and handy as JSON.
Support all features of HTTP Like URls, Request/Response, Headers, Caching and Versioning.
Web API support many HTTP Verbs like GET, POST, PUT, DELETE etc.
Web API is stateless.
Web API supports MVC features (controllers, action results, routing, filter, model binders, IOC container or dependency injection)
Web API can be self-hosted, hosted with in the application and on IIS.
OWIN (Open Web Interface for .NET) is used for self-Hosting.

ASP.net web api is lightweight and REST support inbuilt. It is more suitable for mobile applications.WCF is bloated with more options . It depends on the complexity of the system to select one of these.

What web service to implement so it's easy to read from an iphone application?

I want to develop a web service that will enable me to synchronize the databases of my iphone app with a main database.
I will be using c# to write this web service. What kind of web service should I write, and how should it look like for it to be easy to call from the iphone application?
To answer the comment question: I think would prefer XML

REST webservice with JSON. It will be easier to read from iphone app. iPhone interaction with ASP.NET WebService
Also see this for tutorial http://www.codeproject.com/KB/webservices/RestWebService.aspx

You can't go wrong with WCF.
It's recommended by microsoft for all web services (outside the MVC world) and supports many different scenarios and interop. For an easier (but more fragile and less versatile) solution you would go with an aspx -> asmx service but I wouldn't recommend it.

Used RESTful WCF as a web service see this: WCF REST Service JSON Post data
and this: http://www.codeproject.com/KB/WCF/RestServiceAPI.aspx?q=wcf+rest+web+service+example
Also used JSON instead of XML tutorial here: http://www.raywenderlich.com/5492/working-with-json-in-ios-5
Also used NSURLConnection but haven't found one very good tutorial yet.

Where to start REST web service in C# or ASP.Net

I am thinking to start writing some REST web services as a way to provide data. I guess that when my REST web services are available, then some of my web applications and console applications will be able to use REST web service as data service to get, add, update and delete data to databases. In addition to that, I would like to add authentication feature to identify any request.
My question is that where should I start? I saw Microsoft ADO.Net Data Services. Not sure if this is a good start place? Are there any examples available?

Check out the REST in WCF MSDN site and the starter kit. Good article here too.

You may also want to check out servicestack.net An Open Source, cross-platform, high-performance web service framework that lets you develop web services using code-first, strongly-typed DTO's which will automatically (without any configuration) be immediately available on a variety of different endpoints out-of-the-box (i.e. XML, JSON, JSV, SOAP 1.1/1.2).
REST, RPC and SOAP out of the box
In addition, your same web services can also be made available via any ReST-ful url of your choice where the preferred serialization format can be specified by your REST client i.e.
Using the HTTP Accept: header
Appending the preferred format to the query string e.g. ?format=xml
See the Nothing but REST! web service example for how to develop a complete REST-ful Ajax CRUD app with only 1 page of jQuery and 1 page of C#.
A good place to start is the Hello World example to see how to easily add ServiceStack web services to any existing ASP.NET web application.
Performance
For the performance conscience, ServiceStack makes an excellent Ajax server as it comes bundled with the fastest JSON Serializer for .NET (> 3x faster than other JSON Serializers).
Checkout this live Ajax app for a taste (Live demo hosted on Linux/Nginx/MONO).
Simple Northwind Example
ServiceStack also makes it easy to create strong-typed frictionless web services where with just the code below is all you need to return a List of Customer POCOs:
public class CustomersService : RestServiceBase<Customers>
{
public IDbConnectionFactory DbFactory { get; set; }
public override object OnGet(Customers request)
{
return new CustomersResponse { Customers = DbFactory.Exec(dbCmd =>
dbCmd.Select<Customer>())
};
}
With no other config, you can now call the above webservice REST-fully returning all of:
XML
JSON
CSV
HTML
JSV
SOAP
Accessing web services on the client
You can call the above web service re-using the same DTOs that your web services were defined with (i.e. no code-gen is required) using your preferred generic ServiceClient (i.e Json, Xml, etc). This allows you to call your web services using a strong-typed API with just 1 Line of code:
C# Sync Example
IServiceClient client = new JsonServiceClient("http://host/service");
var customers = client.Send<CustomersResponse>(new Customers());
And since your web services are also REST services, it works seamlessly with JavaScript ajax clients, e.g:
Using jQuery
$.getJSON("http://host/service", function(r) { alert(r.Customers.length); });

ASP.NET Web API is now the Microsoft framework for creating RESTful services.
http://www.asp.net/web-api

If you are new to REST in the .net world then start with OpenRasta. The other Microsoft solutions can do REST if you work hard at it but they will guide you down a route where you will most likely end up with POD(Plain old data) over HTTP. That is not what REST is all about. If that's all you want then that's cool too, but it is not REST.

If you're going WCF, the WCF REST Starter Kit that JP referred to is a great place to start.
Omar Al Zabir provides a pretty good example of using ASP.NET MVC to provide RESTful services that are fluent in both XML and JSON
You can also go the ADO.NET Data Services route you suggested. These services are built on top of the WCF stack.
I've never stumbled across any really good guidance on how to select between these options. In ASP.NET MVC you take on the majority of the plumbing burden but also have maximal control. Straight RESTful WCF is the happy middle ground although WCF tends to want to have things done its way. ADO.NET Data Services are pretty magical with the downside of buying fully into a given approach to generating these services and losing more flexibility.
There are a couple of good books you can read on the topic of RESTful services with .NET. Both O'Reilly and Microsoft Press have recently released books on this topic. Perhaps the most important advice I can provide you is to consume and understand several open RESTful services (e.g. Twitter, Amazon, Flickr) to understand the design decisions that went into creating the services. User provisioning, authentication mechanism, and supported content types (e.g. JSON, XML, RSS/ATOM) are some of the decisions that you can observe in action to aid you in your path to creating your service API.