I finally got my ASP.NET MVC application hosted on my local Windows/IIS server. I went to the login page but when I try to log in it says,
Error:
An error occurred while processing your request
This is fairly non-descript...
My gut feeling is that when I did the web deploy, I didn't deploy the localdb(?) where the users' credentials are stored. Before I try to re-deploy the entire app, I'd like to see if anyone can offer some guidance. Am I on the right track? Are there other possible causes/solutions I should investigate?
I'm using the default registration/login system that is in the project to start with, and it woks just fine in VS. I did a regular web deploy to my IIS server, and the site works just fine until you go to log in.
Fixed: This issue was caused (as suspected) by the inaccessibility of the LocalDB where all the users' credentials are stored. VS uses this light DB instead of making you install SQL Express or another alternative (much like IIS Express works better for debugging than full IIS). When I push my application to IIS from VS, the database wasn't connecting. I eventually found this other SO question, and the top answer fixed my issue.
How to deploy ASP.NET MVC 4 application using localDB to local IIS on Windows 7?
This will solve the issue, but there is a lot of conflict on the web as to whether or not it is ok to use LocalDB in production, so if you have a lot riding on your project you might want to take a look at that. For my purpose, LocalDB is just fine, so this solved the issue. Thank you to all who responded to my (admittedly) broad question. I'm sure this will be a useful thread for others with the same issue.
This question kind of follows on froma previous one I posted.
I have a .net web site deployed on a server.
In certain circumstances the site falls over. Specifically, when I browse to the site from my PC (which has visual studio) to the web server using a particular dns entry.
So, I want to debug a browser session on my PC which is looking to a URL on a web server.
How can I do this?
Within VS when I attach to Internet Explorer no break point is ever reached?
Thanks in advance.
Jim
Attaching to Internet Explorer isn't going to help you because the web site doesn't "run" inside IE. You need to attach to the IIS process on the web server to see what's going on.
May I suggest you start by having a look through the basics of production debugging on Tess's blog. I think this would be a great place to start for you.
Sussed it... attach to w3wp.exe on the remote server.
Made easier for me because the app I'm debugging is in its own IIS App Pool so I could see (by the user name) which one of the w3wp.exe to attach to.
Works like a dream!
I am currently using Visual Studio 2008 on XP Pro SP3.
Developing against http://localhost/ everything including debugging works fine.
I need a second website on my machine. IIS 5.1 only allows one website at a time so I used the JetStat XP Pro IIS Admin tool to create a second website. This runs by stopping the Default website and starting the other.
I have added the new website name into the Hosts file and mapped to 127.0.0.1.
Websites can be accessed via this address http://NewHostname/VirtualDirectoryName
Projects can be started without debugging (Web Applications & Websites).
However, when I try to debug I get an error: "Unable to start debugging on the web server. An authentication error occurred while communicating with the web server."
Integrated Authentication is enabled in IIS.
I have seen a lot of documentation with many fixes for "unable to start debugging on the web server" errors but they all seem like huge overkill for my problem, after all, debugging works fine provided I'm not doing it on this different hostname. They talk about doing things that I would do if debugging did not work at all even with http://localhost/.
Is there a place where I can just add this new hostname so that VS debugging is allowed? Do I need to change permissions somewhere? I feel like there should be a really simple solution that I'm just overlooking.
Here's a description of the problem: http://blogs.msdn.com/webdevtools/archive/2008/08/13/debugging-a-website-with-a-host-header.aspx
And here's the recommended registry workaround: http://support.microsoft.com/kb/896861
Do yourself a favour and download IIS Admin .NET.
This handy little tool allows you to switch between your websites at a snip - each one will become localhost when activated, and crucially, get you out of this debug debacle.
http://www.codeplex.com/iisadmin
You do have to add the hostname to a value within the registry.. but I can't remember where.
Since you can only have one website running at a time, why don't you just have them all running as 'localhost'? This way you don't have to change any annoying registry settings but you still have your applications running in individual IIS Websites.
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.
I have an ASP.Net 2.0 web site, using the DotNetNuke framework (4.09), and it will not compile, but when I hit the site in a browser, it works. Even the parts that don't compile will work. How is IIS able to compile and run this site, when Visual Studio can't? Everything is the same in both places... I copied the entire web site from the remote server on to my local machine, then I set it up in IIS the same way. On my local machine, Visual Studio can't compile the site, but it still runs. How can this be possible?
The specific errors are not important, as there are 189 of them, from every possible part of the site. I'm not trying to fix the errors... what I want to know is how it's possible for the web server to run the site, regardless of the errors. Please pay attention to what I have written - everything is exactly the same in both places. There are no missing DLLs, no different configurations, nothing on the machine itself... remember, the site runs fine on my local machine.
Is this a web site or a web application? If it's a web application, you're probably still running off the last successfully built bits in the bin.
The site is using old dlls, or possibly you have references missing in your local version that the server has just fine.
As Mitchel said, we need to see the error before we can really answer your question.
To give you an answer on this we would need to know what the errors are.
Your local machine cached the 'working' copy and is using that maybe?
The site was compiled successfully at one point as it works on the remote server. Thus, copying it to your local machine and hitting the local site will also work. However, there can be several reason why you can't re-compile it on your local machine including; missing references, web.config entries, third party control licensing, etc..
I realize you are not trying to correct the 189 errors, but there are clues, if not answers, in the error listing that will get you moving in the right direction.