Say I make a web app for my main page and publish it to wwwroot (assuming this is the default website). Do I publish other web apps by nesting them within wwwroot. Something like wwwroot/webapp1 for example? This seems somewhat messy to me, so I'm not quite sure if it's the correct way of doing it. Therefore, I'm wondering how the rest of you would organize this?
I generally do not put applications inside of other applications when using IIS. This is because I do MVC applications that can take over all the routing and it'd be really annoying to host applications in the folders inside. Even if you are not doing MVC applications, I would still avoid doing it, and instead make multiple websites that listen on different host headers or ports. If you need to have applications nested like that I would use a reverse proxy like HAProxy and setup routing there instead.
Related
I am about to convert my Winforms applications to an ASP.NET Web Application. The only question I have is the following:
My Winforms application connects to a server via TCP/IP connection (TCPClient), and handles all requests and commands through my own custom protocols (Strings sent that are validated server side and sent back to client)
Can I keep this same Server to handle the requests from my ASP.Net Web Application (I plan on using the same protocol)?
Will there be anything I have to change within the server? How different is migrating a Winforms application to an ASP.Net application?
Do you suggest I use WebForms or MVC?
Well, we might be confusing things here some what.
You have a asp.net application. Then the question is:
asp.net webforms application
or
asp.net webform web site
While both above are similar?
Well, in the first case, a web application means that you compile your code BEFORE web deploy, and for the most part this site is to be considered the WHOLE site (the web config file is in root etc.). And any external assemblies etc. are linked at compile (or publish time). And you are as a general rule NOT EDITING and design and working against the actual web site files. In other words, the folder that holds your project CAN NOT JUST be dragged say to a web server folder and it will work.
And of course this allows you to write custom handlers for pdf files or whatever.
So you can add + hook into the http handlers.
And of course this also allows you to build say a custom logon (authentication provider).
So, you can think of a web application more like a WHOLE application - just like say all the truckloads of source files that you have for a desktop application. You THEN compile this whole big thing, and you compile down to that .exe (or .dll).
You THEN must web publish the whole thing as a application to the web server.
so this is the whole site. Things like custom logon providers, http handlers, and even trapping the Session() start can be done.
And When you web publish, then you get a standard web site, and folders and all of the SOURCE vb.net (or c#) files are removed. Just like compiling down and deploying any desktop application - the source code and files are REMOVED. Needless to say, this approach is "common" to developers coming from a desktop environment.
So no sub-sites really can be done with this model. You are hooking DIRECTLY into the IIS web server.
A web site?
That is ONLY a set of folders that you can have the IIS site work against. In fact one could argue that AFTER you publish a web application, you get "mostly" the SAME thing as a web site.
But this model with any ease cobble up a web site with say 5 pages and JUST deploy that to your local web hosting? Nope!!! - can't do that!
The reason of course is you NOT dealing with ready made web site layouts and files. You HAVE to compile the whole mess into a application.
So like deploying an desktop application you are deploying a WHOLE system.
Now, if you going to have a site with say user logons, passwords and write a custom authenticaiton provider that IIS will respect and use? Again a web site can't do that.
So again you need a code system that supports logon hooks, and lets you control what those people can see and do. So for a line of business application? Well that quite much going to be a whole system - and thus you need control of logons, a master page(s) etc.
So the root, the config files, how they EVEN logon to your site? Everything must be just right and that config setup and file is the BASE SITE configuration for the web server. You can change authnetical providers - include custom http handles etc.
So this is a whole custom site here. And as noted, this is publish type operations.
However, asp.net for a long time ALSO supports what is called a web site.
So when the web started? Well, you just dumped web pages into some folders - maybe some hyper links to jump around. But a LOT of developers started out working this way. And because you can DIRECT edit the files and save them back to the site? Then no real concept of a application compile or even a web publish exists in this context. It just files sitting in a web ready format and a simple set of folders.
So a asp.net web site = just folders and files - no publish.
Now for one small change, no question that a web site is nice. And BETTER is that you can say take a set of folders and just DROP them into a existing web site - your not really publishing anything, so like the old days, you just edit and copy files to the web server folders and they work. This of course common fair html files.
But IIS does support using aspx pages (files) this way also!
Since this is just SOME folders with web pages? Then you can create and build say a bunch of different folders - each having their own cute little mini-web site. And this means that publishing to your cheap $8 per month asp.net hosting is possbile. You don't need a full IIS server and the ability to manage the IIS server system. All you EVER do is just copy files to the web site. Nothing more, nothing less. As a result, you don't have use of Session() start, and even the logon events are not under your control (unless of course you rolled your own and don't use IIS security.
With simple files and folders? Then your $8 hosting site can be used.
However, all if not most low cost simple hosting sites don't support asp.net applications.
So you can think of a web publish as replacing your base web application system the hosting provider gives to you. it also why you do NOT get use of the full ASP.net and IIS configuration options for the web site (your web provider controls and has that!!!).
One huge benefit of web sites is ease of change. As noted, you can point VS to directly edit even on the live web site files!!! There is really not concept of publishing - you just editing files and saving them to the web site folder. And this is really nice for a small change - the web site will re-compile the code for you, and for a large site, you can make a change to one wee bit of code behind and the web page - just copy that page and code to the site and you are DONE!!!
With a web application? you are doing a full-re compile, re-publish to the site for ANY and all changes. (well, ok, you could sneak in and say edit/change some markup on web page, but for the most part anything that messes with controls on a page would and could very easy break the compiled .dll's that are driving that page.
do you suggest I use WebForms or MVC?
That is a huge deal. MVC does not even have a visual designer for your web pages (you can only see and write markup).
And the whole MVC code model and whole event model is VERY different. So perhaps while a great idea to adopt MVC? (it is!!), it is darn near a whole re-write of your existing site - they work very different from asp.net webforms applications.
to a server via TCP/IP connection (TCPClient), and handles all requests and commands through my own custom protocols
If you mean custom http handlers? No, web sites don't' support this, you have to be creating a web site application. You can't by a simple act of placing some web pages on a web site have the lower level http handlers and network stuff change - you can only do that with a web application. Same goes for the authentication provider(s) you choose - simple web sites don't allow you to build your own custom providers (but you can roll your own logon system from scratch - but you not then enjoy even simple setups that automatic secure web pages based on their memberships in given security roles.
I have an asp.net web api application should I use Self Hosting or should I host it on IIS. I am looking for better performance and security. Which one should I be using?
I just show the answer from here.
What I've found (basically just pros for IIS hosted):
You lose all of the features of IIS (logging, application pool scaling, >throttling/config of your site, etc.)...
You have to build every single feature that you want yourself HttpContext?
You lose that since ASP.NET provides that for you. So, I could see that making things like authentication much harder WebDeploy?
IIS has some nice specific features in 8 about handling requests and warming up the service (self-hosted does not)
IIS has the ability to run multiple concurrent sites with applications and virtual directories to advanced topics like load balancing and remote deployments.
And this
Self-hosting is good when you're not on a server -- for example, you want a desktop app to be able to listen for API requests.
But I think you would be able to achive am faster performing and more stable server if it is worth your time. But you need to be carefull not to make basic security mistakes like public accessable configuration files or ddos.
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 haven't put up a web site/app yet, so please excuse my ignorance.
Eloquera looks like a great object database, but the embedded (in-process) mode is not meant to be used for a web app. I have to therefore somehow run the server exe on the server to use it.
When I use the server on my comp it first needs to be allowed through the firewall, as one would expect.
I am wondering if I could somehow run the server.exe in the same process as the web app and still have it be a tcp/ip server accepting multiple connections.
Or perhaps there are normal ways of dealing with this situation on typical "retail" web hosts?
In Short: I believe I am trying to embedd a tcp "server.exe" into an asp.net web application
Seems like the usual thing to do in this situation would be to get a dedicated server, or, more realistically in my case, a VPS (I did say I was learning!).This really pushes up the costs and hassle. No shared hosting that I can see offers Eloquera DB.
So, it seems that my only option would be a low-end VPS.
It's disappointing that I can't use embedded (desktop mode) eloquera in an asp.net web app, but I understand that this is to do with the nature of web apps.
I have an asp.net 3.5 site and I've just written some wcf services. It is ok to just drop the .svc file right alongside my .aspx files or should I move my .svc files onto a separate virtual directory and IP and call it something like services.mydomain.com.
Just wondering what best practices are. Maybe it doesn't make any difference? I have a client app that will update the database that my web site uses. It updates through an IIS hosted wcf service.
IMHO it would be better to isolate the web service into a separate virtual directory and application pool. In this case the client application and the web service don't share the same AppDomain and if one fails the other will continue serving requests.
In our project we tend to keep them in separate virtual directories. I like to regard the service as something that can be used by more than one client, and so I like the deployment and hosting of it separate from the client. Of course, if you just stick it in a separate virtual directory you can argue to what extent the hosting is separated, but at least it is separate on a logical level, and easily moved to separate physical hosting if necessary.
You definitely don't want to have them in the same place - not least because it makes it hard to configure the appropriate level of security. It also makes configuration simpler as they won't share a web.config.