We have a desktop client application and recent customer requests indicate that they would like to have some dynamic HTML content served and displayed by the application.
We are considering hosting a simple ASP.NET application in a local process, accessible only from the local machine (similar to the ASP.NET development web server used when debugging from Visual Studio).
How can we run an ASP.NET application locally without IIS? IIS is not an option because most client machines will not have it installed.
Is there a leightweight ASP.NET web server that could run locally similar to the development web server that VS is using?
I have found some information about "Cassini". Is this suitable for production use? Can it handle ASP.NET MVC? Are there any alternatives we should consider?
I have not used it myself, but you can try the mono XPS server.
It is a stand alone webserver.
The easiest way to start XSP is to run it from within the root directory of your application. It will serve requests on port 8080. Place additional assemblies in the bin directory.
Cassini is in fact also a good option - it is the development web server that comes with visual studio (so widely distributed, used and tested) and is also used by the open source ScrewTurnWiki. See wikipedia.
In regards to your "only locally" requirement - a web server will serve any request made to the right port. In order to limit accessibility, you should use a firewall that will block any external requests.
You might consider using WCF to host a service on the local machine that can serve the data without having to host a full blown web server.
If you do this, WCF allows you to expose the service with multiple endpoints and make it available through HTTP, TCP, or Namepipes. Namepipes would restrict traffic to only the local machine.
I have also tried IIS Express. It works great with ASP.NET MVC. Right now it is available only with Web Matrix, but installing web matrix is easy.
Coming back to this question three years later, ServiceStack.NET with self-hosted option seems like a good choice. While it is not ASP.NET MVC directly, it provides a good API and features are on par with ASP.NET MVC/WebAPI (or in some ways better).
Related
So, I setup a Win10 box as an Apache server; built VS19 Asp.net webforms app, which works as expected when run in VS. published to the C:\Apache24\htdocs folder. Now, I setup port forwarding on my ISP-provided "Internet IP Address" to point to my local server. If I use any browser (outside of my LAN) to access that address (e.g. http://xx.yy.zz.qq - not showing actual IP for security reasons) I will see the page titled "index of /", and the list of files that I published to that htdocs folder. If I put in INDEX.HTML file in that folder, it will be displayed; but since I see Default.aspx as the 1st entry in the IIS Default Documents list, with NO index.html present, I still just see the list of files, not the aspx. I don't think the fact that I've not yet established a DomainName-to-IP binding should make any difference to this issue, but I can't be sure. Any thoughts? As you might guess, I've not done this before! :) ). TIA!
Jim
I made sure that the VS instance of the website was not running, just in case that might cause IIS confusion; but I don't think that would be the case.
As noted, I can't see how a non .net server going to run/launch/process correctly aspx pages that require IIS as the web server?
I mean, IIS can't run a web site designed for Apache, nor can say IBM "web spere" web server either.
I am trying "hard" to think how a application built in .net framework going to work with a web server that not designed to work with the .net framework?
I mean, if you have a computer, and have a word document, then you need word installed to work with that document.
If you have a PDF file on your computer, then you have to install some PDF software to use that PDF document.
A web server is not some "magic" box, but is a plane jane computer, with some software installed on it. So, if you build a aspx .net framework site in .net, then that computer will require the .net framework to have been installed, and require the correct type of software to work with those pages - in this case IIS.
Now, to be fair, you CAN do this with .net core, since .net core can run on quite much "any" computer (that supports nigex). However EVEN in that case, they FAKE and TRICK you, since how they achieve this "magic trick" is when you build the .net core application, the build process includes a WHOLE WEB SERVER as part of the build!!! (this lighter weight web server (kestrel) thus can work if you forward the ports and requests say from Apache, or quite much any web server. But MAKE NO MISTAKE here, a WHOLE .net core compatiable web server is included in that build, and thus that .net web server IS STILL required to run that .net code.
Unfortunately, the .net framework (as opposed to the .net core choice) does not upon build of your web site INCLUDE that WHOLE WEB SERVER as part of the build.
So, .net framework sites requite the correct software to work, and that correct software in this case is the web server called IIS (Internet Information Services).
You can no more suggest/attempt/assume that some program to load and read a PDF document is now out of the blue going to consume and work with Excel files, or word files.
hint:
Software build to a particular library of code requires the correct software to run and work. Kind of simple!!
So, a computer with a web server?
That is JUST a computer with software installed on it, and you need the correct software installed on that computer to consume the files etc. it was designed form.
Apache web server can no more consume a "application" or "web site" designed for IIS then it can consume other files etc. that are designed for use with a 100% different application. this is how all software works, and it not clear why you would think that Apache, or IIS, or word or Excel would work any different at all here?
Now, there was the "mono" project, and that was a port of .net framework that allowed the .net framework to run say on Linux, and there are some examples of some attempts to run aspx pages that way, but it is a galactic mess of epic proportions, and really not the way to go.
However, as stated, the .net core system DOES run on just about any platform, and it does have the above "magic trick" of being able to run on Apache, but behind the scenes, that software build actually includes a WHOLE WORKING web server that is .net core compatible, and that WHOLE web server is included with your build, and thus some are "fooled" by this magic trick that .net core web sites can run on Apache. They look like they can, but they are not, and in that example case (of .net core, NOT .net framework), the site seeming to work on the Apache web server? Nope, what occurs is the Apache web server simple hands off any web request to the REAL WORKING AND INSTALLED .net core web server!!! (thus Apache really only acts as a router, or "hand off" machine, and all the REAL web processing occurs in the .net core web server called kestrel).
So, you can do as you ask, but you would have to dump "web forms" and build the web site with aspx pages as a .net core web site. If you do that, then YES you can use Apache, and it will work, but behind the scenes, it ONLY works because that build process of the .net site ALSO includes THAT WHOLE COPY AND WORKING COPY of a .net core web server as part of the build. As noted, this magic trick option during the build process is NOT available for .net framework, but is most certainly available for the .net core choice.
So, in your case of using Apache? Software designed for a particular type of web server must use the correct type of web server. Same goes for IIS - it can't consume nor run a web site designed for Apache. I mean, how software works on your desktop is not any different then how software on a web server
The pages you have implemented with the .aspx are part of the ASP.NET Web Forms framework. This framework is part of the .NET Framework. The main server required to host Web Forms applications is IIS (Internet Information Services). Since you are working on a Windows machine, you can research how to setup IIS to host your Web Forms site if you wish. If you still want to use Apache as the front end for your site, you can even have it proxy requests to your site hosted in IIS, although there's probably little benefit and much complexity from such a setup.
Apache out of the box does not include support for hosting Web Forms applications. There is an open source project called Mono that seeks to implement an alternative version of .NET Framework and allows the use of alternative web servers such as Apache. But Mono has largely been superseded by .NET Core.
.NET Core is the official replacement for .NET Framework. It is open source and cross platform by default, and the ASP.NET Core web framework that runs on .NET Core includes a Kestrel web server. This can be utilized with Apache (or any other web server) in front of it, acting as a reverse proxy. It is not a magic trick, but a rather standard approach for web applications these days. However, ASP.NET Core does not include the Web Forms framework, so you would need to re-implement your application in a more modern alternative that's supported by ASP.NET Core if you intend to stay in the .NET ecosystem. There are many alternatives in ASP.NET Core including MVC, Blazor, Razor Pages, and Web API.
I have developed a well-decoupled website using WebAPI and AngularJS as follows:
SOLUTION
|—— WEB.API Project
|—— Website pages Project
'—— Other projects related to functionalities
This setup is on my own computer.
Now I'm here wanting to deploy to my web server (iis 7.5, privately owned, WebDeploy installed). It is possible to deploy both projects on a single web site? (other projects are class libraries, so no hassle)
For what I know, I have to deploy the WebAPI part to a website, and the UI part to another website. May I put them on a single website?
You can put the Web API project in a virtual directory under the main web site. That's what we are actually doing in our current project.
You can, but you should be worried when files conflict. If both projects have a web.config for example, this could break either of them.
If not, it should be possible, but I wouldn't immediately recommend it. I would split them off in separate virtual directories so you can maintain the two separate projects easily.
You could also self-host the Web API using OWIN, so you wouldn't then need to set up a project in IIS etc and you could then have multiple clients talking to the same API.
There's a tutorial here which is more advanced.
I have a near identical project setup. Personally I picked 2 separate apps, I have a multi server setup with load balancers - the choice may have been different if I had a single server or low amount of expected traffic.
This gives the advantage:
I expected my WebAPI to have a larger amount of traffic than the web pages, due to mobile clients also consuming the WebAPI as well as the front end webpages. Because the API is in its own website, it has its own app pool - this means that each application has its own resource pool (app can grow to use more memory and CPU better), not shared like they would be on a virtual directory.
Disadvantages:
Because there is two separate app pools, I have one bound to port 80 and the other to port 8080. As I had a large server farm to roll this out on, I already had a load balancer in front of the webservers - hence to make the URL pretty (i.e. drop the port 8080 from the URL) i added a load balancer config to allow traffic to come in on a given url on port 80 and be redirected to port 8080 on the internal webservers. This isn't really a issue if you don't mind ports in your URL's.
I am not clear that what is the purpose of running asp.net application in IIS. Why we go for IIS. Any difference amoung running in VS and IIS?
Please suggest me.
Simply because you won't run asp.net in VS on production !
IIS Express and the VS Development Server are designed to emulate IIS, but they are configured differently and may fail to reveal errors that can occur when you deploy to a production version of IIS.
Visual Studio Development Server, also known as Cassini, is very limited. It does not have all IIS features and we will have a few problems when resolving References to Root-Level Resources or on security.
For example, when you run a page using IIS Express/VS Development Server, the page runs in the context of your current user account (often Admin). In IIS 7, by default ASP.NET runs in an account that has limited privileges (know as AppPool Identity, see here). This difference can be a source of problems when you deploy on production a web application.
A complete list of Hosting options is available here.
Internet Information Services (IIS) for Windows® Server is a flexible, secure and manageable Web server for hosting anything on the Web. From media streaming to web applications, IIS's scalable and open architecture is ready to handle the most demanding tasks.
Application pools allow you to isolate your applications from one another, even if they are running on the same server. This way, if there is an error in one app, it won't take down other applications.
Additionally, applications pools allow you to seperate different apps which require different levels of security.
Here's a good resource: http://www.advancedinstaller.com/user-guide/tutorial-iis.html
http://www.iis.net/learn
I have made an application in asp.net which sends and receive sms, it works very similar to desktop application and it will be installed on servers to send sms alerts, but the problem is if server does not have iis, it will not work. I have seen many apps which when installed, have their own server and port, you do not need to install any IIS, when you just double click it starts running on a special port and works well, similarly visual studio also runs its own port in development mod, so what is the best way to make such solution for an asp.net product.
If you're talking about how to host a service in an application outside IIS, Windows Communication Foundation (WCF), which allows you to host a service in a Windows Forms executable, Console Application, Windows service, or IIS.
It's too big a subject to explain fully here, but there's a nice starting point here.
This will allow you to create the host, and allow you to hose services similar to web services, but with more options for how to connect. (http, tcp, etc.)
But it's not an ASP.NET host. For that, you will need a web server that can execute ASP.NET, such as IIS. There's no way to get around the need to have a web server, whether it's one of the many already established, or if you write your own. I believe there are extensions for Apache that allow you to do so via Mono, but I've never used them. Writing your own would be, in my opinion, a waste of time and a bad idea.
The simplest solution by far is to specify that IIS instaled with the appropriate framework is a requirement for using your website.
Edit
However, if you REALY want to write a WinForms app and have it host ASP.NET, it looks like this previous question has an answer that would help. You can use the Cassini web server, the same one that Visual Studio uses.
Currently our dev team set up all the websites they're working on in IIS on their local machine. We're thinking of switching to using the built in ASP.NET development server instead.
Is this a good idea? What are the pros / cons of using the ASP.NET dev Server? Are there any gotchas we should be aware of?
Thanks.
NB: Running on Win XP / IIS 5 / VS2005
Edit:
Didn't realise it was called Cassini.. More answers for Cassini v IIS here.
There is nothing that the ASP.NET Dev WebService can do that IIS can't (You can set breakpoints etc, just attach the VS debugger to the ASP.NET runtime).
However, the ASP.NET Dev WebService does not represent a true production environment, and as such you can get caught by gotchas that you wouldn't expect when you deploy to production.
Because of that, I mandate that all development is done using IIS on a local machine. It doesn't take much work to configure a site in IIS.
It's a very good idea. Here are some reasons for:
You no longer need admin access to your machine for web development (it can still be helpful).
It's much easier to test a quick change and continue work, and faster iteration cycles are good.
It can simplify setup and deployment of your development environments.
The XP version of IIS has limitation that are not present in the Server version that Cassini side-steps.
The only argument I know against is that there are a couple very rare edge cases where the Cassini built-in server doesn't exactly mimic IIS because you're using odd port numbers. I doubt you'll ever run into them, and using Cassini as the primary dev environment does not preclude developers from also having access to IIS on the machine. In fact, my preferred setup is Cassini first for most small work, then deploy to my local IIS for more in-depth testing before moving code back to the shared source repository.
[Edit]
Forgot about url re-writing. You do need IIS for that. And an example of a limitation of the built-in XP IIS is that you are limited to one site in XP (can have multiple applications, but that's a different thing).
I had to switch (back) to IIS for one project, because I needed to set some virtual directories which is not possible on the ASP.NET Development Web Server.
As I stated here: https://stackoverflow.com/questions/103785/what-are-the-disadvantages-of-using-cassini-instead-of-iis your developers need to be aware that Cassini runs as the local user, which is typically an admin account for developers. The development will be able to access any file or resource that their account can, which is quite different from what they will see on an IIS 6 server.
The other thing that's a pretty big gotcha is debugging web services is much easier using IIS and vdirs rather than separate Cassini instances.
I know at one point I had an issue with Authentication not working as expected on Cassini (built in development server)
Also, if you need to test things like ISAPI plugins (a re-writer for example) I'm not sure how that's done on Cassini.
The constantly changing port is also rather disconcerting to me. Also, for each web project in your solution it fires up another instance of a Casini server, and each one takes anywhere from 20 to 50 MB of memory.
I use IIS all the time, it's pretty easy to setup, and you guys are already doing that...
I've used both methods and I prefer having IIS locally vs. using the built-in server. At very least you're more consistent with the final deployment setup.
Also, when using IIS 5.1, be sure to get JetStat IIS Admin, it adds functionality that is disabled out of the box on IIS 5, such as being able to setup multiple sites.
I have run into the following limitations with the asp.net dev server:
does not support virtual dirs. If you need them in your app, IIS seems to be your only choice
Classic asp pages dont run in dev server. So if you have a mixed web app (like I have at my client right now), IIS seems to be the solution
If you need an admin UI to configure settings, IIS works better
Of course IIS requires that you be a local admin.
Another distinction I noticed is that Cassini runs as a 32-bit process and you have no control over it, whereas you can control the application pool of your IIS app to disallow 32-bit (assuming your IIS is running on a 64-bit server). This becomes especially important if your web application is going to call APIs in 64-bit processes such as SharePoint Foundation/Server 2010. When you debug your web app with Cassini as your debug server, you'll get "The Web application at url could not be found. Verify that you have typed the URL correctly" type errors when instantiating objects. If you debug using IIS with the app running in an app pool that runs as 64-bit with an identity that allows access to sharepoint database then you'll be able to debug properly.
In VS12 the development server is way slow, takes a few seconds to download a 2kbyte file. This did not happen in vs10. When you have a bunch of jquery files and css this is a real problem. Also every page requeries all the css/js files. Very very slow regression testing.
The main issue I've run into with the dev server is SerializationExceptions with custom security principals stored on the thread context. Details here.