I used to develop my web-apps using ASP.NET 4.x and host them in full IIS already during development, because:
1) I use multi-tenancy (site1.me.local and site2.me.local point to my app) and IIS express can't handle that AFAIK
2) Most of the times I do not need a debugger -> I just (re)build my app and refresh the browser - restarting IIS Express and the VS debugger wastes some time
Now I tried my first web-app using ASP.NET 5 aka Core 1.0 and I wasn't able to get it to run in full IIS to continue using my known workflow. I found out I can start IIS Express without debugging and just rebuild to solve #2, but #1 is still open.
Is full IIS even supported for ASP.NET 5 / Core 1.0 during development? If so is there some documentation on how to set that up around?
All documentation for full IIS I found is for publishing, but not for development.
You may actually not event want to use IIS in development with Asp.Net Core. Asp.Net Core has been separated from IIS and even in production IIS will only act as a reverse proxy passing requests to your AspNet.Core application. Asp.Net Core uses Kestrel as an application server and it is much easier to use just this during development. To get a similar workflow you had before you would use dnx watch/dotnet watch during development which will watch code files of your application and if any of the files changes it will stop the application, rebuild the project and restart the application. This is when you can refresh the browser to see changes (note that this is even one less step that you had before where you had to rebuild the application yourself).
It still should be possible to use IIS for development if you really need it but if you don't have a specific scenario that requires IIS I don't think IIS for development will give you any benefits.
The integration mode with full IIS has been changed several times (from Beta to RC1 and now to RC2), which messes up the documentation,
https://github.com/aspnet/Announcements/issues/164
You probably need to wait till RC2 is available to see the latest official steps.
Related
I am having problems accesing the session after upgrading a web project to .net 4.5
firstly, I had a functional .net 3.5 web forms project which I upgraded to .net 4.5 on my dev machine. This compiled and worked well locally
Secondly I modified the application pools on my dev iis server to use .net 4.0 in preparation for running the new code deployment
Finally I deployed my upgraded project to the dev web server.
The problem is that I am getting an error straight away where I am being told I need to enable session state to access the session variables.
Background:
I have a master page which checks for the existance of a session variable. I have put this code in the page_init event of the master page to ensure it runs before the page_load of the content pages etc.
This technique worked fine under .net 3.5 and works well under 4.5 on the local dev machine. But does not work on the iis server.
I have followed various threads telling me to set enablesessionstate=true in the config all to no avail.
Could it be that there is either a problem with .net sites runnning .net 4.5 on iis with regards to sessions, or am I missing something more obvious.
Please help as this is very frustrating
Well, I have no idea what was causing this?
I have fixed the problem by creating a brand new .net 4.5 project and importing assets / pages from my preexisting site.
Remarkably doing it this way caused no issue with the session after deployment to the web server, Very odd indeed. I can only assume that the project upgrade process that I initially used left some odd configuration in place which upset the server ???
Anyhow, have invested enough time in this now, thanks for taking the time to comment.
I have an ASP.NET website that i want to deploy to IIS 6.0. When i set the sites ASP.NET version to 2.0, the setting reverts to 1.0 when IIS is restarted. There are two other ASP.NET sites on the same server whose version setting is being maintained across IIS restarts.
So this problem seem to be affecting only new sites being created. I'm just wondering if i need to re-register iis or what?
So, here's why: one of your apps runs .net 2.0, while another runs 1.0, and they are using the same application pool. App pools are designed to run only 1 .net version. Unfortunately, this restriction isn't validated during setup time, but errors happen on runtime.
So, check that. Create another app pool for one of the .net versions.
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.
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.