Is there any way to have apache "pass" the request it takes to a c# "application" to handle, allowing it to return specific content. I want to handle an intense amount of asynchronous calls to apache via javascript and have these calls routed through c# (much the way asp.net does). Has anyone successfully done this before? Any idea where to start looking?
Update:
Some more information. I want to be able to handle thousands of concurrent asynchronous requests as fast as can possibly occur writing the interpreting agent in some kind of threaded c# application. I could be wrong, but I dont think that iis with asp.net is tailored for this sort of thing (a proof of concept would be great).
I feel that going with something like apache would be better suited. If that means going from something else to c# first is fine I guess, but I would like to be more direct.
Apache actually supports running C# libraries using mod mono. Also, you could use CURL to send a web request to C# running on IIS. Another way would be to open a server socket directly in C#, and have apache (via php, python, or some other scripting language) connect to you C# application to handle the request. I think you need to be more specific about what exactly you are trying to accomplish.
with apache2, you could run mod_aspdotnet
or if it suits you, run some urls in proxy mode (pass them to another asp.net server), using mod_proxy
or Kibbee's excellent solution
Related
I'm writing a web server app for the first time, and I'm not really sure that I know what I'm doing.
Basically I have some server side C# code and a native iOS app. I need to be able to push updates from the server to the app. The method which we have decided to use is Long Polling, and I can see three ways of doing this:
1) Writing my own web server in C# - not neccesarily tempting as it requires re-inventing the wheel
2) Using WCF - I've seen a few articles about how to implement long polling over WCF, but the tutorials that I've seen all seem to use clients which are implemented in .NET WCF which is not applicable for me as I need to use an iOS app.
3) Something else, possibly using IIS - I don't really know where to begin with this option.
Can anyone recommend a good tutorial, or exemplar project which uses standard HTTP to implement long polling with a C# server? So long as it's using standard HTTP, I'm confident with the iOS side of things.
Obviously if there's an even neater way of doing things then I'm all ears as well.
I would highly recommend that you investigate SignalR which allows you to achieve exactly what you are after. There are many iOS tutorials as well as HTML / JavaScript and of course C#.
One of the benefits of SignalR is that it tries to use the best technology available on the various devices and down-grades until it works. So, will start with Web Sockets for example and fail down to long-polling if nothing better is available.
I'm in this project:
A web page that's gonna be used by the front-end company people to query and update data from a SQL DB.
I'm working with visual studio and the code behind (C#) is almost done, so the interactions between SQL and C# are ok.
My original idea was to work with ASP.NET which is familiar to me, but that's not gonna be possible. I have to switch to PHP.
So, today is my first day learning PHP, checking http://php.net/manual/en/index.php and a lot of things seem quite similar to ASP.NET so I guess it won't be that hard.
Anyways, some questions popped up quite fast as I wanted to script something else than a "hello world".
Is there an easy way to get/send C# variables from my class using a php page? I've read soemthing about using XML in order to do so, but still I'm scratching my head, is there another, easier, way to do this?
You have options.
direct integration. PHP can instantiate and use .NET objects . See the DOTNET library in PHP. So if you run PHP on Windows, and you expose your .NET logic according to the requirements of the PHP DOTNET infrastructure, then you can just call .NET classes directly from PHP. Some restrictions: PHP is built to integrate with the .NET 2.0 runtime. You can't build .NET 4.0 objects and connect to them from PHP.
synchronous network protocols. As others have suggested you can expose your C# logic via aREST or web services interface, then invoke those services from PHP using the curl library or file_get_contents(). The C# logic could be, but need not be, publicly exposed. In other words, you could make it accessible only from within the firewall of your app, so that no anonymous public access is possible. on the other hand your architecture may call for access to the same API from 3rd-party or user apps. In that case it needs to be exposed publicly.
in either case, public or private, you will want to use WCF or ASPNET MVC to expose these services implemented in C#.
asynchronous mechanisms. PHP can connect to MSMQ. See Using PHP to Open MSMQ Queues . Of course C# can do likewise. You could use MSMQ as a buffering communication mechanism between the two worlds. To do this you'd need to come up with a data serialization protocol, for the messages you put and get on the queue. JSON or XML would be appropriate choices here.
Database. If you are concerned about employing MSMQ as it is "one more piece of infrastructure to manage" you can also employ a database as a go-between. A shared database can be accessed by both PHP and C# and used as a message queue or communication conduit. PHP inserts messages in a MySQL Table, and the C# app could read and process them, then place reply messages in a different table. This would require some work by you to design the message formats, protocols, indexes, and request/reply correlation mechanism. But it relies on proven, existing technology that you already know how to use.
Finally, there is Phalanger. This lets you compile PHP onto the .NET Framework. This means integration between C# and PHP will be simple. I haven't tried this but it might satisfy your requirements.
Has anyone worked with mongodb from within Silverlight? What driver did you use? Silverlight supports only asynchronous sockets; but it looks like available C# drivers are synchronous.
Believe it or not, my first project with MongoDB was in Silverlight. IronPython, some C#. This was in 2009 and we went live with something like 0.8 or 0.9 of MongoDB ... so it has been awhile.
This was I think 2.x Silverlight so it was harder to accomplish things like direct database connections. That said, I would recommend still going the route that I went at the time.
Use a REST+JSON API on your server end and have your client communicate through that. We did ours in Python, but there are these days a few awesome prebuilt Mongo REST Interfaces like Sleepy Mongoose if you don't want to roll your own.
The biggest advantage of this is the question of security: with a direct database connection from client to server even with authentication you run the risk of the user getting into your database... at which point they can do anything they want as MongoDB Authentication restricts access at a DB level, but not what people can see or delete. This doesn't even require disassembling code in some cases as there are, as I recall, development browser plugins that let you script a running Silverlight app from IronPython and IronRuby.
There are other reasons including the synchronous question, but overall I think having a serverside interface to Mongo with a clean, secured facade that talks to Silverlight would serve you better.
It'd probably be best to use the official 10gen MongoDB C# driver on the server with a lightweight web API sitting over it that can be consumed by your Silverlight app with WCF, SOAP, REST, etc.
This not seems to be a good practice to access the mongoDB from silverlight.
I suggest you to wrap all your commands in a clean WCF service (maybe a data service), and completely abstract the mongo plumbing.
this will allow you to control exactly what kind of operation can be done, who can execute the command, and with an evolutive protocol.
I would like to write a C# app to handle my HTTP (including AJAX requests) rather than go the PHP, PERL or ASP route as I just need to return some standard HTML, albeit obviously, as I want CGI, dynamically generated.
UPDATE: I am not proposing to write my own web server but have the exe hosted by a webserver such as IIS or Apache. Also I dont want to learn and use ASP (I know I can do it much faster, development time, myself in C#) and I just want W3C valid html sent back to the client.
Are there any good reasons for not doing this?
I realise each time a HTTP request is made the exe has to be loaded and run - but surely so does Perl, ASP and PHP? Is there a way to have an exe remain running dealing with all HTTP requests for specific page? (though it feels like I am just writing a mini HTTP server then!)
Are there any good tutorials? I have read this one, but it is bit dated (2005): http://www.codeproject.com/KB/cs/cgi_csharp.aspx
UPDATE2: I dont think speed is going to be a issue anyway (running a small exe without a GUI is almost instantaneous) but if I wanted to be really efficant I could write C# server then the non-static page requests can have a tiny exe written in C which sends the request to the C# server and returns the reply. Couldn't I? :)
There are solutions such as FastCGI, that eliminate the overhead of launching an executable every time you want to process a request. Very few people still use traditional CGI. I don't know if there is a solution compatible with .net.
There is a much better option for .NET, the System.Web.IHttpHandler class.
All you have to do is subclass IHttpHandler, and overload 1 method to process a request. In my opinion it is simpler CGI.
There is a good example on the MSDN Site.
I'd suggest leveraging the HttpListener API for this kind of thing if IIS really doesn't cut it for you.
Maybe a strange and green question, but
Is there anything C# can't do what javascript can...
And considering JQuery?
except for the fact that one is clientside, and the other serverside?
Or am I asking a very stupid question now?
EDIT:
to be more specific: I mean web programming, and indeed maybe a more useful question is:
> What can I do client side that I can't do server side, and vice versa?
> Are there more reasons to use both languages if you keep "server/clientside" out of scope?
> some developers avoid javascript. why?
What can I do client side that I can't
do server side, and vice versa?
Client-side: Javascript runs in most browsers without a plugin. C# requires a browser plugin like Silverlight. Even though it's running on a client machine, Javascript can't read and write files there. C# in Silverlight may be able to read and write files depending on the Silverlight version and what the client allows. Both Javascript and C#/Silverlight can talk to remote servers.
Server-side: since you control this machine, you can do whatever you want - read files, write files, talk directly to databases, etc. Keep in mind there's nothing stopping you from running Javascript server-side. Check out node.js.
Are there more reasons to use both
languages if you keep
"server/clientside" out of scope?
I wouldn't leave the execution environment out of your analysis. If you absolutely need client-side interaction and can't guarantee C# will execute on the client, C# isn't practical. Likewise, if your company runs Windows servers and doesn't want to install Javascript runtimes/compilers, you won't be able to use Javascript on the server.
some developers avoid javascript. why?
Problems with Javascript in a browser are absolutely awful to debug. You're running on a machine that's out of your control - the user may be running an obscure or ancient browser, they may be using anti-virus software that mucks with your Javascript, their browser plugins might muck with your Javascript. It's hard.
This is the cost of doing business on someone else's machine, however. If it was easy, a beautiful client-side experience would mean less. Solving hard problems isn't for everyone but it sure is appreciated when it's done well.
I take it your real question is, if c# can do everything, why should you use javascript at all? The answer here is performance, both perceived and real. The trick here is that to use c# to do the DOM manipulation normally associated with javascript, a browser has to post back an extra http request to the server and tell the c# code what to do. Lets talk about those extra requests. Spread around a lot of users, they add up very quickly and play havoc on your server infrastructure. The "real" performance issue is that now a lot of work has to happen on your server(s), instead of in your users' browsers. The "perceived" performance issues is that, even if you have the server resources to easily handle all the additional http requests, you user now has to spend extra time waiting for latency incurred by those http round trips.
Both languages rely heavily on API's that were designed for different domains.
JavaScript was originally intended to run inside of a browser, so it makes heavy use of DOM API's as well as other in-browser operations such as AJAX. C# probably does not have good support for such API's as it was never intended to be executed directly inside a browser - although Silverlight may provide such operations since it is (in a way) a "C# Sandbox" inside of a browser.
On the other hand, C# is a general-purpose language that was designed to build basically any application, from server-side engines to client applications to services - you get the idea...
I have seen a C# project where javascript is embedded and can execute javascript within a C# code. Have a look here on CodeProject to see how that is achieved.
Technically, no.
You could even use Javascript server-side if you wanted (or client-side C# via different mechanisms).
They're really just two ways of getting the same job done.