As part of our .NET deployment process we'd like to make a new website on IIS. The idea is to be able to run another set of smoke tests before making a site live - plus being able to immediately roll back to a previous version should something go wrong. We hope to have this all hooked up to Jenkins.
While IIS7 has a comprehensive suite of tools that allows us to throw together and configure a new website via PowerShell, IIS6 shares no such luxury.
While upgrading to IIS7 would obviously solve our issues, our servers currently run on Windows 2003.
Is there a way to do what we want in IIS6? Are we going about the issue the wrong way?
IIS6 configuration is stored in 2 xml files, MetaBase.xml and MSSchema.xml located in %SystemRoot%\System32\Inetsrv.
Check these links about available scripts for managing IIS sites, application pools etc:
Internet Information Services (IIS) 6.0 Resource Kit Tools
Managing IIS Configurations Using Scripts (IIS 6.0)
Administering Servers from the Command Line in IIS 6.0 (IIS 6.0)
How to manage Web sites and Web virtual directories by using command-line scripts in IIS 6.0
Regarding configuration of sites like default page, .NET version etc I couldn't find any script for that on Technet. But if it is in configuration xml, I think you can create some command line tool for that.
Related
I need to show customer an ASP.NET MVC3 website, but they don't have IIS or Visual Studio installed. only .NET Framework 4 is installed.
So my question is: Is there any tiny little IIS server (like IIS Express), but don't require installation, that can run the compiled site just on local machine?
PS: I don't need advanced features. But HttpHanlders and HttpModules should be working fine.
I back Shan's suggestion to host your website on a server somewhere and access it over the Internet. I don't see why it wouldn't work for Intranet applications either unless you have dependencies on some services like SMB shares or network printers.
The Cassini ASP.NET webserver is portable and doesn't require installation, but it doesn't run the same as IIS and there are things that will break (because it invokes ASP.NET for every request unlike IIS, so if you've blocked unauthenticated visitors then they wouldn't be able to download site images and stylesheets, for example, until they've logged in).
Howcome I deploy my intranet ASP.NET MVC project?
What I've got so far:
project itself;
several client machines connected in a workgroup and server;
IIS Express 7.5, SQL Server 2008 R2 Express installed on a server.
It should be mentioned that though it's odd and unusual but server is just a machine without (even) server OS installed. Please note that it's not mine idea and is the environment I've got at the moment
I've read the instruction http://msdn.microsoft.com/en-us/library/gg703322(VS.98).aspx but it describes situation when you have Web Developer installed on the same machine.
Please help!
And Thanks!
This is the 100% manual approach, you might be able to access the remote web server via VS if authorization/permissions is lined up properly (much simpler, basically you just hit deploy):
Install IIS
Install .NET Framework 4
Install MVC
Register ASP.NET with IIS (just to be safe run it again)
Create Website via IIS Management Console (use a new directory for the website)
Put your files inside the new directory
Make sure permissions are setup properly
That's it
Webdeploy is an alternative to WebDav, FTP, and FrontPage extensions. It also acts as an alternative to DFS for replicating websites. I found instructions for configuring Windows 2008, but I'm unclear how to set up 2003 especially when multiple sites / IP Addresses are present.
It is possible to install Web Deploy Tool 1.1 on Windows 2003 for IIS6. Generally this tool is used for synchronization between remote/local sources. You can refer to the following article about how to use Web Deploy Tool 1.1 on Windows Server 2003:
Synchronize IIS 6.0 Web Sites
http://learn.iis.net/page.aspx/445/synchronize-iis-60-web-sites/
However, it's not possible to use this tool to enable publishing from Visual Studio 2010 to the webserver. The reason is that this method relies on ‘Web Management Service’, which is newly introduced in IIS 7. This service can be used when there are some users delegated to manage certain sites or applications on the server. However, this service does not exist on Windows Server 2003.
IIS Web Management Service (WMSvc):
http://technet.microsoft.com/en-us/library/cc735010(WS.10).aspx
I use WebDeploy (MSDeploy) on 2003 servers to ensure content, IP addresses, certificates, etc remain the same across a MS NLB cluster. I also created a batch file to automate most of the different functions based on what I want to do (Full Server replication, single website, content only). Here are my notes on using the tool that I posted on my company's internal blog:
MSDeploy (http://www.iis.net/download/webdeploy) is a tool developed by Microsoft to make migrating, deploying, copying, and backing up websites easier. It was developed for IIS 7, but most features work in IIS 6. It can also be used to move a website from IIS 6 to 7 although I have not tested this. Some things to keep in mind when using MSDeploy are:
MSDeploy must be installed on both source and destination servers
The “Web Deployment Agent Service” must be running on both source and destination servers
Application Pools for the website must be created on the destination server before using MSDeploy or it will fail. I think this is fixed in IIS 7, but I am not 100% sure
When deploying a website, MSDeploy will attempt to put the files in exactly the same path on the destination server. If the path doesn’t exist on the destination server (like if the source path is D:\website and the destination server doesn’t have a D: drive it will fail)
The migrated website will have the exact same configuration as it did on the source IIS server. Some settings you might want to change after the move/copy are the website IP address and home directory path. You will need to make those changes manually on the destination server.
The metabase keys will need to be edited on a per-server basis since they are unique for each server (unless you created the sites using MSDeploy, then it uses the same key string across servers). As more and more sites get deployed with MSDeploy, the key strings will become universal for all servers since the metabase keys will be the same on all servers.
I'm deploying an ASP.NET application to Windows Server 2003 under IIS
IIS is serving html pages fine but I get a page not found when I try and serve IIS pages
You may need to "register" IIS for ASP.NET applications. As an administrator, run the command "%systemroot%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -i". In addition, you may need to convert your web site to an application through the IIS management console.
By default, IIS has ASP support disabled in IIS6.
A server running a member of the Microsoft® Windows® Server 2003 family supports application server functionality, with Microsoft ASP.NET as an option that you can enable when configuring the application server role. To deploy ASP.NET Web applications to a production server, you must be sure to enable the ASP.NET and Internet Information Services (IIS) roles on the production server before you distribute the application.
See here for instructions to enable it:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/9fc367dd-5830-4ba3-a3c9-f84aa08edffa.mspx?mfr=true
Other possible reason could be Web Service Extensions, where ASP.NET version could have been disabled. My other post here explains steps to solve this.
Make sure the right .NET framework is installed properly
Make sure the ASP.NET extension is enabled
Under website properties, ASP.NET tab, make sure the right version is set.
After having this same issue and trying all of the above without any luck. We reinstalled SP2 for Windows 2003 and this resolved our issue. I too have seen this problem resolved a few times with the other answers. Most of the time just reinstalling .Net 2.0 resolves the issue but not this time.
For future reference, this could also be the issue:
IIS on a Windows Server 64-bit can only to run in either 32 or 64 bit mode.
In short you need to:
1) run adsutil.vbs to enable 32 bit asp.net apps on win 64
2) re-register IIS calling aspnet_regiis.exe
3) re-open IIS Manager, go into Web service extension list and ensure ASP.Net version {2/4.xxx} (32-bit) is set to Allowed
(You might need to do Steps 2 and 3 for both Framework 2.0 and 4.0 if you want to run asp.net apps on both versions)
Full details are in the following link: http://support.microsoft.com/kb/894435
Another future reference in case this is helpful to anyone who used a similar path to mine.
My back end for the ASP.NET app was MySql not Sql Server, which for me meant having a mysql connector, the reason my IIS was not serving the .aspx file is because on my development environment I was using a different version of the MySql connector than the one installed on my production environment, I updated the MySql connector on the production server to match the version Im using on the development environment and it worked great.
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.