Occasionally, I find that while debugging an ASP.Net application (written in visual studio 2008, running on Vista 64-bit) the local ASP.Net development server (i.e. 'Cassini') stops responding.
A message often comes up telling me that "Data Execution Prevention (DEP)" has killed WebDev.WebServer.exe
The event logs simply tell me that "WebDev.WebServer.exe has stopped working"
I've heard that this 'problem' presents itself more often on Vista 64-bit because DEP is on by default. Hence, turning DEP off may 'solve' the problem.
But i'm wondering:
Is there a known bug/situation with Cassini that causes DEP to kill the process?
Alternatively, what is the practical danger of disabling Data Execution Prevention?
The only way to know for sure would be to dig through the Cassini source and see if there are any areas where it generates code on the heap and then executes it without clearing the NX flag.
However, instead of doing that, why not use IIS?
EDIT:
The danger of disabling DEP is that you open up security holes. DEP works by not allowing arbitrary generated code on the heap to be executed. This helps prevent malware programs from inserting code into the data segments of legit programs.
You are on vista, iis got better (7), cassini stayed crappy.
So just start this app on iis with a host header and a hosts file entry.
You can grant certain programs exclusion from DEP if you need.
As Jonathan
mentions this does open up any vulnerabilities that application may have.
Using IIS in Visual Studio isn't the pain in the ass that it used to be in 1.1/VS02/03 days. There are lots of good reasons to prefer IIS over the Cassini server (articles by Dominick Baier):
Cassini considered harmful
Another Reason why I would not recommend Cassini
Dominick is 'the man' when it comes to IIS and security stuff.
When using IIS for a web app, I always create the app in IIS first, point it at my preferred folder, then get VS to create the project. This means you don't end up cluttering c:\inetpub\wwwroot with your web apps.
Of course, now we have IISExpress which if you're targeting IIS7.x it's the obvious choice for developing ASP.NET applications in Visual Studio.
Thanks for the answers. I guess I developed such an aversion to IIS in the .net 1.x era that I've refused to consider re-using it -- until now.
aside: when choosing between two equally acceptable answers from ChanChan and Jonathan, I arbitrarily marked Jonathan's as 'accepted' because a) he got in first and b) his rep is currently lower.
Related
I have a legacy Classic ASP web application that performs slowly on my current Windows 10 / SQL Server 2017 Dev machine as well as a Windows server 2016 machine.
In more detail, the ASP parts of the application construct and execute a lot of queries on the SQL server behind it. The queries seem to be taking about 5-10 seconds each to execute and some parts have more than 200 queries resulting in script timeout errors.
The interesting thing is that the same code ran on another Windows 10 Dev machine and performed just fine (the main difference is Windows defender being turned off on that machine), as well as on Windows server 2008.
I've tried disabling real time protection as well as Windows defender altogetger on my Dev machine with no luck.
Any ideas or hint as to what could be causing this?
Turns out the very undocumented (local) value for the database source was what was causing the delays. Changing (local) to the actual machine's name in your Classic ASP project's configuration will fix the issue. This is usually found in a some ASP configuration file within your project (e.g. config.asp).
I will edit this answer with several other topics that I found throughout my research which should apply to anyone having issues with Classic ASP projects.
What's also interesting and hasn't been answered yet is that two machines with (basically) the same stack were having different results.
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 am so used to attach a process when debugging ASP.NET application in .NET 2.0 and VS.NET 2005. I don't know what happened to this functionality in VS.NET 2008.
I also don't want to do debugging by starting from the start page because when the application is big enough you don't want it to be compiled and you sometimes cannot catch a case from start and you want to catch that case during that time.
I could't figure this one out.
I am running Vista Ultimate x64 with VS.NET 2008 Team Suite.
Also in the start options of the WebSite Propery pages Server is selected as "Use Default Web Server" and custom server is grayed out which I cannot check. (I don't know if I need some change here but I can't even try that)
On top of it, I tried debugging from default page but in that case what I got is "Unable to start debugging on the web server. Mixed mode debugging is not supported on Windows 64-bit platforms". What? Anyway I get into the configuration manager of the solution and changed the mixed mode to ANY CPU, however no luck.
Going without the help of debugging brings down ASP.NET to the level of PHP or other kinds.
Additional notes:
I am using DotNetNuke 5.0.1 and building modules under that.
IIS 7 is used with Integrated mode.
The key that I have found on 64 bit Vista for debugging is the following.
1.) Ensure that the web application is FULLY running in IIS and not Cassini (http://localhost addresses)
2.) When attaching to the w3wp.exe process, be sure to select the one with a type of T-SQL, Managed, x64 and NOT the one that shows a type of just x64
Following these two steps I have gotten around all of the issues that I have had. Similar to those you list above.
By the way, for anyone else finding this article based on the same error message (at least in my case) was to modify the app pool in IIS. Go to advanced settings, change "Enable 32-Bit Applications" to True. VS2010, Win 7 64 bit.
Okay, it sounds like you're suffering from a couple problems.
1) Automatic startup of the webdev server: This is usually caused by a project in your solution being set to "Always start when debugging". Simply click the project in the solution explorer and hit F4 to bring up the properties window, and change it from "True" to "False". You might need to check all the projects in the solution.
2) Attaching to a process should be done when the site is published to a real IIS, which I'm assuming you're doing. I'm not totally familiar with IIS under Vista, but you'll need to go into it and make sure that debugging is enabled for your web application. If you're doing this, you shouldn't need to bother with the Start Page or using custom servers.
Hope that helps some.
Help came from Mitchel Sellers.
He pointed out that the debug mode was ok however while attaching to the process, the "Attach To" was "Automatic:Native Code".
After changing to only "Managed Code" or simply by selecting "Managed Code" it started working.
Thanks Mitchel.
And here is the final words from Mitchel:
The "Script" option, is for classic ASP scripts, which ALWAYS run in 32 bit mode, thus debugging T-SQL and Script at the same time results in the "mixed mode", as T-SQL is 64 bit by default. Additionally without the "Managed" option selected, you would never be able to debug anyway.
Now, as to why it was different? I'm not sure, but once you change it you should be set to go for the future.
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.