I am trying to self host an asp.net website / web application
Ideally web forms
Is this even possible? I have found a fortune of info on how to self host web api, or self host signalR
but I cannot find anything for a simple website (1 page) without all the overhread of iis.
I have tried using nancy, but it doesn't seem like it will run my aspx files, it has its own view engine
I have searched like you but find all about WebApi.
I remember that there is a component of windows called "Internet information services hostable web core".
You can install it by "Turn Windows Features on or off" if you are on a client windows (not on server).
Don't know if you are looking for unit test or other.
I found this page, that i'm going to read. I hope it should be usefull. Mabye if i have time i will update my post after i have made some tries.
Try here http://blogs.msdn.com/b/carlosag/archive/2008/04/14/hostyourownwebserverusingiis7.aspx
You can't self-host web forms using owin, it would require system.web. You'd need to upgrade to asp.net core to be used in the steteless Service Fabric.
Otherwise, I would create a separate SPA app to be hosted in an appservice. Just html, js and css files.
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.
So I'm creating a new .Net Framework 4.8 Web API in Visual Studio 2019 and I'm wanting to know how to create the API as a windows service? I can't seem to find any examples or online resources to do so. I can run the API locally in VS and it opens Chrome and shows the responses under the local IIS Server it spins up. How do I take this same project and compile it as a windows service while still using HTTPS?
Web API is fully capable of being self hosted on top of OWIN, and does not require IIS to run.
Web API self hosted is basically just a console app. So the techniques for turning a Web API console app into a Windows Service are the same as for any other .NET console app. You can use a service manager such as NSSM, or create a Windows service project directly (by inheriting from the appropriate classes, pretty messy) or use a library like TopShelf.
Note that it's generally not a good idea to directly expose this self hosted app directly to the public. IIS provides a lot of security benefits out of the box designed to protect against malicious requests. If you're planning to publicly expose it, make sure you stick a proxy in front of it that will fulfill those security needs.
I am tasked to to build a Web API application. The app will be hosted inside an existing web site - a pre-ASP.NET 5 web application with a WCF web service.
I wonder - can I build the web-api application using ASP.NET Core 1 in a way that it can happily exists as a sub application inside the already existing site in IIS?
Thanks!
Yes, this is possible, I'm doing the opposite of this scenario but conceptually its the same thing. You need to create your subsite as a separate application in IIS with its own app pool. That app pool needs to be configured No Managed Code per the instructions on the Docs site https://docs.asp.net/en/latest/publishing/iis.html
The only other thing you need to watch out for is that the web.config in the subsite will inherit some settings from the root web.config, so you need to remove or clear things sometimes like handlers, modules, etc.
If I understand you correctly it is not possible what you want. Please refer to the following documentation about hosting ASP.NET Core on IIS: https://docs.asp.net/en/latest/publishing/iis.html.
If you specifically look at the .NET CLR version in the application pool it should be "No Managed Code" while your current website is set to a .NET framework version I assume. This is because ASP.NET Core is now cross plaform and completely web server agnostic. It even needs a little 'trick' (the ASP.NET Core Module) to work on IIS. See: "The module creates the reverse-proxy between IIS and the Kestrel server."
But if you follow the link provided above I think you'll manage to work it out.
I have several asp.net website projects for various sites.
Currently I want to add REST API's to these projects so I can start developing mobile apps (using HTML5/JavaScript/CSS3 and PhoneGap) that make use of these webservices.
Since WCF is far more powerful than regular asp.net webservices (among others with control over the service and authentication/authorization), I'd love to add these to my existing website project.
I did a Google search but cant find anywhere a step-by-step tutorial how this can be done. And also if there's any functionality I'd possibly loose when adding WCF functionality
I was also thinking of creating a new project specifically for WCF, but think I'd rather add it to an existing website project.
Can anyone help me with this?
Depending on exactly what your needs are and how your current web site is configured, there are two approaches.
If you are using a Web Site Project, then you should create your WCF service in a different application:
1) Create a new ASP.Net Web Application Project.
2) Add a new item to the project and select the type of WCF Service or WCF Data Service.
When you deploy this project, you will deploy it to your web server, but not as part of your web site since configuring the web.config will be a large manual effort.
If you are using a Web Application Project, then you could add the WCF Service directly to your existing project. However, I only recommend this approach if you are Silverlight applets within the web site that rely on the user's authenticated credentials.
WCF can be configured with a lot of bindings and it can be configured to return xml or json(.net 4.0). Try to create a wcf service configured to use basichttpbinding or wsHttpBinding and to format the response as json and use jquery to interact with the wcf service. This article might help you http://www.codeproject.com/KB/aspnet/Cross_Domain_Call.aspx
I'm responsible for a .NET process running under windows.
The process is running as a windows service.
I would like to have the ability to be able to get some info from the service in a web browser.
For that matter I would like to write a small ASP.NET web service.
The problem is that I want the run the web service within my process.
As far as I know, I can't do that since ASP.NET must run from within an IIS.
so...my question is, is it possible to host ASP.NET server within another process?
I know that in the common scenario, I should have the "process code" run as "code behind" the ASP.NET but in my case, the .NET service is already a part of our product so in this case I'd like to have the opposite.
Thanks a lot.
You don't have to host ASP.NET inside your service. You can use inter-process communications techniques to communicate between your service and a new or existing ASP.NET webapp. Here's an example using named pipes. Or if you're using .NET 3.5 or higher you can use WCF.
If you really want the service to host its own site I don't think embedding ASP.NET is possible but you can use an http component like this one.