I'm looking at working my long-standing API to run on IIS rather than in a desktop app as it is now. Everything on the API is working so I'd rather not change too much if I don't have to. I know about the new Web API template in ASP.NET MVC 4 and I've worked with it, but I found that it didn't give me the control over everything that this particular project needs.
So my question is, is there any way to build an application for IIS that has something like an entry-point where I can just get a web request then use entirely my own code from there? Or do I have to build something that uses the Web API?
Yes, you'll want an ASP.NET handler.
How To Create an ASP.NET HTTP Handler by Using Visual C# .NET
http://support.microsoft.com/kb/308001
You'll need to handle parsing the request and serializing the result yourself. It's probably much better to create a web-api facade in front of your services than trying to do it manually.
Related
Are there any way to do a project using pwa concept in ASPX page? I am using HTML with PWA, it was working fine but I moved into the ASP .NET. It doesn't work anymore and the JSON file is not loaded.
You will maybe found this SO post useful.
After testing, i was successful at implementing the functionality by
adding the serviceworker and manifest to a ASP.NET MVC application.
Since the view (HTML) gets rendered in the backend, it's only possible
to cache an static version of your web application. So preferable you
should use angular etc to generate your HTML.
A progressive web app works on IIS and apache web server.
progressive web app is a general concept. It has nothing to do with your web server. Please give more details about your code architecture etc
you can also use swtoolbox plugin for handing client side caching
mybe your problem is client-side caching. however PWA concepts are as follows, neither of them has nothing to do with web server type
Progressive - Works for every user regardless of their browser
Responsive - The app works on any form factor whether it's desktop, mobile, or tablet.
Connectivity-independent - Allows the user to use the web app even if it's offline.
Native Look-and-feel - Acts and feels like a native application, but is strictly web-based.
Safe - Always served up to the client through HTTPS.
Discoverable - Even though it's an "application," it can be indexed into a search engine.
Re-engageable - Allows re-engagement through features like push notifications.
Zero-Deploy hassle - Allows users to add the web app onto their home screen without the issues with app stores.
Link-friendly - Allows you to reshare using a Url.
Yes finally I able to accomplish this. PWA now works not only on ASP.NET webform but On any framework.
https://github.com/cpbenipal/PWA_Aspx
I am a total newbie to the WCF world. I have an ASP.net (v4) website running on our dedicated windows 2008 server box. I'll refer to the website as, webisteA.com
I'm creating a new website, websiteB.com.au and I'd like to expose the functionality in WebsiteA.com to the new site. Things like logging in, registering in the database etc.
I think the best way to do this is to create a WCF service which sits in WebsiteA.com - but I am struggling to find any tutorials on how to do this. There are lots about creating a new project, but not that many about adding a WCF service to existing websites.
Is this the best way to do it? In the future I'd also like to use the service for mobile apps in the future too - not sure if that will make a difference.
OR - do I create a new service in a new app which is totally seperate to websiteA.com and websiteB.com and host this as website0.com and expose the database via that?
The questions I don't have answers for are...
is it restful? Do I use XML or JSON?
Baiscally, I want to be able to use it like an API - for example, saying "show me all the members who meet criteria X".
Thanks for any information.
ps) I have visual studio express 2010 c# (and a trial of studio pro)
You can certainly include WCF within the website A project - but have you considered the ASP.NET Web API? I haven't used it yet - but did use the earlier WCF Web API which spawned it.
Neat features include Content Negotiation (if the client asks for XML the API sends XML. If it asks for JSON is gets JSON) and a lot less config cruft (WCF web.configs are dreadful and completely overcomplicated IMO)
It's probably a lot easier to make a RESTy API with the ASP.NET Web API than with standard WCF.
A great open-source .NET solution is NancyFX which is really worth a look too.
I wish to build a Windows application that will generally run in the background, but have a configurable front-end Windows Forms GUI. I also would like this program to publish a small web page which can be accessed from other machines/devices and interact or call functions of the server application.
I'd rather not deploy a full-fledged ASP.NET web site with IIS, etc. I just need something simple.
So how would I go about doing this?
Take a look at Kayak. It's a relatively small and lightweight HTTP server that you can embed into your application and should provide all the functionality you're looking for.
FWIW, I am in no way associated with this project.
Maybe it's just because i've been doing asp dev for years, but I really think you should go the iis asp route as its very simple and built into windows. I can't imagine a more straightforward way of serving a webpage that has c# behind it to programmatically effect the host system.
Thanks to Kev in the comments on my question, he pointed me to this question, in which I found a link to a lightweight C# HTTP server component I could just drop in to my application: http://webserver.codeplex.com/
Works well for little stuff like I was doing.
I want to implement a restful service in ASP.NET. I want it to be compatible with .Net 2.0 and IIS 5+. I am constrained to not use ASP.NET MVC or REST starter kit. By reading on internet I have learned that it can be implemented using HTTPHandlers. The problem is, the request will come in as a POST request. And I want to URL to be like:
http://abc.com/MyService/MyMethod1/
and
http://abc.com/MyService/MyMethod2/
Any workarounds for this?
Thanks,
Vamyip
Your best option is to use URL Rewriting. This is non-trivial in IIS5. The methods I know of are as follows:
Method 1 - ISAPI filter
These are low-level modules that allow you to manipulate the incoming request. Programming one of these is hairy and tough to debug. If you go this route, you are better off using one that has already been built like ISAPI_Rewrite.
Method 2 - IHttpModule
These are managed ASP.Net modules that are easy to add/remove from your application. Again, you are better off using a pre-built component like UrlRewriter.NET. The issue with using one of these, (as BrainLy mentions), is that you have to configure IIS 5 to map all incoming requests to ASP.Net as follows (link):
Open Up IIS and Navigate to the “Home Directory Tab”
Select “Configuration”
Click “Add” and enter “C:\WINNT\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll” in the Executable box. For the file extension, enter “.*”. Finally, make sure that “Check that file exists” is not checked.
One interesting thing to note is that ASP.Net is itself an ISAPI module :)
Once you are able to manipulate URLs using one of these tools, you can easily rewrite the RESTful urls to be handled by your default.aspx page (or whatever handler you choose to use).
If you can allow the restriction of only IIS 7.0 and above you could use URL Rewrite http://www.iis.net/download/URLRewrite to do that pretty easily.
Can I ask why is it that you need to support IIS 5+? That is an 11 year old technology that hopefully people will move out of those platforms in favor of more recent versions. Also keep in mind support for some of those platforms is ending pretty soon.
If the concern is developers running Windows XP I would point out that IIS Express includes version 7.5+ functionality and is available for all platforms Windows XP and above.
I think this will be difficult to do because IIS 5 will not let you handle non ASP.NET file extensions without some additional configuration in IIS. That means you are limited to URLs ending in .aspx etc. To handle URLs like those in your examples you need to map ASP.NET to handle all URLs in IIS, implement some type of URL rewriting, or introduce some kind of hacky 404 redirection.
Once you have the correct mapping in place you can wire up an IHttpHandler, but you will have to parse the incoming request yourself to work out which is /MyService/MyMethod1/ and which is for /MyService/MyMethod2/. If your methods are simple then it is easy to do this with a regular expression.
You should start with a simple handler like this one.
I have an asp.net mvc application and now I need to add a web service to go along with it. What is the best solution for this? Just create a new web service project and add it to my solution then deploy it to the same web server using a different url? I would like it to be a part of the mvc application only because I have all my database code in there.
Any suggestions would be appreciated. Thanks.
There's no reason not to add a web service project.
You state that all your database code is in your MVC project. I strongly recommend you remove it from there into a separate class library project. This third project would be used both by the web service and by the MVC application.
I also strongly recommend that you not use ASMX web services for any new development.
Use WCF only, unless you have no choice at all. There's a misconception that WCF services don't do SOAP - they do, and WCF has replaced ASMX.
Web service could mean a soap based web service or a RESTful web service. I can't think of any reason why you would not be able to simply add an asmx file to your project and be in business. That is the soap based route. If you want to be really cool though you can simple return xml from a controller action and implement a RESTful solution right over the MVC framework.
If you want to use a regular ASP.NET asmx web service, it's certainly possible. Here's an example from Scott Hanselman that does just what you are asking about and it throws in some other ASP.NET technologies for good measure.
All you have to do is File -> New Item -> Web Service and it should work like a regular ASP.NET application in your Mvc project.
i think there's a couple of things here.
you can indeed add a web service to an MVC application. you may even consider identifying the web service(s) as a script service to make REST like operations easier to perform via javascript. this may not be necessary due to your circumstances.
i think there is a stronger question as to the underlying architecture. If you are placing the web service withing your mvc application, because, your database code is already there...should it be? it might be a good time to abstract your data layer out a little. However, if you're dealing with a relatively small project and don't need the flexibilty, then certainly, add a web service right in. i guess what it really boils down to is addressing the true needs of your application.
MVC is built on the asp.net framework. You should be able to include a web service within the same project. I haven't done it but I know that you can combine asp.net forms applications with MVC applications in the same project. The same should go for web services.
Unless your application is very small I would recommend you create different projects for each logical part of the application. A good staring point is having a project for each of these:
Domain objects
Data access
Web Services
UI (your ASP.NET MVC app)
This provides a clean separation corresponding to your architecture and supports reuse.