I'm looking into Azure and unsure if Classic ASP (i.e. ASP 3.0 with .ASP extensions) can run in Azure?
I found this blog post from January 2009 indicating Classic ASP can NOT be run in Azure. But on this interoperability page it looks like now, other platforms like PHP can be run on Azure. I still see no mention of Classic ASP though.
Can Classic ASP pages run in Azure?
Check this out - http://channel9.msdn.com/Shows/Cloud+Cover/Cloud-Cover-Episode-31-Startup-Tasks-Elevated-Privileges-and-Classic-ASP, at about 15 minutes in they tell you how to run Classic Asp in Azure
The actual startup command is at 23:51 within the video.
I've tried replicating the code that they have on the show but I get an error - "CloudServices64 : Cannot find file named 'approot\bin\startup.cmd'" for startup task startup.cmd when I try to build the project. Hopefully its just me and you'll have better luck.
To solve the error "CloudService...." - have a look at http://207.46.16.248/en-us/library/gg456327.aspx It tells you that you need set the properties on the file to "copy to output directory" to always
Yes, the instructions for enabling it are here:
http://coderead.wordpress.com/2011/09/20/running-classic-asp-on-azure/
Not yet, but as soon as the new "virtual machine role" becomes available, you'll be able to configure your own virtual server(s) to support classic ASP. No timeline given AFAIK, but "soon" has been mentioned.
These servers will run on the Azure hardware, but they won't run the Azure Guest OS 1.x, so you cannot easily use Azure features like Storage or AppFabric... then again, you might not want to from a classic ASP environment :-)
EDIT: at the time of asking my answer was correct (there was no full IIS available), but a lot has changed, so the answer in 2012 would definitely be "yes", as detailed below.
Nope. You can attempt to get around recoding your ASP pages with something like the ASP Classic Compiler.
I've asked a question about changing the version of .Net sites in the IIS. If it affects classic asp sites etc (See Does asp.net setting affect classic asp (IIS 6 settings))
And that seems fine. So my follow-up question is, will running this command get me fired? What it does is changing the default value (and all existing?) of the .net version to 2.0.
This wont affect any of the .net sites since they're allready versioned to 2.0.
The classic asp pages needs to get its app pools updated so its functionoal with 2.0 but may I run into any other troubles?
I've tried doing this on a test environment and no sites whet down during the installation period (from the command) but I did not have any classic asp sites or any .net sites running though (which I should test, come to think about it) but may something else break?
Is this command doing anything else? We have some very large sites running and we cannot have downtime periods so I need to be 100% sure that this command is safe. Since all sites go down everytime we change a new sites .net version number we need to get this fix live asap.
Any good ideas?
This should not cause any side affect as it relates to what the IIS does with .NET pages (e.g. aspx extensions).
Since the classic asp pages are not handled by the .NET extensions in the IIS I can see no reason to worry.
EDIT:
According to MSDN you can use an option
-norestart - inhibits the restart of the World Wide Web Publishing Service after installing or updating ASP.NET script maps. If you do not use this option, all application pools are recycled.
so you can see from that application pools will be recycled.
long time since I asked, but Dror, thanks for your edit. I'll be sure to try it.
I actually found a solution to this problem some months ago.
You can export a sites configuration, and you get a XML file, edit this file and set the site name etc to something (like dev1). Then you import this and you got yourself a new site with .net pre-configured. Just make sure you change the name and other things that cannot be the same as another site (like host things, cant remember exactly what parameters there were) because that would cause a problem I guess.
Happy iising
I would like to hear if there is a small classic ASP server, similar to the ASP.NET Development server that comes with Visual Studio?
We are a small group that supports a legacy (classic) ASP site, and would therefore like to have a small server that easily can be executed on a Windows XP machine. Currently we're stuck with IIS 5.1 on our development machines (and because we're running XP Pro, we cannot update to IIS 6 or 7).
I've tried installing the Cassini web server, but that doesn't seem to work with classic ASP either.
You're not going to get anything extra from ASP by running on IIS 6 or 7. Are you having any specific issues with being stuck on IIS 5.1?
Have you tried Baby Web Server? - http://www.pablosoftwaresolutions.com/html/baby_web_server.html
The short answer is No, there is no small web server that runs classic ASP. There are many alternatives, as mentioned here, such as IIS or Apache plug-ins, but none that has a similar small footprint like the ASP.NET Development Server that comes with Visual Studio and that supports debugging.
There is a small footprint web server that runs Classic ASP.
Its called Abyss Web server. Abyss Web server is produced by Aprelium software and can be downloaded free of charge. Abyss Web server can be configured to run with ASP.net OR Classic ASP.
The Server can be configured to run ASP.net without any addition downloads.
To run Classic ASP on the server a program called ActiveHTML written by Selisoft must be downloaded and configured to allow Classic ASP to run on the Abyss web server. Active HTML is on a 45 day free trial and if you like it the purchase price is currently around 30 to 40 euros depending on whether you need a client or server version.
Hope this helps.
Anthony
Abyss web server http://www.aprelium.com/ supports classic ASP (also ASP.Net, Ruby, and PHP) with a 3rd party extension that cost $$$. But at one point there was a free version of the third party component, you MIGHT be able to find a copy of that still floating around. Not sure about debugging.
Baby ASP Web Server can take care of things for you, PLUS you don't have to install it, so it doesn't plop all sorts of crazy settings into your registry.
Get it here
Your only real choice is to either run Windows server or Vista in order to get the latest version of IIS.
Cassini doesn't support classic asp.
According to this post it is not possible to run ASP on Cassini. A couple of google searches later I have still not been able to find any other alternatives either.
What functionality is it that you're after? If it is the quick-and-easy running features of VS, you can quite easily make the IDE debug on IIS (although ASP cannot technically be "debugged" - what you really do is just run it with the Ctrl+F5 command).
Here is a web site that allows you to run classic ASP pages from any web server (including IIS and Apache), but it costs money:
http://www.selisoft.com/en/ahtml/index.phtml
I'm working on a fairly new project and we started from scratch. So not only the web application itself needs to get developed, but also the whole process of publishing the site and configuring the web server etc. need to be done from scratch.
This question might be more apropriate for serverfault, but that really depends on the answers. So, let's give it a try.
Wehn ever I publish our site via VS2008 (right click on the web site, publish web site, wait... done) I need to somehow tweak the process and trigger some other tasks, like:
- Copy some folders from my dav machine to the web server
- Delete the test database and let some scripts run on it
- and maybe some more I'm not remebering right now.
I was reading about the most obvious solutions like MSBuild, Powershell and VSTS2008, but I don't really want to dive deep into them until really I know, that theses tools can actually solve my problems. So guys, I'm pretty sure a lot of you have got a lot of knowledge about these tools or know even better ones. Please let me know. I really appreciate.
Thats my environment I'm living in:
- VS 2008
- VSTS 2008
- SQL Server 2008
- Windows Server 2008
UPDATE: Thanks for the great answers so far, but I'm especially looking for a solution integrated into Visual Studio Team Foundation Server as we're already using it for Source Control.
Cheers,
Steve
We deploy our web application with Subversion, and are very happy with it.
The build server compiles the application, copies it to a deploy directory and checks in changes to a Subversion repository. Okay, I admit that this is not trivial, but it's worth to invest here... because on the server(s) the deployment is now extremely easy. Advantages are:
Only the necessary files are copied to the server, the downtime is minimal (using svn update)
It's a piece of cake to verify what version is deployed to the server, and it's easy to have a consistent version across multiple web servers
If you screwed up, it's just 2 clicks to revert back to the previous version
It's takes care of deleting files when you deploy a new version. Copying a web application over an older version can leave potentially dangerous files
Modifications in the web.config are not overwritten by the deployment, they are merged. That's really a big plus
You can set pre and post build events, and can have one the events fire a script to complete your tasks.
You might look to see if the IIS Web Deployment Tool fits your scenario; it allows you to publish your website, configuration settings, database, etc... all together. This will also be integrated into Visual Studio 2010.
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.