I want to self-host an ASP.NET web application from a service that we have developed. Their are only 2 requirements, the first being no external applications to be redistributed, i.e. no solutions like xsp2 or IIS express, etc. Second, I'm trying to not leave aspx/code-behind files laying around on the filesystem. I'd prefer something that can host from embedded resources or from a compiled ASP.NET Web Application (.dll and placeholder aspx files).
I realize that anyone could decompile the binaries, etc, but I'm really just trying to not make it 100% easy to tinker with the web interface. I've looked at a few options, but none that will properly host a compiled Web Application WITHOUT an external application.
Are there any (preferably 100%-managed) libraries out there that can do this? Even if it's raw files in a virtual filesystem of some sort (although that would require a driver-installation which I want to avoid).
There is one Open Source Embedded C# Web Server on CodePlex but it is not actively developed.
You can however, fork it as per your needs.
http://webserver.codeplex.com/
Related
I've got this scenario: I want to build a website to a friend só he can manager his business. I want to do it like it is going to be online, using C# MVC. The thing is that only my friend will use the system, on localhost:/something...
My question is: if I put the files of my app on Apache, installed in my friends computer, will he be able to access the web site thru localhost:/mysite...?
I think for your use case ASP .net Core makes perfect sense. Have a look at the these articles and sample
https://docs.asp.net/en/latest/intro.html
https://github.com/aspnet/MusicStore
Easy to run/deploy and don't need IIS Install either.
https://sourceforge.net/projects/mod-aspdotnet/
mod_aspdotnet is a loadable Apache 2 module for serving ASP.NET
content using the Microsoft's ASP.NET hosting and .NET runtime within
the Apache HTTP Server process. Non-Windows users should look at mono
(mod_mono) for an alternate implementation.
This is more of an Architecture question, and I want to know all the possible pros and cons of the approach.
In my org, we have an ASP.NET Application, a Web API Project, and underlying DLLs which calls App Tier which is physically on different server. In ASP.NET Application, for a particular piece, we are having a SPA.
For most of the things (I would say 99 % of the things) , we are making ajax call from our SPA to Web-API to access underlying functionality.
SPA and WebAPI are both deployed and hosted on same Web Server as different applications and WebAPI has reference to underlying DLLs so these DLLs are deployed with WebAPI.
For one of the functionality some server side processing needs to be done on ASPX page's code behind.
I am suggesting to my team to do keep calling from SPA to WebAPI using http client and maintain loose coupling that we have between Application and the dlls via WebAPI, but many (I would say everybody else in my team) is in favor of adding direct reference of DLLs to ASP.NET application, so now these DLLs will be deployed with ASP.NET Application alongside.
Is my suggestion not so good provided ease of implementation that we would be getting with adding direct reference for DLLs in ASP.NET Application? Let me know if I am not explanatory enough.
I would be in favor of using a DLL directly if you could get rid of the Web API altogether. Since it does not sound like you are planning to do that, I think your suggestion to continue using the Web API from your application:
Using the DLL from two places creates a deployment liability: every time you update it, both places must be updated
Changing the code in DLL requires testing the change from two paths - A-D and A-W-D
Fixing a bug in the way that you call your DLL would likely have to go to both A and W, instead of going to W alone.
Of course, the path A-W helps you exercise your Web API component, too, helping you detect bugs early.
Background
We are using a reporting tool which is .NET based.
The reporting tool uses a settings file which is a pain to update between environments (doesn't do transformations, etc.)
The reporting tool allows us to write .NET plugins to be run at certain times so I can modify the settings file on the fly
We have access to IIS and can add settings / connection strings at that level
Goal
I'd like to:
Simplify deployment by moving all connection strings & settings to the IIS server-level settings.
even our developers have IIS available locally so this won't be a problem for them.
Use the .NET plugin that I'm writing to connect to the server the app resides on and pull the connection strings and settings files.
Question
How can I access server-level IIS connection settings programatically from within a .NET class?
Notes / Things to Consider
This application does not use a web.config.
EDIT: While apparently the app doesn't use a web.config, one does exist when the app is deployed, so theoretically I could access it via the .NET plugin.
These are actually technically 5 different web sites. I'll be implementing the plugin the same way for each web site
The IIS servers are only used for this purpose, so I'd like the settings & configuration elements to be global across all of the web applications.
you can use Memory Cache, MemoryCache class has been changed to make it usable by .NET Framework applications that are not ASP.NET applications.
Background
I have a windows console app written in C# which needs UI. I started using WPF, but as I come from a web background, I want to use html, and some features of html5, including web sockets for real time communication with another application.
Initially, I'll use a web browser as the UI, though I may later host a web browser in the main app. This bit doesn't concern me at the moment.
After a lot of googling/reading, I'm going round in circles. It looks like WCF can be used to serve html, json based web services, and possibly web socket streams.
A lot of googled info relates to pre .NET 4.0 community projects. Even post 4.0 there are several NuGet packages which seem to me to overlap what is already in the framework. To a WCF noob, it's all a minefield.
So, what areas of .NET 4.0 WCF and the various open source projects should I be concentrating my efforts on.
Requirements
I require a lightweight self hosted web server. It cannot be IIS based, as users will not have it installed. The server (or servers) must:
Be able to server complete web pages, including html, linked images, css and js files. C# MiniHttpd does the job well, but is not based on http.sys. HttpListener seems to be the core of what I want, but I haven't found a complete web server project based on it.
[optionally] Be able to parse those pages through asp.net or razor
Be able to respond to web service call via json. This bit I have a working example using System.ServiceModel. Is this the right way to go?
Be able to work with the emerging Web Sockets standard. SuperWebSocket is actively developed, but doesn't appear to be http.sys or wcf based.
Preferences
I would prefer to stick to one basic stack for all 3 of my main requirements - and I suspect WCF may be that platform.
I would prefer an http.sys based approach for all three requirements, so I can reserve the relevant url/port/namespace combinations and prevent conflicts with other web servers or services
Although other SO questions may help with individual aspects of my requirements, I need advice on a more holistic approach.
Ok, answering my own question feels wrong, but...
I have since found a great CodeProject article that provides an easy to use self hosted web server for serving the html, css, js and images, and serves the json requests.
Developing Web 2.0 User Interface for Self Hosted WCF Services using HTML5, CSS3 and JQuery
I still have to settle on a WebSockets solution, but the above project is as close to what I need as is possible at the moment. It doesn't support rendering asp.net or razor, but these were my lowest priorities, as I'm happy to use only pure html and javascript for the front end.
I'll try to post more specific questions in the future :)
Except for your WebSocket support requirement, the OpenRasta framework currently supports what you describe. It definitely can run in http.sys and can be used for both creating REST services and as a web app platform. It also supports Razor and other view engines. The link page has a good comparison chart toward the middle that compares it with ASP.NET MVC & WCF.
In March 2014, a solution which fits my original requirements is ASP.NET Web Api. It can be self hosted, and can apparently be set up to serve html etc as well.
Is it possible to serve a web page from a self hosted web API in a windows service?
I wish to build a Windows application that will generally run in the background, but have a configurable front-end Windows Forms GUI. I also would like this program to publish a small web page which can be accessed from other machines/devices and interact or call functions of the server application.
I'd rather not deploy a full-fledged ASP.NET web site with IIS, etc. I just need something simple.
So how would I go about doing this?
Take a look at Kayak. It's a relatively small and lightweight HTTP server that you can embed into your application and should provide all the functionality you're looking for.
FWIW, I am in no way associated with this project.
Maybe it's just because i've been doing asp dev for years, but I really think you should go the iis asp route as its very simple and built into windows. I can't imagine a more straightforward way of serving a webpage that has c# behind it to programmatically effect the host system.
Thanks to Kev in the comments on my question, he pointed me to this question, in which I found a link to a lightweight C# HTTP server component I could just drop in to my application: http://webserver.codeplex.com/
Works well for little stuff like I was doing.