I have a set of web services written in classic asp. I want to convert them to asp.net, but this will be a long process. I want to convert a couple functions at a time, and use some sort of routing mechanism to select which version the requests go to (classic asp, or asp.net).
Changing the url used to access the web service and functions is out of the question.
The function to use is defined by a parameter in the querystring.
It seems I cannot use Server.Transfer to go from asp.net to asp or vice-versa.
Anyone have suggestions?
If everything is going to run in the same server (IIS 7) you can use URL Rewrite to simply use regular expressions or a map (table) to do that:
http://www.iis.net/download/URLRewrite
This way your URLs will not need to change, you will not need any extra servers or additional "proxy software", just extremely fast early rewriting (for those familiar with apache, is like mod_rewrite).
If you need to FW to a separate server (ie you need a reverse/forward proxy) your best option is to use Application REquest Routing (http://www.iis.net/download/ApplicationRequestRouting) which actually uses URL rewrite capabilities to have very flexible routing mechanisms, and with extreme performance, and advanced features like kernel mode caching and disk caching.
Not sure but have you considered some sort of proxy server (apache mod proxy or squid etc) to re-route a request at one url to a different url possibly on a different server? You should be able to configure the proxy to redirect one or many of your service calls to either asp or asp.net implementations on the same or different servers.
Enjoy!
You could create a wrapper Web Service.
Compile your current classic asp (and the asp.net web service you wish to convert to) using new namespaces. Say your current asp web service is called "MyWebService"...compile it into MyWebServiceAspClassic and the newly converted web service into "MyWebServiceAspNet".
Compile a completely new Web Service (MyWebServiceWrapper) using the current URL you mention above. Then, reference the 2 newly compiled MyWebService's in your wrapper WebService. Then you can use the QueryString parameter to decide which referenced web service to use. Whew! Make sense?
Related
I'm brand new to C#/.NET
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. If there are libraries to help me do routine stuff like constructing the HTTP request, parsing the header, ect - then cool. But I don't want a super opinionated framework that tries to do everything under the sun.
Why do I need IIS at all?
Addressing your points in reverse order, first - why do I need IIS?
The answer is, maybe you don't. If you are doing a simple listener that won't be exposed to the public internet, then you don't need it.
If you are doing a web application that needs to scale, be robust and easy to manage then it can help you with:
Logging
Operating in a multi-server environment for scale/high availability
Handling multiple requests in an isolated way
Serving multiple applications from the same host with sandboxing to ensure each application has guaranteed resources (memory, CPU)
Application lifecycle management
IP address restrictions
support for FTP, CGI, WebDAV
URL rewriting
Response header manipulation
Failed request tracing
Protection against some DoS exploits like slow HTTP attacks
Etc.
In short, it is an industrial strength, real world web server that will keep your application up reliably in a hostile world and scale as your application grows. it is certainly overkill for some cases if you don't need this kind of scale/high availability/management capability. In those cases you have the option to self host ASP.Net in a Windows Service or even a console app. This might sound complicated, but it has been made pretty simple by OWIN - Open Web Interface for .Net. This is an abstraction of the interface used by Asp.Net to communicate with its hosting server.
There is a very good tutorial on how to self host web API in a console app here
http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api
It does exactly what you ask for in your comment:
You create a console app project
You add references to the right assemblies (the tutorial uses NuGet to download the assembly packages)
You code up your web operation logic
You compile
You run the resulting exe
That's it!
On your second point about ASP.Net - it is a framework that has gone through a lot of evolution trying to keep up with very rapid changes in the web development world. This meant it got a bit bloated and lost some of its coherence, but recently the developers have been focussed on making it more lightweight, more modular and simpler. Scott Guthrie summarises it in his blog:
http://weblogs.asp.net/scottgu/introducing-asp-net-5
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. etc...
Because each project has its own purpose.
If you want to just listen on a TCP port then you could go learn Microsoft's Katana OWIN (but I highly doubt if this is what you want).
Katana OWIN
Briefly going through each projects purpose:
"Web Application" actually opens up another window and lets you choose from the following:
Web API is for exposing RESTful services or JSON data.
Web Forms is for making web pages that use Web Form components.
(A bit like Windows Forms, but Web)
MVC is for making Model-View-Controller web applications. This is where you build components with a separation of concerns. Model for data. View for what the user sees. Controller for controlling how your page behaves.
Why do I need IIS at all?
IIS is for serving .NET applications.
Without it, it would be quite hard to serve .NET applications.
I'll start with 2 then move on to your first question. IIS will run whatever the .NET web service you need, be it a monstrous WCF service, an ASP.NET application or the most basic http handler.
To my knowledge, ISS is the most straightforward way to use .NET web services. If you are used to PHP, it's basically LAMP or WAMP for .NET, which means it is sort of necessary. There are alternatives, as Mike Goodwin points out, but I have to admit I am not familiar with those third parties. Since replacing a layer for another doesnt mean much, I would stick to the "normal" procedure.
Since you dont want the framework to do a truckload of operations for you, your best bet might be along those lines:
Create a basic ASP.NET projet
Remove the default ASP.Net page because it seems you dont want it
Add a Generic Handler to your project. This will result in a myFile.ashx, which handles http requests and let you build any response you want
Of course, if you dont want to bother with IIS configurations, you'll need someone to setup an URL on IIS and map it against your handler repository.
EDIT:
"Abstraction layers" would be the very definition of frameworks, for good or ill, so you're stucked with it.
Now, since you have a low level background a not-so-intrusive way to work with the .NET web services would probably be the three steps I suggested earlier. You are still stucked with IIS though, in order handles the communications (i.e. manages sockets/requests). That's the way the framework works.
STILL, THERE IS HOPE. If you have complete control over your server (which is not my case, some other IT team manages the web servers), you certainly could build a windows service that listens to some socket and work the requests accordingly. It is a most unusal solution if you want to serve web pages, but would work rather well if you only want to push some data through http requests. If you go down this path, I suggest you take a look at the System.Net namespaces, you'll find some classes like "Socket" there. Combined with a console application or a windows service, you could work something out.
One of my coworkers is former microcontroller designer, I know exactly what kind of feeling you have towards the .NET framework. You'll go through some frustrations at times, but most of the time there are work arrounds. Feel free to request more details if you need some.
I am currently starting a massive web app project, and one of the requirements is that down the line I may be required to allow an iOS and Android app to interface with my application, I figured the best solution was to create a RESTful API and have the web application interface with it. However, my coworker who does front end development is unfamiliar with using a javascript framework such as backbone.js (more of a library I know), ember.js or angular.js. Since we're using asp.net I figured that the I could handle authentication and routing using asp.net MVC, delivering seperate views depending on the route, and he can handle the data manipulation only, However, I can't seem to figure out how to seperate routing from the javascript framework, I've looked into ember.js and backbone and both of them seem to require routing to be handled on their end for it to really work.
Does anyone have any idea how to implement data manipulation without the need for routing?
What you are describing is generally called API oriented architecture, meaning you have a RESTful service on a back-end and rich client-side application on front end.
The point is, it basically does not matter what technology you pick up on server. It could be anything: ASP.NET MVC, Web API, Express.js or Django. As soon as it's really RESTful and pure. By purity I mean, it deals only with data, no serving of HTML or something.
Server just specify the interface you work with data,
GET /invoices // get all invoices
GET /invoices/:id // get invoice by id
POST /invoices // post new invoice
If you confident with .NET, WebAPI is probably good choice. Typically you would prefer JSON output, WebAPI could handle content negotiation for you.
Now, the client job is to consume the API data and dynamically create HTML in browser. A lot of options now: Backbone.js, Angular.js etc.
Please be aware: client side routing and server side routing are completely different things.
Server side routing: routes particular HTTP request to particular controllers action (or any function).
Client side routing: detects the URL change and triggers corresponding JavaScript function to handle change. Client side routing is vital for SPA (single page applications). You can find a bit more information on SPA on that blog post.
Have a look at KnockoutJS, which would allow you to use ASP.NET MVC for routing or another JavaScript library like sammy.js (just for routing) or Durandal (for routing and navigation).
Note: Durandal version 1 used sammy.js internally, but version 2 has a custom routing engine and no longer uses sammy.js.
I wish to implement REST service which will be integrated with ASP site (basically the same project).
I've tried to provide my custom VirtualPathProvider (VPP) and it works, but to a certain degree. First, the content-type of the response is always application/octet-stream. Second, only GET requests are piped through the VPP. I've seen people playing around with HttpApplication to solve these problems. I am not sure if I wish to follow the path of hacking the ASP as it might take a lot of time, and in the end it might be simply impossible to accomplish the task.
Is there a way to do it, or I should create a separate page for MVC, and talk with it via some inter-process communication. This way MVC will be handle the REST requests and call my code in response. And vice versa - ASP will be able to send REST requests to remote servers.
If there are any other, cleaner, safer & easier, ways of linking MVC with vanilla ASP, then feel free to post them in comments/answers.
VirtualPathProvider is meant to be a way to virtualize the filesystem for internal ASP.NET operations (e.g. storing *.aspx and *.master files in a database), it is only coincidental that it works for user-provided URIs and requests.
Your best bet is just to use ASP.NET MVC, which is now integrated with ASP.NET (since 4.x) or as an easily redistributable component in .NET 3.x. ASP.NET MVC does play nice with WinForms in the same application, so don't reinvent the wheel.
However, if you are insistent, the only real option is to do it all from within a custom IHttpHandler that chooses to handle incoming requests or not (as you won't have ASP.NET URL Routing because you're not using ASP.NET MVC).
When an AJAX call from the client side hits the server url, data of the type JSON, XML or CSV is exchanged with the browser.
What are the various alternatives for the server side end point for each of the following technologies for the AJAX url call (i.e. xmlhttprequestobj.open(TARGETURL))
1) ASP.NET (excluding AJAX Toolkit)
TARGETURL can be ASMX, WCF services, ASP .NET page serving the content
Is there any other way?
What is the standard way?
2.) For Java EE the target URL should be a servlet?
What is the standard here?
3.) How does it work for the LAMP stack and PHP?
What is the standard here?
For Java EE, Servlets can indeed be used. However, if you're looking at a more of less independent client application that does (AJAX) calls to server-side services, then JAX-RS is much more typical. JAX-RS' main function is to provide RESTFull web-services.
If you're looking at web pages that are more integrated with the server application, then JSF has first class support for processing AJAX calls as well. JSF's main function is to provide a component based MVC web framework.
The big difference is that with JAX-RS, you'll be making explicit calls using some URL pattern from your application and will manually process the data it returns (which can be in JSON or XML, but is rarely CSV).
With JSF the AJAX machinery is more a behind the scenes kind of thing for the average application developer. You put some component on your page, specify bindings to some backing bean, and at run-time AJAX interactions will take place.
You can use for example mod_rewrite in apache with php application and then your url can be for example yourapp.com/user/seahorse and this can be mapped by your application to whatever.php script. So url needn't be exactly mapped to some code unit.
If you are using LAMP, then you probably create new virtual host in apache config files, that is mapped to some domain (for example yourblog.com). And then if apache gets request to this domain, then it see to home directory of this app and try find appropriate script.
yourblog.com/user/whatever.php -> yourblog directory -> user directory - whatever.php
script.
Or you can put special file .htaccess to home directory of your app and in this file put some rewrite condition, for example all requests to index.php script.
I have a component (an assembly built in .net) that i need to access on (almost) every request to two different websites. One website is written in classic asp and the other one in asp.net mvc.
At the moment i reference the assembly in the asp.net solution and call it like i would any .net assembly. On the classic asp website, i call it through a COM wrapper.
This is all good, except now i need this component to actually stay alive and monitor changes to a configuration file. In my asp.net website i could keep a refence in the application scope and i guess i could register it in component services for the asp access.
Is this the best way to do it? Also, this way the component would actually be hosted twice - one instance in the asp.net application scope and one in the component services. I could perhaps instead only have it live in component services, and then instead reference it from asp.net.
I don't know - something smells fishy (and no, it's not me) - am i on the right track or do you see better alternatives?
Do you really need a long running object? You say you need to monitor configuration file changes -- when the config changes do you need to trigger some actions or do you just need to ensure that each incoming request uses the latest copy of the configuration for your component? If it is the latter then standard .NET configuration should work for you without concern for the object lifetime.
In terms of hosting, do you need to use any COM+ services? If not, then I would not use COM+. If you want one central location for your .NET component, why not register it in the GAC?
Ok so i think i found two solutions, both acceptable for this project:
1) Register it in global.asa on the Application_OnStart in the Application object like this Application("Someobject") = Server.CreateObject("Someobject")
2) Host it in component services and handle lifetime there.