I have an ASP.NET website which is running currently on IIS. Now I want to move that site to run on Cassini.
What are the advantages of Cassini over IIS? What are its disadvantages?
What are your experiences using Cassini as a production web-server?
As far as I know, you cannot use Cassini in production because it listens for localhost requests only. You will have to modify source code and recompile the webserver by yourself.
Another thing is that IIS is built on top of http.sys kernel-level library for maximum performance. I'm not familiar with the latest Cassini versions but last time I checked, it used slower managed TCP sockets.
If your website is not very popular and Cassini has all the features you need, why not... there is nothing wrong with Cassini. It's simple webserver but it's not the only alternative to IIS.
There is Abyss, UltiDev Cassini and I think a few other open-source servers with ASP.NET support.
UltiDev Web Server Pro is a free, redistributable, light-weight web server with lots of enterprise-level feature for ASP.NET applications (from ASP.NET 1.1 to 4). Unlike Cassini, its design has nothing precluding it from serving Internet-facing applications. Created by UltiDev, the vendor of UltiDev Cassini fork, new UWS Pro is functionally closer to IIS than to Cassini. More screenshots.
.
Easy choice: it's simply not possible to use Cassini in production, because it's not accessible from remote machines (it only listens on localhost).
I would say you are better off, going with something proven to handle scaling, like mod_mono on apache if you are looking for alternative servers.
The integrated pipeline, routing, compression and caching features of iis are hard to replicate. But the app pool and failure rapid response stuff is hard to do without knowledge of the OS and the network stack at a root level.
Cassini doesn't claim to be multi threaded or handle any of the advanced e-tags or other header control issues that can be issues with iis, but are also usually set at sensible defaults in later versions of iis.
For the sake of completeness, you could do the older rails-mongrels model, spin up say 10 cassini's on ports 10100 - 10110, then use ngenx or apache to load ballance requests on those threads, and using a monitoring tool to redo requests to new threads when old ones go out to lunch and constantly be restarting 2 or so ports, because you get overloaded.
There is a good comparison of Cassini and IIS here at StackOverflow
There is no possible angle you can look at cassini or any of it's derivatives and consider using it as anything other than a development/testing server.
Related
We have a desktop client application and recent customer requests indicate that they would like to have some dynamic HTML content served and displayed by the application.
We are considering hosting a simple ASP.NET application in a local process, accessible only from the local machine (similar to the ASP.NET development web server used when debugging from Visual Studio).
How can we run an ASP.NET application locally without IIS? IIS is not an option because most client machines will not have it installed.
Is there a leightweight ASP.NET web server that could run locally similar to the development web server that VS is using?
I have found some information about "Cassini". Is this suitable for production use? Can it handle ASP.NET MVC? Are there any alternatives we should consider?
I have not used it myself, but you can try the mono XPS server.
It is a stand alone webserver.
The easiest way to start XSP is to run it from within the root directory of your application. It will serve requests on port 8080. Place additional assemblies in the bin directory.
Cassini is in fact also a good option - it is the development web server that comes with visual studio (so widely distributed, used and tested) and is also used by the open source ScrewTurnWiki. See wikipedia.
In regards to your "only locally" requirement - a web server will serve any request made to the right port. In order to limit accessibility, you should use a firewall that will block any external requests.
You might consider using WCF to host a service on the local machine that can serve the data without having to host a full blown web server.
If you do this, WCF allows you to expose the service with multiple endpoints and make it available through HTTP, TCP, or Namepipes. Namepipes would restrict traffic to only the local machine.
I have also tried IIS Express. It works great with ASP.NET MVC. Right now it is available only with Web Matrix, but installing web matrix is easy.
Coming back to this question three years later, ServiceStack.NET with self-hosted option seems like a good choice. While it is not ASP.NET MVC directly, it provides a good API and features are on par with ASP.NET MVC/WebAPI (or in some ways better).
A quick ASP.Net performance question...
I have an ASP.Net 3.5 SP1 Application that I want to run on IIS 6. For SSL certificate reasons I need to run it on separate sites in IIS. It's a CMS, and some clients will need the add their own SSL certs.
1) Can I run the same set of ASP.Net files on the disk on multiple sites in IIS or do I need to mirror them?
2) What considerations do I need to make in terms of performance, e.g. having multiple database connections from each site?? Or will they be 'pooled'?! Also, I am using Linq to SQL and am caching the results using ASP.Net's cache. Will it be an overhead to have separate caches for each IIS site of essentially the same data? Are there any other performance or application design considerations for this scenario?
3) Does running the IIS sites under the same App Pool make any difference?
Or does anyone have a totally different recommendations?
Any guidance you can give would be much appreciated. I'm looking for as many varied opinions and experiences as possible here, so please do add an answer if you can help.
Cheers,
Tim
Maintenance will be WAY easier if you only have one IIS site to manage. A more efficient way would be to deal with the SSL issue somewhere else (eg, hardware load balancer, content switch, Apache box, etc) and reverse-proxy to a single IIS instance with a single version of the app running. Sharing the app pools won't help (assuming you're using SQL Server with the managed client anyway), because each web app gets its own Appdomain and hence its own connection pool. Sharing app pools causes them to share a process, but not an appdomain.
I've done this on the cheap before by having Apache installed on the same machine as IIS, listening only on port 443 (for however many IP/cert combos were needed), then have Apache set up as a reverse proxy to IIS on the same machine listening only on port 80 (but for any host header).
I agree it does not make sense to run different web sites for the same applicaiton.
You can set SSL port in the web site with IIS manager. If you do not set IIS to require certificates, some users can use the HTTP version without the certificate error and the others can use SSL.
We do ASP.NET Development using Visual Studio.
A discussion point we've just had is whether or not our developers should have IIS installed.
With the ASP.NET Development Server you can run your web apps without IIS. Once you're happy with everything you can then deploy it to a test server running IIS and then onto Live.
In my opinion, all developers should also have IIS installed on their own machines as that will eventually be the end platform for the application.
The arguments are basically if the developer should have as close to "live" an environment as possible, or if the developer should only have the tools they require and not be cluttered with other things.
None of this is missions critical and I'm sure everyone will have a differing opinion. I'm just interested to hear some of them!
Robin
I'm going to say unequivocally yes. IIS and Cassini are not the same and not exposing your code to production conditions can cause you problems. Better to get yourself in the habit as early as possible.
(obviously you can replace "IIS" with "Apache" or whatever your webserver tech is)
I would say that you don't need to have IIS installed, but that you should test on IIS at some point.
The Development Web Server has two "issues":
it only works for local requests
ALL requests are passed through ASP.net
Especially the second point can really open ways to shoot you in the foot. "Why can people access SuperSecretPicture.jpg? I have a Handler in my Web.config that blocks that!".
But if you know about those limitations, then I find that the Development Web Server is better to start with since you can first focus on your code and then about your environment, but YMMV.
The bottom line is if your application is served by IIS, you should be testing on IIS. If that means IIS on your local machine or a dev server is up to you.
What harm can it do having it installed? At least if you have it installed you can choose to use it or not. The day you need to debug a webservice call from an externally hosted application you don't want to be messing around installing it.
Depends - are you running server versions of windows for you dev boxes?
Because, e.g. the XP version of IIS is different from 2000/2003 server, so you'll get a different experience. Similarly, if you develop on Vista but plan to deploy on 2003, it won't be a "complete" experience.
We have IIS installed on our local machines at our work for development purposes. We need to test the web applications against IIS, but neither do we want to release it to our live server, or to our test server as that requires a lot of work. Instead, we just host it locally and everytime we modify a file through Visual Studio we can then instantly see the changes without having to go through a file copying process.
I don't think it's a bad thing at all, as long as everything's secure you'll be fine.
Ideally your test server should mirror your production server. That should go without saying. In my opinion, your dev environment should come as close as possible, while fulfilling your needs first (I prefer to keep the dev environment as self-sustaining as possible, in case I am disconnected from the network).
I have no problem using the dev server for development, and IIS (locally or remote, as the case may be) for testing - but it depends on the project requirements too. I prefer to host web services on the local IIS server, for example. YMMV.
We develop on laptops using virtual machines. This way, if the virtual OS crashes (or the host OS, for that matter) you just copy your vpc back over from the network (where we have backups) and you are good to go. also, it makes it WAY easier to run a "standard" development platform wich is as close to production as possible.
For us, we HAVE to have IIS installed, as we are developing Sharepoint '07 webparts.
I've found that on some occasions I can edit the source while debugging. Are there any other advantages of using the Visual Studio built-in webserver instead of a virtual directory in IIS?
I'm using Windows XP on my development environment, and a local instance of IIS 5. I work on several projects, so I use multiple virtual directories to manage all the different sites.
Are there any disadvantages?
The built-in web server for Visual Studio is called Cassini and here are a few of its limitations...
It can host only one ASP.NET
application per port.
It does not support HTTPS.
It does not support authentication.
It responds only to localhost
requests.
It is slow startup compared to IIS
All the previous responses are great answers - here's one gottcha with Cassini that might require IIS on the destkop.
Cassini runs in the context of the developer, not as the IIS user (IUSR_, IWAM, or in WinXP x64, the w3wp process). This can be a bit painful if you've got a web site that is accessing external files or creating temp files. It is most evident when your developer is running as an Admin of their desktop.
When you move to the server IIS, something that you would have had access to in Cassini doesn't work the same. CACLing with the IIS_WPG usually is all it takes to fix, but if your developer is not thinking about this, they will quickly get quite frustrated with their deploy.
Cassini does not support virtual directories.
It looks like a third option is coming soon:
IIS Express.
Another disadvantage I've run into is on a Forms authenticated website using custom IPrincipal/IIdentity. Cassini will switch the AppDomains without warning (or notice).
Check this blog post for more.The headache on this made me drop Cassini and stick with IIS.
The Visual Studio web server is less forgiving about // in the path.
It will refuse to serve a link like
http://localhost:52632/main//images/logo.jpg where IIS will do.
That's pretty obscure, but it means we have a lot of fixing to do to get rid of all the // occurrences.
The built-in server works well for larger corporations that don't want to give developers any administrator access on their own machines to configure IIS.
There's a bug in the way the built-in server handles HTTPModules - there is a workaround, but I hate having to put in code that'll never be needed in production.
You need to have Visual Studio running to use it (under normal circumstances)
It only responds to localhost, so you can't give the link http://simon-laptop:37473/app1 to a friend to view your site over the network
Big disadvantage: it's harder to get fiddler working, because localhost traffic isn't sent through the proxy.
Using http://ipv4.fiddler:37473 is the best way to get Fiddler working with it.
You cant use virtual directories :(
Cassini also does not support ASP Classic pages. This is only an issue for legacy projects where old ASP Classic pages still exist (like our web application at work).
The built-in server means the developer doesn't have to know how to set up IIS to test their site.
You could argue this is a disadvantage, and that a Windows developer should know at least that much IIS. Or you could argue that a developer who isn't a system administrator shouldn't be messing around with the web server at all.
If you 'web reference' the URL for web services that are on the built-in webserver, the port might change. Unless you have set a "Specific port" mentioned in menu Project → Properties options page.
This is something I've gotten used to now. I always set a specific port. Now when sometimes the webserver crashes (I've had that happen), I simply change the port number, and all is well. I reckon restarting will also fix this.
If you do hobby work at home using XP Home, you can't install IIS locally.
When you use IIS in Vista or Windows 7 with UAC enabled, you must run Visual Studio with administrative rights. If you do this, you can't drag an drop from your shell to Visual Studio (even if you run an instance of explorer.exe as administrator).
For this reason I use Cassini for most projects.
FYI, Windows XP 64-bit comes with IIS 6.
This is an old thread started 2 years ago. I just stumbled upon UtilDev Cassini while googling. Looks promising to me. At least it has the ability to run multiple sites simultaneously. That feature is really useful for me, because I work on 2 different sites and have to continuously switch between them using IIS.
Here's a reason for a third way: although UWS Pro is probably closer to IIS than Cassini (although inspired by Cassini and is from the vendor of the UltiDev Cassini fork), its main purpose is to be redistributable along with ASP.NET applications.
Cassini is meant to be a lightweight test webserver. The idea is that a developer does not need to have IIS installed and configured to test his/her application.
Use IIS if you are familiar with it and you have it set up and your box can handle it. Cassini is not meant to be a replacement.
I often take the best of both worlds and create an application in IIS, and use the built-in web server for more efficient debugging.
The built-in server isn't as configurable, and it runs on an odd port, so if you're counting on specific behavior it can be troublesome.
Install IISAdmin, and you can setup separate sites in IIS 5, instead of using virtual directories.
The built-in webserver is a little less robust than IIS, but requires no setup so it is just a tradeoff.
You may not always want your development projects exposed on your IIS server (even your local IIS server) so the built-in server is good for that.
However, if your application is going to access resources outside of the norm for a web app then you may want to debug frequently in IIS so that your app will run with restricted permissions and you can see where the pain points will be.
One difference I've found is that the development server handles uploading files differently than IIS does. You can't trap the error if the file being uploaded is bigger than your Max_File_Size setting. The page just dies and returns a 500.
Another dis-advantage is that it sends every request through the gloabal asax file which includes all requests for images and stylesheets. This means if you have code in there which does things with the file names, such as a look up, then the auxillary files willget processed too.
Also via IIS, you don't have to worry about automatically remembering and setting a stupid port number in your localhost url. That's something funky directly relied upon with Cassini...big pain in the ass. Who wants to remember some abritrary port number. Just run the damn site in IIS..plain and simple.
We've also seen some issues with Visual Studio built-in server regarding some third-party controls which put their scripts in the \aspnet_client folder.
Since the folder isn't there when you're not running under IIS, the controls didn't work. It seems a lot simpler to always work with IIS and avoid strange problems.
If your project resides in the IIS directory you can still edit code. It just depends if it has been published or not.
You will run into so many issues on the Cassini vs. IIS when you are debugging certain permission based scenarios, like Kerberos and NTLM authentication as well as issues like server compression, etc. All in all, the Cassini is still okay to develop with, but make sure you do extensive testing when publishing to IIS.
Currently our dev team set up all the websites they're working on in IIS on their local machine. We're thinking of switching to using the built in ASP.NET development server instead.
Is this a good idea? What are the pros / cons of using the ASP.NET dev Server? Are there any gotchas we should be aware of?
Thanks.
NB: Running on Win XP / IIS 5 / VS2005
Edit:
Didn't realise it was called Cassini.. More answers for Cassini v IIS here.
There is nothing that the ASP.NET Dev WebService can do that IIS can't (You can set breakpoints etc, just attach the VS debugger to the ASP.NET runtime).
However, the ASP.NET Dev WebService does not represent a true production environment, and as such you can get caught by gotchas that you wouldn't expect when you deploy to production.
Because of that, I mandate that all development is done using IIS on a local machine. It doesn't take much work to configure a site in IIS.
It's a very good idea. Here are some reasons for:
You no longer need admin access to your machine for web development (it can still be helpful).
It's much easier to test a quick change and continue work, and faster iteration cycles are good.
It can simplify setup and deployment of your development environments.
The XP version of IIS has limitation that are not present in the Server version that Cassini side-steps.
The only argument I know against is that there are a couple very rare edge cases where the Cassini built-in server doesn't exactly mimic IIS because you're using odd port numbers. I doubt you'll ever run into them, and using Cassini as the primary dev environment does not preclude developers from also having access to IIS on the machine. In fact, my preferred setup is Cassini first for most small work, then deploy to my local IIS for more in-depth testing before moving code back to the shared source repository.
[Edit]
Forgot about url re-writing. You do need IIS for that. And an example of a limitation of the built-in XP IIS is that you are limited to one site in XP (can have multiple applications, but that's a different thing).
I had to switch (back) to IIS for one project, because I needed to set some virtual directories which is not possible on the ASP.NET Development Web Server.
As I stated here: https://stackoverflow.com/questions/103785/what-are-the-disadvantages-of-using-cassini-instead-of-iis your developers need to be aware that Cassini runs as the local user, which is typically an admin account for developers. The development will be able to access any file or resource that their account can, which is quite different from what they will see on an IIS 6 server.
The other thing that's a pretty big gotcha is debugging web services is much easier using IIS and vdirs rather than separate Cassini instances.
I know at one point I had an issue with Authentication not working as expected on Cassini (built in development server)
Also, if you need to test things like ISAPI plugins (a re-writer for example) I'm not sure how that's done on Cassini.
The constantly changing port is also rather disconcerting to me. Also, for each web project in your solution it fires up another instance of a Casini server, and each one takes anywhere from 20 to 50 MB of memory.
I use IIS all the time, it's pretty easy to setup, and you guys are already doing that...
I've used both methods and I prefer having IIS locally vs. using the built-in server. At very least you're more consistent with the final deployment setup.
Also, when using IIS 5.1, be sure to get JetStat IIS Admin, it adds functionality that is disabled out of the box on IIS 5, such as being able to setup multiple sites.
I have run into the following limitations with the asp.net dev server:
does not support virtual dirs. If you need them in your app, IIS seems to be your only choice
Classic asp pages dont run in dev server. So if you have a mixed web app (like I have at my client right now), IIS seems to be the solution
If you need an admin UI to configure settings, IIS works better
Of course IIS requires that you be a local admin.
Another distinction I noticed is that Cassini runs as a 32-bit process and you have no control over it, whereas you can control the application pool of your IIS app to disallow 32-bit (assuming your IIS is running on a 64-bit server). This becomes especially important if your web application is going to call APIs in 64-bit processes such as SharePoint Foundation/Server 2010. When you debug your web app with Cassini as your debug server, you'll get "The Web application at url could not be found. Verify that you have typed the URL correctly" type errors when instantiating objects. If you debug using IIS with the app running in an app pool that runs as 64-bit with an identity that allows access to sharepoint database then you'll be able to debug properly.
In VS12 the development server is way slow, takes a few seconds to download a 2kbyte file. This did not happen in vs10. When you have a bunch of jquery files and css this is a real problem. Also every page requeries all the css/js files. Very very slow regression testing.
The main issue I've run into with the dev server is SerializationExceptions with custom security principals stored on the thread context. Details here.