I want to try moving to VNext from Asp.Net MVC 3, I used windows service project (http://www.interworks.com/blogs/banderton/2009/10/30/long-running-tasks-aspnet) but this doesn't seem to work on VNext, because it doesn't have proper System.ServiceModel reference and I cant add dll.
Is there a way around? Would you recommend other ways to run long tasks such as big file import/calculations with VNext?
Generally, no - not because of any feature-set in ASP.NET vNext (it's been possible since .NET 1.0) but because of permissions: a process needs to run under a high-privilege security context or be able to impersonate such a user account in order to control Windows Services.
w3wp.exe (the application pool hosting process, and by extension, the application pool and the applications within it) all typically run under a least-privilege user-account (often NT AUTHORITY\NETWORK SERVICE or a custom user account with enough permissions to write to the website's root directory, a database server, and not much else (in recent versions of Windows this is further reduced to the concept of a "service account" which your worker-process and pools run under).
The easiest solution is to create a user-account with the necessary privileges to control services and run your application pool process under this user-account, but I don't recommend this.
Consider, instead, creating a new Windows Service that then controls the other service (or if it's your own service, do it in-proc) that uses some form of IPC to communicate with your ASP.NET application to shut itself down and perform other tasks. You might want to look at named-pipes, for example.
If you need to run ASP.NET in a Windows service, you can do it now using ASP.NET 5. I wrote a detailed post on how to do this here: http://taskmatics.com/blog/host-asp-net-in-a-windows-service/
Related
I am not clear that what is the purpose of running asp.net application in IIS. Why we go for IIS. Any difference amoung running in VS and IIS?
Please suggest me.
Simply because you won't run asp.net in VS on production !
IIS Express and the VS Development Server are designed to emulate IIS, but they are configured differently and may fail to reveal errors that can occur when you deploy to a production version of IIS.
Visual Studio Development Server, also known as Cassini, is very limited. It does not have all IIS features and we will have a few problems when resolving References to Root-Level Resources or on security.
For example, when you run a page using IIS Express/VS Development Server, the page runs in the context of your current user account (often Admin). In IIS 7, by default ASP.NET runs in an account that has limited privileges (know as AppPool Identity, see here). This difference can be a source of problems when you deploy on production a web application.
A complete list of Hosting options is available here.
Internet Information Services (IIS) for Windows® Server is a flexible, secure and manageable Web server for hosting anything on the Web. From media streaming to web applications, IIS's scalable and open architecture is ready to handle the most demanding tasks.
Application pools allow you to isolate your applications from one another, even if they are running on the same server. This way, if there is an error in one app, it won't take down other applications.
Additionally, applications pools allow you to seperate different apps which require different levels of security.
Here's a good resource: http://www.advancedinstaller.com/user-guide/tutorial-iis.html
http://www.iis.net/learn
I have to debug a WCF hosted in local IIS. Each time I have to attach two processes "w3wp.exe".
One ID is 7624, the other is 8372.
Users: one is "IIS APPPOOL\ASP.NET V4.0 Integrated[administrator]
the other one is "IIS APOOL DefaultAppPool[administrator]
Questions:
What they are? (google search but bo clue)
Can I just attach one process rather all?
Thanks
Updated:
See IIS image:
Just check in your IIS Management Console the Application Pool in which your site resides, then attach to the proper one. Probably, as you're using WCF, you're running under .NET 4, so under the first process you linked.
Application pool is the set of apps that run under same worker process.
Important thing in practice is that one app pool can serve only applications with same version of .NET (version of .NET CLR - to be precise). It is also good to remember that applications from the same app pool will "share" recycling of worker process.
So, you should look up at the IIS in which app pool your service is running and debug only process associated with this app pool.
They are Application Pool Identities. This is the newer (and securer) way of assigning priveleges to websites. Essentially a site runs on its own application pool, so you assign rights to files based on that pool.
See: http://www.iis.net/learn/manage/configuring-security/application-pool-identities
How is it possible to deploy MVC3 web roles to windows Azure? Most of the tutorials seems done on deploying ASP.NET web roles than the MVC3 one.
can any one give me a link/hint?
Way back in the old days, MVC3 wasn't supported out-of-the-box because the appropriate DLLs needed to be manually added by you (or installed as a startup task). These days, the MVC dll's are all there using the MVC3 template, so there's no difference in what you'd need to do, between asp.net and asp.net mvc deployment. The basic Web Roles and Worker roles are just Windows 2008 Server VMs, and the deployment process is the same. The most important part, when starting out, is making sure your connection strings to storage point to "real" storage and not dev storage (such as your diagnostics connection string). Also, session state defaults to using SQLExpress, which isn't running in Windows Azure, so you'll need to either use a SQL Azure database (plus proper connection string) in web.config, or change session state to use Cache (again, a web.config change).
Usually I would look at writing a Windows Service to manage tasks that aren't suited to being hosted in a web application. These types of tasks are usually long running processes or scheduled tasks. Although this is normally the primary approach for these types of tasks, people have looked at ways of running these kinds of background processes in a web application by kicking off a number of threads in the Application_Start event exposed by Global.asax. The problem with this approach has always been that if your IIS worker process dies, then your background thread is killed too (effectively your 'Windows Service' is stopped until the next request is received).
ASP .NET 4.0 offers a solution to this problem. You can now set the StartMode to 'AlwaysRunning' as described in this blog post by Scott Gu. Somewhere in the comments on this post, someone asks a question about the viability of hosting Windows Service type tasks in IIS since the new feature ensures the worker process is always running. Scott mentioned that it would definitely support the scenario. Further to this, the recent introduction of AppFabric means that Microsoft themselves are providing simple hooks for hosting and monitoring WCF and WF services in a web application.
What does this mean for those of us that used to write Windows Services to support our web apps? Should we adopt this model? What are the pitfalls? As far as I can tell, there are a number of benefits to hosting 'Windows Service' processes in a web application, the most useful being the ease of deployment. Furthermore, we can actually start developing simple user interfaces to our services which provide information about what is happening at runtime.
If I had to go this route, I don't think that I would host my 'Windows Service' type functionality in the customer facing web application. I would probably develop a new web application project (much like I would in the Windows Service context) that would host my long running/scheduled task processes. I guess there are few reasons for this.
Security. There may be a different security model for the UI displaying information about the running background processes. I would not want to expose this UI to anyone else but the ops team. Also, the web application may run as a different user which has an elevated set of permissions.
Maintenance. It would be great to be able to deploy changes to the application hosting the background processes without impacting on user's using the front end website.
Performance. Having the application separated from the main site processing user requests means that background threads will not diminish IIS's capability to handle the incoming request queue. Furthermore, the application processing the background tasks could be deployed to a separate server if required.
I would be really interested to hear your thoughts on this approach and whether I should be sticking with Windows Services. I am very tempted to try this new approach.
What does this mean for those of us that used to write Windows Services to support our web apps?
I think this a key scenario where you could be move away from a Windows service to using the continous running web site.
Should we adopt this model?
Standard development answer: Depends ;)
What are the pitfalls?
One issue I can see is the IIS dependency. If you need a service to run on a users machine I would not feel comfortable about asking them to install IIS just to run my service. Here I think the traditional model works better.
Monitoring and tracking are major issues, but as you also point out this is solved by AppFabric. It is even better than what you get from the Window Service. However you have added another dependency which also will require .NET 4.0 and a relatively new version of Windows. I could also be wrong here, but my understanding is that AppFabric is not supported in production on client OS's. Which could bring in additional headaches.
You will lose pause functionality in the continuous web site model too.
Finally IIS killing inactive app-pools isn't the only way an app pool can recycle. Editing a web.config file causes it for instance, which may not be an ideal situation.
the most useful being the ease of deployment.
I also think development is much easier - in the past I have had a console app and a windows service so I can dev/test on my machine using the console app and then change it to a windows service when it goes out. Now dev/test is MUCH easier.
A must read for this is Death to Windows Services...Long Live AppFabric!
What are the pitfalls?
One I found, no shutdown event. You have AppStart when the web site starts (not global.asax because that is HTTP only) but you have no way to handle shutdown which could mean disposing becomes an issue.
I would suggest sticking with a windows service. The issue is with your number 2.
You won't be able to update service part of web site without restarting whole web site.
I have a web application that executes IIS 7 provisions (using Microsoft.Web.Administration.dll) to create our web and ftp sites. When I run this using the administrator account, it works ok.
I want to create a Windows user account for impersonation that will only execute these web provisioning procedures without being identical to a server's administrator roles.
How can I achieve this?
You should split your application into three parts:
Windows Service
This would host a WCF or Remoting application. You want to put the code that requires privileged access to your system in here. For example creating and deleting websites. Run this service under an account that has enough rights to perform operations using Microsoft.Web.Administration.
Trusted Wrapper or Proxy Assembly
This is just a signed wrapper assembly that is installed in the GAC. Its role is to pass on calls from your low trust web application to perform privileged actions in the code running in the service above. Mark the assembly with the AllowPartiallyTrustedCallers attribute (if your server is configured for partial trust) and mark any classes that require access to the remoting service with [PermissionSet(SecurityAction.Assert, Unrestricted=true)].
Front End Application(or Web Service)
This is the interface to your application (whether it be a web application with a GUI or a web service). Run this in its own application pool with just enough rights to execute, for example IUSR or a similar account. Ideally you should also run this under partial trust.
Your web application/service references the Trusted Wrapper assembly in the GAC which in turn has a reference to the remoting or WCF application running in the windows service.
Using this layered approach means that you are locking down by gating access to specific privileged operations which only run in your windows service.
This approach is covered quite well in Appendix C of Dominick Baier's 'Developing More-Secure Microsoft ASP.NET 2.0 Applications'. I thoroughly recommend getting a copy.