I've just run into one of the problems of using the integrated dev server (Cassini) in VS and would like to see if there are any solutions.
We're using asp.net authentication to secure the site. However, Cassini runs in integrated pipeline mode, meaning that requests for all files go through the asp.net isapi. The result of this is that it's securing files that would otherwise not be secured in a production environment (.htm .js .css etc..).
Now I understand that we can run the project on a local IIS instance, but we would like to avoid this if possible. But, because of the problem above, this is looking like the only solution.
Does anybody have any ideas about how to get Cassini working with authentication that can be easily moved to a production environment when ready. (I'd also like to avoid having a different development web.config that specifically allows access to these files).
We're using VS2010 by the way.
Many thanks.
Instead of using Cassini, you can download and install IIS Express:
IIS Express is a lightweight, self-contained version of IIS optimized for developers. IIS Express makes it easy to use the most current version of IIS to develop and test websites. It has all the core capabilities of IIS 7 as well as additional features designed to ease website development
You can wire up to the HttpApplication.PostAuthenticateRequest event in your global.asax or an IHttpModule. PostAuthenticateRequest event on MSDN
In the event handler, check the file extension for the one that you want to be unsecured. If the file extension is a match then give set the HttpContext.User to an IPrincipal instance that has the roles required for accessing a file in the specified directory.
Related
Can anyone please tell me the difference between IIS Server and Development server provided by Visual Studio.
Here is a few links to read up on :-)
Core Differences Between IIS and the ASP.NET Development Server
ASP.NET Development Server or Localhost IIS?
What are the (dis)advantages of using Cassini instead of IIS?
I don't know why your looking into this but you might want to take a look at IIS Express - Introducing IIS Express
There are MANY differences, some of them:
Local access in Cassini
Cassini does not support S
Cassini runs as your account (whoever is logged on), IIS runs as a service which means some things change quite a bit
Does not support authentication methods like Basic, Digest, etc.
Does not run any of the IIS Modules, which means you will not be able to do things like URL Rewrite, Default Documents, Directory Browsing, Custom Errors for static pages, etc
Does not support things like Virtual Directories, etc.
What I would recommend for anyone wanting something as simple as Cassini, yet more compatible is to use IIS Express which supports almost all features from IIS yet with a much simplified model suited for development http://weblogs.asp.net/scottgu/archive/2010/06/28/introducing-iis-express.aspx. Visual Studio will include support for it.
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).
I'm developing a web site in a high-security environment. For example, we use CAC cards to authenticate users over SSL.
The site is a mix of VB.NET and C# on .NET 3.5 with some AJAX. The AJAX parts are now calling web services for things like Cascading Drop Down Lists.
We've been running VS2008 configured on our local PCs to use IIS instead of the default server (Cassini). However, some security policies were rolled out to the desktops over the weekend and, suddenly, we're not allowed to run IIS on our PCs anymore.
I already have some of our IT people trying to appeal for waivers for developers. In the meantime, I need to find a way to keep developing.
If I turn off the SSL requirement to the 'secure' part of the application (locally, my PC only) I can serve up some of the pages (using Cassini) when I hit "F5", but pages with web services just bring up "server application unavailable".
I need to be able to add some more functions into the existing web services, among other things, so the ability to single-step through the code is still a necessity.
I'm sure someone who is limited to using Cassini has found a way to Build/Debug pages in VS2008 when webservices are involved.
Thanks in advance.
EDIT: As it turns out, some links had "HTTPS://" hard-coded in them (I inherited these). Changing the link to "~\folder\page.aspx" allowed Cassini to properly serve things up.
Note that using Cassini is the default for VS2k8, even for Web Services. Try starting a new HelloWorld web service project and confirm if you can debug it.
OK So that worked. Then change the debugging options of your real project back to using Cassini rather than IIS. I wouldn't move the project (although backing it up might not be a bad idea) as you might be able to get IIS working again.
EDIT: So your actual problem wasn't to do with web services, just hard-coded URLs. (We have similar problem where much of the site works where ever the root of the website is, but some places, such as "main menu" links, expect the root to be the root of the webserver.)
You proabbly need to contact your IT department and have them open up something on the network so you can call the services - a port on a firewall, for instance.
Hi guys,
We have a mixed development environment of three servers running: Win Server 2003 & 2008, IIS 7 & IIS 6, ASP.NET 2.0 & ASP.NET 3.5. Previously, all three servers were Server 03/IIS6/ASP.NET 2.0, but with this new change, I am finding that pushing/moving any applications from server to server is always a terrifying experience because there are always a variety of problems with the web.config from server to server. I used to consider myself a confident ASP.NET developer but now I am frightened to come to work every day.
I have always used the web.configs that VS generates for me on the Win 2003/ ASP.NET 2.0 server. None of our web.configs are "leet", they are just normal, although we do use ScriptManager and UpdatePanel.
To get by, as a temporary fix, I'm having to remember that when projects are moved/tested/deployed, never to move or overwrite any web.configs and things get confusing very fast. I've tried "ducttaping" like suggested here my web.configs with the new IIS7 stuff but even that doesn't work all the time.
What can I do here, what's going on? Is there a standard web.config that will work on all of the servers and do the UpdatePanel and ScriptManager ?
[edited question]
Since IIS6 is the baseline install for your application, you should make sure to run the application in "Classic" mode under IIS7. This makes configuration the same as an IIS6 box. This is how we run our web applications for now until we have fully migrated to 100% IIS7 server environments and we have zero problems with deployment/runtime.
To do this you can either choose to run your app under the built in "Classic .NET AppPool" that comes with IIS7 or, assuming you create your own custom application pools, just make sure you set the "Managed Pipeline Mode" to "Classic" under the "Advanced Settings" dialog for the app pool.
You should seriously look at web deployment projects for visual studio 2008.
This is an official add-on for Visual Studio that gives you a new project type called web deployment project. Among the most useful features is the ability to do web.config search/replace as well as pre-compiled builds of your web sites or web application projects.
In your case, what you'd do is create a solution configuration in visual studio for all of your target web servers. Then you'd create a web deployment project for your web app. In the properties for the deployment project you tell it how you want to compile the project and what web.config replacements you want to use for each solution configuration.
The end result should be that you can open Visual Studio, pick a solution configuration, build the deployment project. The build will create a folder with everything you need for that environment including the correctly configured web.config files. Then you just copy the folder to your server and you are up-and-running.
Best of all, since the different config files are all stored in the projecct, it lets you manage your configuration in one place and check it all into source control.
Do note that there is no equivalent in Visual Studio 2010. Instead, VS 2010 has a whole new deployment mechanism called MSDeploy. With 2010 you don't need a seperate project for deployments, and MSDeploy goes a lot further allowing you to package your SQL databases and other stuff too.
You can use the Classic mode under IIS6 by changing the process. That is actually pretty simple and it should work.
Another approach would be to automating your deployment process and have it so that it deploys the correct web.config to the server when you need to update your application.
If you run your IIS 7 websites using the Classic .NET App Pool, then the config files will match what you would use for IIS 6. That's probably the easiest thing to do until you're ready to migrate everything to IIS 7.
Knowledge is a great way to get over fear. Figure out what's going on (you're currently grasping at straws) and the fear will go away.
It's my guess that you'll do better if you refactor the code that uses the config file. Sloppiness there can definitely explain your weirdness and inconsistencies. You can't control much with your config settings if the code isn't behaving properly.
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.