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.
Related
What is the kestrel web server and how does it relate to IIS / IIS Express?
I come from developing apps on IIS Express and hosting them on an IIS web server. With ASP.NET Core I have a dependency on Microsoft.AspNetCore.Server.Kestrel and my startup has .UseServer("Microsoft.AspNetCore.Server.Kestrel"). But when I run my website, I still get the IIS Express icon in the system tray. Someone asked me if I was using IIS Express or Kestrel and I didn't know what to say!
I don't have any cross-platform requirements as I develop on a PC and host in Azure, so I'm confused if I even need Kestrel, but it doesn't seem like there's an alternative - even the simplest samples use Kestrel.
I'd like to offer an alternative answer, with some history, so that you might understand why Kestrel comes, even if you only use Windows and IIS.
At the very beginning of ASP.NET development before year 2000, clearly Microsoft created two pieces to host ASP.NET WebForms apps,
Cassini, later became ASP.NET Development Server in Visual Studio. It is a fully managed web server written in C# based on HttpListener. Of course, since it was for development only, many features were never implemented. As Microsoft made the source code of Cassini available for the public, there are third parties who forked the code base and added more features, which started the Cassini family.
ASP.NET support on IIS (revision 1). Because IIS was 4.0 and 5.0/5.1 at that time, which has nothing like application pools, ASP.NET even has its own worker process (aspnet_wp.exe).
So to develop a web app, you use Cassini, and to deploy you use IIS.
The introduction of application pools in IIS 6 required some changes on ASP.NET side, so aspnet_wp.exe became obsolete and replaced by aspnet_isapi.dll. That can be seen as ASP.NET support on IIS revision 2. So ASP.NET apps are being hosted in IIS worker processes w3wp.exe.
The introduction of integrated pipeline in IIS 7 and above required further changes, which replaced aspnet_isapi.dll with webengine4.dll. That can be seen as ASP.NET support on IIS revision 3. ASP.NET and IIS pipelines are unified.
You can see ASP.NET has become much more complex and tightly integrated with IIS, so Cassini started to show its age, and gradually was replaced by IIS Express (a user mode lite IIS).
Thus, in many cases, when people blame that IIS is slow, they should blame ASP.NET in fact. IIS itself without ASP.NET is pretty fast and stable, while ASP.NET was not developed with enough performance metrics in mind (as WebForms focuses quite a lot of productivities and RAD).
Then in November 2014, ASP.NET 5 (later renamed to ASP.NET Core) was announced and became a cross platform technology. Obviously Microsoft needed a new design to support Windows, macOS, and Linux, where all major web servers, nginx/Apache (or other web servers) should be considered besides IIS.
I think many would agree that Microsoft learned quite a lot from NodeJS, and then designed and developed Kestrel (based on libuv initially but might move to other technology soon). It is a light-weight web server like Cassini initially, but later more features are being added (like another answer commented, much more features so can be treated as a full web server). Though fully managed (some native dependencies exist), it is no longer a toy web server like Cassini.
Then why cannot you just use Kestrel? Why IIS Express and potentially IIS, nginx, or Apache are still needed? That primarily is a result of today's internet practice. Most web sites use reverse proxies to take requests from your web browsers and then forward to the application servers in the background.
IIS Express/IIS/nginx/Apache are the reverse proxy servers
Kestrel/NodeJS/Tomcat and so on are the application servers
Another answer already showed a link to Microsoft documentation, so you can take a look.
Microsoft developed HttpPlatformHandler initially to make IIS a good enough reverse proxy for Java/Python and so on, so planned to use it for ASP.NET Core. Issues started to appear during development, so later Microsoft made ASP.NET Core Module specifically for ASP.NET Core. That's ASP.NET support on IIS revision 4.
Starting from ASP.NET Core 2.2, ASP.NET Core Module for IIS (version 2) can host .NET Core environment inside IIS worker process (w3wp.exe), quite similar to ASP.NET 2.x/4.x. This mode is called "IIS in-process hosting". It can be considered as ASP.NET support on IIS revision 5.
Well, quite lengthy, but I hope I put all necessary pieces together and you enjoy reading it.
One recent update (Jan 2023) is that ASP.NET Core/Kestrel can be used to host reverse proxy functionalities itself, as the open source YARP project revealed.
Kestrel/YARP is now widely used inside Microsoft Azure to replace IIS ARR in many scenarios as reported, so literally now you can host your own production web apps with Kestrel/YARP without any other web server (IIS/nginx/Apache) in front as well.
What is Kestrel
It's a full blown web server. You can run your ASP.NET Core application using just Kestrel.
But when I run my website, I still get the IIS Express icon in the system tray
In your ASP.NET application, probably in the wwwroot directory, you'll see a web.config that contains this:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="httpPlatformHandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified"/>
</handlers>
<httpPlatform processPath="%DNX_PATH%" arguments="%DNX_ARGS%" stdoutLogEnabled="false" startupTimeLimit="3600"/>
</system.webServer>
</configuration>
This is the HttpPlatformHandler. Essentially, what this does is forward all requests to Kestrel. IIS Express (and IIS for that matter) will not run ASP.NET themselves anymore. Instead, they will act as proxies that simply pass requests and responses back and forth from Kestrel. There is still advantages of using IIS, specifically it gives you security configuration, kernel-level caching, etc.
From ms docs at:
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?tabs=aspnetcore2x
Kestrel is a cross-platform web server for ASP.NET Core based on
libuv, a cross-platform asynchronous I/O library. Kestrel is the web
server that is included by default in ASP.NET Core project templates.
You can use Kestrel by itself or with a reverse proxy server, such as
IIS, Nginx, or Apache. A reverse proxy server receives HTTP requests
from the Internet and forwards them to Kestrel after some preliminary
handling.
UPDATE: .net core 2.1, Kestrel uses managed sockets instead of libuv
From asp.net core 2.1 docs at: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-2.1#transport-configuration
With the release of ASP.NET Core 2.1, Kestrel's default transport is
no longer based on Libuv but instead based on managed sockets.
Multiple apps on the same port is not supported in Kestrel.
Windows Authentication does not exist on Kestrel.
Request Filtering is much more fully featured in IIS.
Mime Type Mapping is much better in IIS.
HTTP access logs aren’t collected in Kestrel.
I am having a problem setting up a website hosted on Windows Server 2012. The website is just the default website you get when setting up a new "ASP.NET Web Site (Razor v2)" site. Then I simply published it using the "Publish Web Site" option in VS2012. I have also added the .cshtml extension in the MIME types. The server is running IIS v8 and .NET v4. The problem is when I visit the website this is how it displays:
http://i806.photobucket.com/albums/yy341/SamuelCB/Razor%20Error/Untitled.png
Is there anything I am missing?
Items to check:
rarely do MIME Types actually matter if IIS and ASP.Net are installed properly
don't mis-interpret this statement, I'm not saying MIME types don't matter, just that if/when configured properly all of this, IIS/ASP.Net is "out of the box" without mucking with MIME types.
The issue with adding ".cshtml" manually is that IIS will (now) serve it, but the ASP.Net engine isn't (necessarily "there" for) handling it (e.g. integrated mode). That's why you're seeing the "unparsed" (raw) version of the file...code and all...it's all IIS (no ASP.net engine is configured to handle it).
if you run your own box, run Web Platform Installer - and it should give you insight on what's installed vs. what's not. Pay attention to ASP.Net bits and versions. You may need to (re)register ASP.Net
if you're hosted, just because your host has .Net Framework 4.x installed, doesn't mean they have all the bits and pieces of ASP.Net installed as well. Ask your host for guidance instead of doing a guessing game. I often have to "load" things that my dev machine has "by default" (of course its my machine) because I end up with non-functioning stuff when deployed to my host. You're not even getting an ASP.Net engine error, so that's a sure sign ASP.Net needs some work.
Nuget is excellent for this task. Some items that might be necessary to be "bin deployed" (aka. you have to add them to your deployment/upload to /bin directory on your host):
Microsoft ASP.NET Razor
Microsoft ASP.NET Web Pages
Microsoft.Web.Infrastructure
Unrelated: This sounds more like it should go to ServerFault rather than here on SO...I don't mind...but the community may think differently...and you might even get better answers....
Hth...
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).
I've developed a very simple ASP.NET (jQuery) application.
The RDBMS is MS Sql Server but I could easily convert it in MS Access.
My client would like to have it available on a CD, ready to run.
I was thinking to convert it in a WinForm app but, still, I have to install the framework on the client.
Is there any other "possible" solution?
You're going to have more trouble trying to run a web app on a client machine than you will a desktop application.
A web app requires some sort of web server running, but a desktop app just needs the framework.
You're going to be better off converting it to a desktop app.
If your users are running versions of XP, Vista, or Windows 7 that include IIS, you could conceivably install the application into a virtual directory. That's a lot to ask from end-users, though. Most users won't have IIS installed even if they are running a version of Windows that offers it.
I haven't tried this, but I just found it by searching for "portable asp.net web server"
http://www.codeproject.com/KB/aspnet/TinyWebServer.aspx
Introduction
Have you ever wanted to show up an
ASP.NET project where IIS was not
accessible? Have you ever thought of
if there can be a way to carry your
web server wherever you go, i.e., on a
USB flash stick or even a CD?
If so, then this cool TinyWebServer is
for you! This tiny portable web server
can be used for testing and developing
ASP.NET projects, wherever IIS is not
available.
Should be simple if you convert it to HTML & jquery script. As HTML doesn't require any seperate runtime & also worth considering asp.net runtime also does the same thing when the response is sent to the client.
You maybe able to do this by using something like cassini http://www.asp.net/downloads/archived/cassini/. This is a simplified version of the visual studio web server that you see when you run from visual studio.
In my team we have used this and wrapped it in a exe that allows us to start the cassini server and start a browser to the cassini server address.
This still relies on the right version of .NET Framework being installed.
EDIT: Some more recent links http://ultidev.com/Products/Cassini/ and
http://blogs.msdn.com/dmitryr/archive/2008/10/03/cassini-for-framework-3-5.aspx
Hi guys,
We have a mixed development environment of three servers running: Win Server 2003 & 2008, IIS 7 & IIS 6, ASP.NET 2.0 & ASP.NET 3.5. Previously, all three servers were Server 03/IIS6/ASP.NET 2.0, but with this new change, I am finding that pushing/moving any applications from server to server is always a terrifying experience because there are always a variety of problems with the web.config from server to server. I used to consider myself a confident ASP.NET developer but now I am frightened to come to work every day.
I have always used the web.configs that VS generates for me on the Win 2003/ ASP.NET 2.0 server. None of our web.configs are "leet", they are just normal, although we do use ScriptManager and UpdatePanel.
To get by, as a temporary fix, I'm having to remember that when projects are moved/tested/deployed, never to move or overwrite any web.configs and things get confusing very fast. I've tried "ducttaping" like suggested here my web.configs with the new IIS7 stuff but even that doesn't work all the time.
What can I do here, what's going on? Is there a standard web.config that will work on all of the servers and do the UpdatePanel and ScriptManager ?
[edited question]
Since IIS6 is the baseline install for your application, you should make sure to run the application in "Classic" mode under IIS7. This makes configuration the same as an IIS6 box. This is how we run our web applications for now until we have fully migrated to 100% IIS7 server environments and we have zero problems with deployment/runtime.
To do this you can either choose to run your app under the built in "Classic .NET AppPool" that comes with IIS7 or, assuming you create your own custom application pools, just make sure you set the "Managed Pipeline Mode" to "Classic" under the "Advanced Settings" dialog for the app pool.
You should seriously look at web deployment projects for visual studio 2008.
This is an official add-on for Visual Studio that gives you a new project type called web deployment project. Among the most useful features is the ability to do web.config search/replace as well as pre-compiled builds of your web sites or web application projects.
In your case, what you'd do is create a solution configuration in visual studio for all of your target web servers. Then you'd create a web deployment project for your web app. In the properties for the deployment project you tell it how you want to compile the project and what web.config replacements you want to use for each solution configuration.
The end result should be that you can open Visual Studio, pick a solution configuration, build the deployment project. The build will create a folder with everything you need for that environment including the correctly configured web.config files. Then you just copy the folder to your server and you are up-and-running.
Best of all, since the different config files are all stored in the projecct, it lets you manage your configuration in one place and check it all into source control.
Do note that there is no equivalent in Visual Studio 2010. Instead, VS 2010 has a whole new deployment mechanism called MSDeploy. With 2010 you don't need a seperate project for deployments, and MSDeploy goes a lot further allowing you to package your SQL databases and other stuff too.
You can use the Classic mode under IIS6 by changing the process. That is actually pretty simple and it should work.
Another approach would be to automating your deployment process and have it so that it deploys the correct web.config to the server when you need to update your application.
If you run your IIS 7 websites using the Classic .NET App Pool, then the config files will match what you would use for IIS 6. That's probably the easiest thing to do until you're ready to migrate everything to IIS 7.
Knowledge is a great way to get over fear. Figure out what's going on (you're currently grasping at straws) and the fear will go away.
It's my guess that you'll do better if you refactor the code that uses the config file. Sloppiness there can definitely explain your weirdness and inconsistencies. You can't control much with your config settings if the code isn't behaving properly.