Are there any particular settings one should optimally enable/disable/tweak when doing ASP.Net MVC development on local test machine Windows 7 using IIS 7.5 and moving in and out the debugger & recompiling refrequnetly (integration/troubleshooting stage now before TDD fantactics throw stones - although admittedly I could have more under test), I work with 64 bit edition but figure this probably applicable at both x86/x64?
I'll start with one:
Ping Period (seconds) - increase from 90 to 3000 (or something somewhat higher) so you can if unfortunately need to a good bit of time whilst debugging or disable ping on local test machine.
Credit: http://blogs.msdn.com/johan/archive/2007/09/12/my-web-application-times-out-when-debugging-in-iis7.aspx
However I see over stuff such as:
Disable Overlapped Recycle & Recycling settings etc.. that I wonder if could increase performance or make debugging less friction
Question prompted by the annoyance that I've ran across a few recent debugging issues (not apparent in production) including a random, and tempormental error "An assembly with the same simple name blah-blah-lah-assembly-definiton has already been imported . Try removing one of the references or sign them to enable side-by-side." (iisreset resovles) and generally slow debugging attaching. The points and answers to this question need not help with the above (I believe it may be related to spark view engine as that where the stacktrace ends) but figure it worth mentioning incase someone has a direct suggestion *
quick tip: if you're experiencing slow response times (~1-1.5 sec) from browsers other than internet explorer (eg: firefox, chrome, safari) while running your mvc/ other web app on your local machine using win7/vista, it is due to dns resolution with ipv6.
firefox solution: disable ipv6 in about:config (boolean cfg 'network.dns.disableIPv6')
machine wide soft solution: uncomment the good old localhost address in the hosts file (%WINDIR%\System32\drivers\etc\hosts):
# localhost name resolution is handled within DNS itself.
127.0.0.1 localhost
# ::1 localhost
machine wide hard solution: disable ipv6 completely
credit goes to this blogpost: http://weblogs.asp.net/dwahlin/archive/2007/06/17/fixing-firefox-slowness-with-localhost-on-vista.aspx
Embarcadero guys just published a fresh article on similar topic for Delphi Prism (aka Delphi for .NET), so why not take a look on their suggestions?
http://edn.embarcadero.com/article/40108
From the experience i have working with asp.net mvc, i can tell that there are no special settings for IIS 7 or IIS 7.5 for working on asp.net mvc projects. It works fine in the default form, you just need to create a new website and point it to the folder that has the files for you application.
For debugger if you ask, you can simply put a breakpoint in the code and hit that breakpoint when you run the application from visual studio. But by default the application will use the development web server that fires up when you run a web application from visual studio. If you want to the application to run using the IIS installed on your system you will have to change the project settings. See here for a screen shot of how to do so
http://blogs.bootcampedu.com/blog/post/Debugging-aspnet-mvc-application-using-IIS.aspx
Additionally you can also use System.Diagnostics.Debugger.Break(); for putting a break point in the code.
If you only want to debug your application, I recommend to use the built-in development server of Visual Studio.
If you debugged the most of it or want to do that on IIS, I recommend you the Ctrl+Alt+P shortcut, which enables you to attach a debugger. Select w3wp.exe and you can debug with IIS.
Related
It may be a silly question but why one would like to attach debugger to IIS instance?
These SOs
Attach Debugger to IIS instance
How do I attach the debugger to IIS instead of ASP.NET Development Server?
show you how to do it but could you let me know what are the benefits of doing this?
One time, in my entire career, we had a web app that started getting strange errors that had us baffled. We tried a dozen things to try and figure out what was wrong, but we were panicking and needed an answer immediately. So, we attached a debugger to the production instance and set up a few watch/break points. It helped us track down the errors and fix the problem.
Naturally, it hung the server during our debugging session, and made people mad, but no more mad than they already were, because of the problem we had.
It would not have been necessary if the code had been written better, with error logging and diagnostic points. I don't expect to ever do it again.
Apart from TimG's post a couple of reasons I can think of are:
To debug the application in a closer representation of its
production environment
To debug on a remote machine
Example, like #TonE #1 -- in order to test a deployed website (with web.config transformations) locally, like if you can't remote debug a live website or just need to test config transforms (since you can't run them in-place):
Open site project from C:\Dev\AwesomeWebSite\AwesomeWebSite.sln
Publish the site to a local folder C:\Webs in Release mode (or Whatever mode)
Set up a local IIS website pointing at the published project
Do stuff on the locally-deployed version (e.g. browse pages, make webservice calls, etc)
Attach VS to w3p.exe (appropriate instance) in order to debug the deployed version
You might be able to effectively do the same thing by instead pointing the Project at your IIS website per this answer.
I'm using Microsoft Visual Studio 2010, developing and debugging a ASP.NET C# application.
(I would imagine that other versions of Visual Studio might also have this issue, hence the additional tags.)
During debugging I find it easier to set the Start URL (in the project's Properties tab) to
http://localhost:[port]/Account/Login
where [port] is the port that the development server opens when it is created.
This [port], however, is the issue; as the development server can potentially not work/stop working from time to time, and can occasionally re-assign to a different localhost port, setting the start page as above - basically a static address - means extra work having to either alter the URL in the debugging browser window, or going into the properties page of the solution and changing the port number prior to debugging.
Admittedly, its not much extra work, and it might be a case of laziness, but its not really necessary when there might be potential for a dynamic alternative that I'm not aware of. The use of visual studio's built-in development server is preferred over setting up a dedicated static server simply for speed of setting up a project and for brief stints of development debugging of new code additions.
In an ideal world and/or for longer QA debugging, I'd publish to a dedicated debug server, but that would be for a nearly finished project in its entirety or major milestones.
Is there any way of setting a relative/dynamic port as part of the start page in a solution's properties page, or will I just have to keep changing the port manually?
To my knowledge there is no way to scope the ports VS/IIS Express will use for running the dev server. I have never heard of a work around of killing the dev server when it locks up - I just close/stop the server from the toolbar.
The dev server should only lock up occasionally. If it's frequent then I would look into other causes or what you were referring to and stand up a full blown dev IIS server, but like you said, that takes a bit more time.
I have an application that runs perfectly fine locally using the VS 2010 application server, however, when I deploy to our web app machine startup just spins and spins and never loads. We have other apps on this same machine that load just fine (this is a debug deployment of same app in product).
I have been spinning my wheels on this for days and I am at a loss as the problem could be.
Here is what I did
Create a new directory (same level as other apps)
Copied over our existing test (www.domain/test/) and it works fine
Build and publish new debug app (www.domain/test/) and it just spins trying to load first form.
I know the diretory is "working" as the 'test' application I put there works fine.
If it's killing the App pool, you might get something in the event log. Fiddler (www.fiddlertool.com) is great http debug tool which let you see if you're in a redirect loop. Also Firefox shows a more meaningful error, something about exceeding the max redirect count.
It does sound like something is looping, but not quick enough to cause a stack overflow, which is odd, because you'd expect it to fail every time.
Simon
Do you have the ability to remote desktop into the machine? If so try running process explorer and look at the process details for the worker process that is giving you issues. Definitely look at the TCP connections being created. If your processor is pegged at 100%, and memory usage is rising then you probably have an endless loop running.
It sounds like it's more related to IIS than ASP.NET. What about the identity that the website is running under? Is it possible that the user the site's running under a bad user, or maybe the password needs to be re-entered?
I did a quick Bing search
There are a lot of postings regarding the error message you described above. Most if not all point to code in your app that is crashing. I know I had a similar problem when I used an automated/threaded daemon utility in my web application. Make sure your code is not bringing down the server, sometimes the VS2010 web server is a little more foregiving than an actual IIS deployment.
If that doesn't work try running a Remote Debugging Session to try and catch any errors being thrown but not handled.
Lastly you could try to setup a new local IIS server to see if you have the same problems. Scott Gu has a nice article about using IIS Express to do this.
When you run an application from within visual studio, it seems to pick a random port on localhost. For example, running an application right now, I get
http://localhost:3240/ApplicationStuffHere
I realize this port gets loaded into the solution file, via
VWDPort = "3240"
How does this get decided on? it seems fairly random.
By default, ASP.NET Web Application Projects are configured to launch and run using the built-in VS Web Server (aka Cassini) on a random HTTP port on the machine.
This port number can be changed if this port is already in use, or if you want to specifically test and run using a different number:
(source: scottgu.com)
I know this is a little bit old, but I was wondering the same thing. I eventually found the answer for VS2005, but figured I'd share it with the stack overflow community.
Open your project
Click (not right click) on the name of the project in the solution explorer (that top, bolded line)
Hit f4 - this will bring up a properties panel
Change "Use dynamic ports" to False
Optionally change the Port number to whatever port you want to use
And you're done.
This port number is initially assigned randomly, but Visual Studio will try to use that same port number every time the application starts.
Check out the Properties of your web application in solution explorer (Right click > Properties)
The web tab is the one you are looking for.
Kindness,
Dan
I am running VS 2008 SP1 on a pretty high-powered Win XP machine. My startup project is a web project that was written by another developer (I'm not that well versed in web development). Start Options = launch specific page, Server = default Web server, debuggers = ASP.NET.
When I push F5, my browser opens a new tab in Firefox (my default browser) - but then it takes over 3 minutes for the web page to appear! I tried "step into" instead of F5, and the first executable line of code is only hit after that same 3 minutes.
Other developers do not have this problem. There is clearly something wrong with my configuration, but I haven't the faintest idea where to start looking.
Your suggestions are most appreciated!
There were issues reported with FireFox and the VS built-in development server. It has something to do with IPv6 issue.
With me it's similar: IE/Opera do it quickly, FireFox/Safari terribly slow.
You should be able to fix it the following way:
In your FF type in the "about:config" address. Then find the setting "network.dns.disableIPv6" and set it to true. Now it should become fast.