I have an ASP.NET MVC 1.0 webapp, which serves as a front-end site for our external API. More specifically, it has a Control Panel for our API clients, documentation, etc.
Now I want to move our actual API (which is a set of WCF services) inside this project, so that, for example, http://api.example.com/controlpanel/dashboard would be served by ASP.NET MVC runtime, wherease http://api.example.com/services/1.0/users.svc would be served by an appropriate WCF service.
Granted, this can be done by adding a services/1.0 virtual folder in IIS, but I really want these two parts to be inside one project.
Is this doable at all? If yes, how do I integrate these two beasts?
Turns out MVC/WCF isn't the issue. Services hosted within the MVC app are activated just fine (I guess IIS bypasses the MVC runtime for .svc requests).
The issue was more to do with services in Areas, and requests for .svc files not going through the route table.
I've asked a more specific question addressing the actual problem here.
Expose WCF services that belong to an Area in MVC app at a routed path
Related
I have a web api returning json and I have Mvc website consuming that web api. I want to make api calls on the clientside using Jquery, not in the mvc controllers on the serverside. Therefore I don't want to publish them as 2 different application with 2 different domains as it will cause cross site scripting.
ex. mywebsite.com for mvc webapp
mywebsite.com/api for web api
Ok I figured out how to run them under same domain as explained nicely here
But I believe all of these solutions requires deploying the webservice and web api separatly even they run under the same domain?
I want to publish only mvc webapp and api should be published together with it. is it possible?
for example something like "nopcommerce" project is doing with Nop.Web and Nop.Admin? When publishin Nop.web also includes nop.admin and nop.admin is reacheable with the url like nopcommerce.com/admin
I've a web site developed using MVC 4 ASP.net application. I'm new to .net platform & I want to add web service which would return me operating system name of users device based on certain input.
Assuming I've logic to capture OS information using inputted data, how do I go forward in building this web service?
Do I need to have a complete separate solution file which will have a web service or in existing MVC 4 asp.net application itself, should I create a new project which would be of type "WCF Service Application"? Again I don't know much about WCF service either, if I use it, how would the URL be accessible, etc?
Can anyone give me some insights?
Note: I've also a separate REST web service which is a completely separate solution with separate projects but deployed on same IIS.
Thanks in Advance!
You don't need to create a WebAPI project just for what you described (i'm assuming one or a few end points).
Simply use MVC controllers that return JSON for example, this way you deal with a single framework.
Reasons to move to Web API is if you need support for CORS, need content negotiation for results etc. From what you are describing it's completely fine to stay with MVC.
I am working on a web service which is going to have both a native WPF client as well as a Javascript based web interface.
While I was working on the service and WPF client, the WCF service has been an IIS hosted WCF service project of its own, and has been working fine. Now that I'm starting to work in earnest on the web interface, I am wondering if keeping the WCF service separate is a good choice.
Reading around on the subject, there seem to be lots of options regarding this; for example, I could:
Keep the two projects separate
Create the asp.net MVC website and add an Ajax-enabled WCF service to the project
Create the asp.net MVC website and add a WCF service to the project
Create a WCF service library project and have that hosted in the MVC application (not entirely sure about this, but it seems possible)
And I have a feeling there's probably more.
What do you suggest I should do? My goals are:
Accessing the service from the WCF client using a service reference like I have done so far
Accessing the service from Javascript on the web interface
Accessing the service using port 80 from Javascript and the WCF client (to avoid firewall issues)
Having website and service under the same domain
Being able to run the thing using shared hosting (Gearhost), without multiple IIS virtual directories/application starting points.
Recommended: I would suggest keeping the projects as separate as possible. It allows more flexibility in how everything can be hosted if your app takes off and you need to separate to different servers/app pools/etc. Also, separation of concerns is one of the Service Oriented Architecture (SOA) tenets. This will force you to code your service in a way that is "generic" enough that might promote re-useability down the line. Forgive me if this is below you but I need to say it: In visual studio you can create an empty solution and add in each of your individual projects so you are working all within one instances of visual studio.
Then in your IIS instance you would have something like this:
/ = root app
/servicelayer/ = virtual application
But... you have a goal of "Being able to run the thing using shared hosting (Gearhost), without multiple IIS virtual directories/application starting points." You cannot host separate asp.net applications within a default IIS directory without marking them as virtual applications. This means you can not just paste the servicelayer application folder into your root application folder.
Because of that requirement then the only option you have is to add your service code into your asp.net mvc application. I'd create a folder called "/services/" that houses all your endpoints so that it's slightly separated. Then add an Ajax-enabled WCF service to that folder.
In the end I decided to create three projects: the service interface, a dll holding service and data contracts, the service library itself, which references the interface, and the website, an MVC application which hosts the created service library. The MVC code interfaces with the service as if it was hosted on a different system, using a client proxy (which in this case connects to itself, funnily enough). This should allow me to host the whole thing in a single virtual directory while still providing for not-too-painful decoupling down the line if need be. To keep things tidier, I am creating the service proxy manually in code by referencing the interface dll and NOT using the "add service reference" function.
I have a .NET 4 application that runs as a windows service. It runs periodic tasks and provides WCF restful webservices. It already hosts a silverlight web page (via WCF) that allows a user to configure the service.
Now I have a requirement to provide information on HTML/java script pages (e.g. for browsers and platforms that don't support Silverlight). I can serve simple HTML and javascript pages through WCF but that becomes laborious very quickly. I'd like to use MVC2.
Is it possible to provide MVC2 web pages from within a windows service? Or at least use some of the functionality provided by MVC like routing and the view engine?
Or is it more trouble than it's worth and should I head down the path of a separate app hosted on IIS?
You can host the ASP.NET runtime in any type of application including a Windows Service using the CreateApplicationHost method. Although note that by doing this you lose the robustness, security, logging, etc... that a real web server such as IIS provides.
Since you're asking the question about what route to take, I'd host an MVC2 application in IIS. Why recreate a web server using WCF when IIS is already there - and since you're asking, it sounds like that's a viable option.
I agree with Darin's answer that you can host ASP.NET MVC2 in any application, but I think you're going to end up recreating a lot of plumbing that's already in place with IIS.
On the upside, if you go with serving up ASP.NET MVC2 resources in a WCF service application, it may end up rocking and you could have a nice application you can sell on the side. :)
can we use WCF in Asp.net MVC and how can we use?
Sure you can - you need to learn the basics, e.g. from this site here:
http://msdn.microsoft.com/WCF
I can't possibly explain all you need to know here - go and learn the basics of WCF, and if you have concrete problems / questions, come and ask them here!
Do you mean, can my ASP.NET MVC projects be WCF clients, or contain WCF servers?
If the former, sure no problem. Right click on Solution Explorer, 'Add Service Reference', enter the URL to a running service (or pick an existing one from within another project in your solution) and away you go.
If the latter, that's fine as well. There is nothing stopping you from adding a WCF service via (perhaps SomeService.svc) 'Add\New Item...' (WCF Service, AJAX-enabled WCF Service, or Silverlight-enabled WCF Service are your options) or by hand. You need to bear in mind that the WCF service in this case will be hosted in IIS so there are some restrictions you need to be aware of depending on which version of IIS you are deploying to (ie. in IIS 6 only HTTP protocols are supported for your WCF services, some of the more esoteric WCF options may also be limited).