We just stood up an on-premise MS Service Fabric cluster. I have some WebAPI's i'd like to host in it. I'm looking for resources on how to take our standard 4.5 WebAPI's and host them in Service Fabric without have to create a Service Fabric project and migrate it; that just seems too complex.
I looked at some of the Service Fabric sample projects, and it seems all the projects are tightly coupled with Service Fabric. My goal is keep these apps unaware of Service Fabric.
Any links of information is greatly appreciated, thanks!
We did this way:
Created the service fabric projects in the same solution of our WebAPI.
Inside the ServiceFabricHost project we created our HttpListenerService to expose the ports using service fabric, the same you would do to a SelfHosted WebApi.
Configure the ServiceFabricHost to open the needed endpoints.
Add the reference to the WebApi project
Use the WebApi Startup to send the IAppBuilder and configure the api with our external(SF) configuration, like ports and URL.
The secret is: when you create a self hosted web api, your generaly create a console application, like the asp.net docs. With service fabric, you replace the console with the ServiceFabricService, that is similar to a ConsoleApplication, but in this case will be a statelessService.
In this case, we used a stateless service for HttpListenerService, if you need a StateFull service, you will need to refactor your Api to use the reliable collections.
The fellow Vaclac, created a nice tutorial for this:
https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-services-communication-webapi/
If it's a standalone web application with a self-hosted web server (e.g., Katana, not IIS), then you can simply run it as a Guest Executable.
If it's not self-hosted and requires a separate web server to run, like IIS, then you can look at running it in a Container.
I had the same problem and solved it by using the DependencyResolver.GetService() method on the HttpConfiguration object in the Startup() class. Create a new Service Fabric Stateless/Statefull WebAPI project. In the Startup() class, add the following code:
public static class Startup
{
// This code configures Web API. The Startup class is specified as a type
// parameter in the WebApp.Start method.
public static void ConfigureApp(IAppBuilder appBuilder)
{
// Configure Web API for self-host.
HttpConfiguration config = new HttpConfiguration();
// Allow custom routes in controller attributes.
config.MapHttpAttributeRoutes();
config.Routes.MapHttpRoute(
name: "Default",
routeTemplate: "{controller}/{action}/{id}",
defaults: new { controller = "API", action = "HealthCheck", id = RouteParameter.Optional }
);
//inject controllers here
config.DependencyResolver.GetService(typeof({{YourWebAPIRootNamespace}}.Controllers.APIController));
appBuilder.UseWebApi(config);
}
}
This allows you to deploy your existing APIs into Service Fabric without having to migrate the entire code base to a new project. Don't forget to update the app.config in the new project with all applicable settings from your web.config.
Full blog post here http://thenameisirrelevant.com/hosting-an-existing-webapi-in-service-fabric
Related
I want to create a gRPC service but I need to host in a winform .net application.
there is an extraordinary example of how Hosting ASP.NET Core API in a Windows Forms Application
I would like someone to explain to me, what I need to install and what I should change in that example, to host a grpc service in the form of Windows ...
You could follow the same steps but with several additional:
Install the package Microsoft.AspNetCore.Grpc.HttpApi This is going to map your gRPC endpoints to the classical HTTP. It is not automatic you need to specify the services in the Startup.cs as follow:
app.UseEndpoints(endpoints =>
{
endpoints.MapGrpcService<MygRPCService>();
});
Into your protos you need to indicate the HTTP path, something like this:
rpc Get(GetRequest) returns (GetReply) {
option (google.api.http) = {
get: '/my-endpoint'
body: '*'
};
}
Add to your Startup.cs ConfigureService method:
services.AddGrpc();
services.AddGrpcHttpApi();
I'm really new to WebApi and I've been reading information about it but I don't know how to start my application.
I already had a project with many WFC services with .Net 3.5. So, I updated my project to 4.5.1. Then I created a controller with the Visual Studio 2012 Wizard. Then, when the controller is created, I see a class as a template with the get, post, put, delete methods. So I place my post method and finally I want to test the service with a HttpClient.
I tried to apply the solution in green from the following forum:
How to post a xml value to web api?
I'm gonna receive a XML string with the structure of a Contract model.
I run my project into Visual Studio Development Server.
But I have troubles with URL to test my service.
I saw many pages where people do something like this http://localhost:port/api/contract. But I don't still know how it works. So how can I do to test my service? What is it my path or url to test my service?
WebApi, like MVC, is all based on the routing. The default route is /api/{controller}/{id} (which could, of course, be altered). This is generally found in the ~/App_Start/WebApiConfig.cs file of a new project, but given you're migrating you don't have it most likely. So, to wire it up you can modify your Application_Start to include:
GlobalConfiguration.Configure(WebApiConfig.Register);
Then, define that class:
public static class WebApiConfig
{
public static void Register(HttpConfiguration config)
{
// Web API configuration and services
// Web API routes
config.MapHttpAttributeRoutes();
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);
}
}
If you created a TestController controller and wanted to make a POST request to the instance running locally, you'd access http://localhost:12345/api/Test/ (with the appropriate verb). 12345 would be the local port that Visual Studio is using to host your service (and can be found by viewing the project's properties, then navigating to the "Web" tab).
Having said that, testing is probably best performed on the the project (without making an external call). There are several posts on the subject, but generally come down to something like the following:
[TestMethod]
public void Should_Return_Single_Product()
{
// Arrange
var repo = new FakeRepository<Widget>();
var controller = new WidgetController(repo);
var expected = repo.Find(1);
// Act
var actual = controller.GetWidget(1) as OkNegotiatedContentResult<Widget>;
// Assert
Assert.IsNotNull(actual);
Assert.AreEqual(expected.Id, actual.Content.Id);
}
How do I get OWIN to host a SOAP endpoint (do not care if WCF is or isn't involved, SOAP gives WSDL which makes services easier to consume by certain clients, that's why I want SOAP and REST)
I suspect the answer is: Implement your own middleware that hosts a SOAP endpoint. If that's the answer so be it, but that's a lot of work so I'll probably just end up sticking with WCF and avoiding OWIN if that's the case. I find it hard to believe no one has implemented a SOAP hosting middleware yet...
As a rule we like to do both REST and SOAP endpoints on our services; currently we use IIS and the WCF restful bits to host the SOAP with [ServiceContract]/[OperationContract] attributes, and the rest is defined with [WebInvoke] attributes, with these attributes the services need no reimplementation for the different endpoint types.
We just use the ASP.NET routes to add new ServiceRoutes which add a rest binding to URI/REST with the same service as a soap binding to URI/SOAP.
Now we're looking at doing some new services work and I'd like to move forward to using OWIN so we can implement our new services with hosting agnosticism as some services will be better served by windows service hosting and some better served by IIS service hosting.
All of my fiddling with things and so far I can come up with no way of getting a SOAP endpoint hosted by OWIN. I have the rest handled fine by making my service inherit from ApiController and then using this little snippet of code in the OWIN app's Configuration method:
public void Configuration(IAppBuilder app)
{
HttpConfiguration config = new HttpConfiguration();
config.MapHttpAttributeRoutes();
app.UseWebApi(config);
[...]
There is a custom OWIN middleware example on MSDN that shows how to support SOAP requests. It is not a general purpose WCF host but may be enough to expose your existing WCF Services (i.e. [ServiceContract/OperationContract]) within an ASP.NET Core app. The example does not include support for [WebGet/WebInvoke] but may be enough to get you started.
https://blogs.msdn.microsoft.com/dotnet/2016/09/19/custom-asp-net-core-middleware-example/
If your primary goal is simply to begin writing new services using OWIN and you still plan to host them in IIS using Microsoft.Owin.Host.SystemWeb. You could ignore the WCF requests within the OWIN pipeline and allow the IIS ASP.NET pipeline to handle them. This would enable you to write services that are a combination of OWIN middleware and traditional WCF endpoints.
public static class WCFAppBuilderExtensions
{
public static IAppBuilder IgnoreWCFRequests(this IAppBuilder builder)
{
return builder.MapWhen(context => IsWCFRequest(context), appBuilder =>
{
// Do nothing and allow the IIS ASP.NET pipeline to process the request
});
}
private static bool IsWCFRequest(IOwinContext context)
{
// Determine whether the request is to a WCF endpoint
return context.Request.Path.Value.EndsWith(".svc", StringComparison.OrdinalIgnoreCase);
}
}
Then call the IgnoreWCFRequests extension method when configuring your app.
public class Startup
{
public void Configuration(IAppBuilder app)
{
var config = new HttpConfiguration();
WebApiConfig.Register(config);
app
.IgnoreWCFRequests()
.UseWebApi(config)
.Run(context =>
{
return context.Response.WriteAsync("Default Response");
});
}
}
It's not so easy to host a WCF infrastructure over an OWIN one, sure it can be possible, with a bit of work it's clear possible to adapt, or proxy the owing request-response layer to the WCF infrastructure; WCF provides a not so easy but a complete infrastructure to do something like that.
cpowers answer may work for some, but didn't for me because I have other Filesystems setup within Owin, and I couldn't get both behaviors (fallback to other handlers when needed and also go through OWIN pipelines).
This was the configuration which made it work for me:
Use Owin automatic startup (Remove any appSettings named owin:AutomaticAppStartup)
Do not manually add its handlers in your web.config (or Startup will run twice) (Remove OwinHttpHandlerfrom from <handlers> in you web.config)
Add appBuilder.UseStageMarker(PipelineStage.MapHandler) after builder.UseFileServer()
UseFileServer must happen after all pipelines you setup, otherwise the ones setup after it will not work and you'll get 404
Optionally Fork the pipeline like cpower mentioned
If your OWIN pipelines does not register middlewares for the paths where your legacy stuff is you don't even need to fork your pipeline (my case).
I am trying to convert an existing ASP.NET Web API project (currently hosted in IIS) into one that can use the SelfHost framework. I'm a bit fuzzy on the actual details but understand I can run a self-host server in a console window and then run the service on top of it. The problem I'm having is that my project is an MVC project and not a console one. My familiarity with console/Windows apps is somewhat limited as I generally work with projects to be hosted in IIS.
What I'm a bit confused on is whether I need to convert my existing Web API project in Visual Studio into a new console application, or if there's a way to create another console application Project in the solution which can act as the web server for the Web API services, or rather if there's a way to add a console element with a Main() entry point to the existing MVC project (overriding the Global.asax entry point.)
Search didn't yield much information that helps me fill this knowledge gap. Hoping someone can point me in the right direction. Even at a high level.
I recently had to convert a Web API project into a self-hosted service using OWIN (on Visual Studio 2013). I did that as follows:
Manually added Program.cs and Startup.cs files at the root of the project. Both files containing code as described here: http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api.
Went to the properties of the Web API project. On the "Applications" section, I stated "Output Type" as "Console Application", and set the "Program" class as the "Startup object".
Although not required, I slightly modified the using block within Program.Main() to look as follows:
// Start OWIN host
using (WebApp.Start<Startup>(url: baseAddress))
{
// Create HttpCient and make a request to api/values
HttpClient client = new HttpClient();
var response = client.GetAsync(baseAddress + "api/values").Result;
if (response != null)
{
Console.WriteLine("Information from service: {0}", response.Content.ReadAsStringAsync().Result);
}
else
{
Console.WriteLine("ERROR: Impossible to connect to service");
}
Console.WriteLine();
Console.WriteLine("Press ENTER to stop the server and close app...");
Console.ReadLine();
}
Finally, instead of calling config.Routes.MapHttpRoute() multiple times within Startup.Configuration(), you can refer to the routes you already wrote for the Web API:
// Configure Web API for self-host.
var config = new HttpConfiguration();
WebApiConfig.Register(config);
app.UseWebApi(config);
So after a great deal of research I'm starting to enhance our service server stack with a webAPI entry point. Based on this thread, and especially the last post by a member of the Digerati board, we are implementing webAPI services as a facade into our WCF application layer. (Our WCF services are just facades into our Application layer where all of the behavior lives)
My question is this. I downloaded MVC 4 and created a new WebAPI project in my service solution. But wow there was a ton of crap that created in my project that I just am not going to need! For example, all of the image files, the home controller, views and models, etc.
So in stripping this down to be just a service project, what are the minimum files I need to build a functional service project? Our intent is to publish both of the service types (WCF and webAPI) side by side in the same server .. each service call doing the same identical service call and returning the specific DTO for the request. So far it looks like App_Start, Controllers, and the Glabal.asax/web.config entries. I definitely don't need Views, Models, or Images!!!
Any input on what others have done to do a pure service deployment would be of great welcome here.
Same problem here. I've found that article from Shawn Kendrot explaining how to create minimal Web API project. It was written for the beta version of Web API but it seems to be still valid.
Create an empty ASP.NET project.
Add a reference to System.Web.Http and System.Web.Http.WebHost (version 4.0.0.0)
Add a Global.asax file
Register a route in the Global.Application_Start. Something like:
protected void Application_Start(object sender, EventArgs e)
{
GlobalConfiguration.Configuration.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional });
}
Add a controller
public class SampleController : ApiController
{
public string Get(int id)
{
return "Hello";
}
}
Run the project locally with the URL /api/sample/123 and enjoy the outcome:
FYI. I have found that I have had to reference two more .dlls:
System.Net.Http
Newtonsoft.Json