I have made some edits in my aspx code behind cs file. I can't make the site down since our site will miss our viewers.I want to make the update possible with this single page upload.
You are searching for strategies of seamless deployment for IIS asp.net apps; this can be achieved via two machines and a load-balancer before them - Seamless deployment in ASP.NET (IIS kills worker process before new worker process is ready)
Another convoluted way is to host two identical websites on the same host and switch between them, as explained - Is smooth deployment possible with componentized ASP.NET MVC apps?
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 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.
I have web application that are using multiple clients.
I should create one copy of application for all clients or every client should have its own copy.
I am using Asp.net MVC and SQLServer.
What you suggest.
Creating seperate projects per client will be troublesome to maintain while a single project for all clients could be difficult to customize. It is a fine line and your needs will dictate how you build your solution.
One of my more recent projects where we do SAS (Software as a Service) we were able to build our MVC application using a plugin architecture so that each client COULD have their own DLL deployed to the BIN that would enable customizations for just that client (to the Views, Assets or even the Controllers). We are able to leverage a single code base and have many clients, most without customizations and some with minor to heavy customizations.
Every client has a unique URL for their "portal" and most often they have private domains, so http://app.mycompany.com or http://mycompanyapp.com and some are even hosted on our own site, http://hostingcompany.com/client/.
By building an application that can determine what client it is based on the URL we were able to handle all of these cases with ease. When we deploy we have a single code base (deployed just ONCE to a single folder) and all of the sites use that same code deployment.
We run a web farm where we have many .NET Web Servers and have load balancing setup and the sites all have ping pages that our load balancers interact with to determine their health.
Like I said, your needs will determine what the best solution for you is.
Nick , what about database should we use one database every client or should have separate database for each client in my scenario our application is more database centric so there are lot of changes done for each client as per there business roles .
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.
Is it possible to develop a web-app in ASP.NET (framework is not a constraint), to have a sandbox architecture, and deploy widgets without disturbing the parent application?
I expect both the parent application and the widget to be developed using .NET.
EDIT:
To elaborate, I want to have an web-app, say App1, and widgets (say wid1 and wid2). wid1 and wid2 should be like a plugin into App1, only difference is that, if I make any changes to wid1, I want to be able to deploy it without disturbing App1 or Wid2.
The widgets can be something similar to a flash object, only that it needs to be developed on .net.
Would something like the Managed Extensibility Framework be what you are looking for? They even have a WebForms sample:- http://mef.codeplex.com/releases/view/44166
I believe you will want to look into Application Pools.
In a web server running IIS with ASP.NET websites, you can create Application Pools which will contain your applications (web sites). You can restrict pools to limit resources usage like RAM, CPU, # of threads, etc. If one of the websites go crazy, it should only affect it's own Application Pool. You can put more than one website in a single Application Pool so if you put all of the websites in one Application Pool, then they will all crash together.