Do you do local development/debugging with the internal webserver or a local iis install? I'm currently running the internal VS2010 webserver but it's so slow it hurts. I can see the page rendering in front of me...
I prefer to use Windows Server 2008 as my development machine so that I can use IIS 7 as the web server and just set the default location of the website to a locally mapped DNS name. This especially helps when testing code that is dependent on domain URIs and other information of that nature.
One problem I have experienced is an intermittence in the ability of studio to bind the debugger to the IIS processes. (sometimes a reboot is required to get studio to bind if this happens)
Related
I have a solution that contains multiple projects, two of which are web applications that have their own separate domains. I have this published successfully to my dev/production environment fine and now would like to mirror these settings across to my local machine for better testing.
I have configured the project to run under Local IIS and enter the required Url for both projects and hit debug, I'm then presented with the following error:
Unable to start debugging on the web server.
Invalid access to memory location.
Interestingly if I change my IIS configuration and remove the hostname and change the port to 81/82 (and reflect these changes in VS) then I can successfully start debugging my application.
This is more of an irritation than anything else as I can work without the custom hostnames and configure the rest of IIS perfectly, however this does get in the way of logging into both systems simultaneously.
I tried a number of recommended fixes such as:
Ensured app pool is running
Restarted Visual Studio
Restarted computer
Run VS as Administrator
I have a multi site Azure based web application. One site contains the web pages (with the view functionality driven through jQuery, Raphaël, and HTML) and a thin WCF service. The second site contains a more functional WCF service which in turn calls the data objects that call the database. We stopped development on the site a few years ago but it is still live for the few people who still enjoy using it.
Yesterday I had to fix an cross-site scripting vulnerability someone had reported on the site.
I was alarmed to find that I can no longer run the sites on my local machine under Visual Studio to test and debug any changes before deploying them to Azure.
Because of the interaction between the two WCF sites I had the local debugging set up as follows:
In the Internet Information Services Manager tool (InetMgr) I add additional websites with their physical path set to the location of the source code in the TFS local path on my machine.
I edit the host name in the site's binding to mimic the Azure location, i.e. the main site is projname.cloudapp.net:80 on Azure and projnamelocal.cloudapp.net:80 in my local IIS and the data WCF site is projname-wcf.cloudapp.net:8080 on Azure and projname-wcflocal.cloudapp.net:8080 in my local IIS. (N.B. The main site has a HTTPS binding too.)
I edit C:\Windows\System32\drivers\etc\hosts to include the lines
127.0.0.1 projnamelocal.cloudapp.net
127.0.0.1 projname-wcflocal.cloudapp.net
In Visual Studio I edit the web properties for the main site's project so that it uses the local IIS and project URL http://projname.cloudapp.net/ and I have a switch (in the code to say whether to call the local WCF or the live Azure one.
In the past when the project was under active development this set-up worked fine for locally testing and debugging. Yesterday it failed, one one machine http://projnamelocal.cloudapp.net/ gave a 503 error on another a 404. (N.B. I can ping each URL from the command line so the hosts redirect is working.) Visual Studio complains that it is "unable to start debugging on the web server" and that it "could not start ASP.NET debugging".
I've tried all the suggestions and some:
Running without debugging
Running Visual Studio as administrator (I was already)
Re-registering ASP
Changing the app pool
Giving everyone full permissions to the code directory
Running as my own domain account that is an admin on the local machine
Changing IE to not auto-detect proxies
Adding the sites to IE's list of trusted sites
Turning off IE's protected mode
Restarting Visual Studio
Restarting the PC
Restarting the PC again
How should I set-up this style of running, testing, and debugging local sites work in IIS under Visual Studio?
Got it.
I had forgotten to go to Control Panel > Programs > Turn Windows features on or off > .Net Framework 4.5 Advanced Services > WCF Services > HTTP Activation
Now that I have that installed the local sites start
Does anyone have any experience with creating URL rewrites in Webmatrix? Because it uses IIS Express instead of IIS 7, there's nowhere for me to create these rules.
I am deploying to IIS 7 on my production server, so if I need to do any rewrites, I need to make them directly in production to test.
Is there any way I can switch to using IIS instead of IIS Express on my local machine?
I have tried a few things to get local IIS working, but to no avail.
You can install IIS on a Windows 7 or Windows 8 machine by going to Control Panel -> Programs and Features -> Turn Windows features on or off. Make sure to install enough of the components to get a WebMatrix site working - ASP.NET & the management console for certain.
You can then create a virtual server for the directory your project is in and use the IIS management console to play around with URL rewriting. You may need to install the UrlRewrite module using the MS Web Platform Installer, available here:
http://www.microsoft.com/web/downloads/platform.aspx
If you need more help getting your local IIS working, give me some more information on how far you've got and I'll try and extend my answer.
I'm running Visual Studio 2010 and IIS 7.5
My site accesses a specified servers hardware for some statistical analysis.
When I debug my site in Visual Studio, I can access other servers hardware information with now issue. When I publish the site to IIS running as ASP.Net 4.0 appPool because the site is written under the 4.0 framework, the hardware retrieval fails. (note: when I run the site and analyze the local machine hardware, it works perfectly... the problem lies in analyzing another machine on the network.)
My question is, What is the difference in permissions a site is running under when debugging in Visual Studio in comparison to a published site in IIS 7.5?
Things I've tried...
Changing the app pool identity to every possible built in option, and my own domain profile, which is local admin on the machine I'm trying to retrieve hardware info about.
Changing the user that access the file directory of the website.
Changing app pools period. (The site has to run under .net 4.0, or else it barks out bad things).
I'm thinking I may need to install the site directly on the server that's being analyzed, but I find it odd that I can get all the data from other machine when I'm debugging. Any insight someone could bring would be greatly appreciated. Thanks!!
This answer is, in some cases, you have to add the appPool identity running the site to the "Performance Monitoring" group for the local machine in order to allow an ASP.NET site access the server's local hardware resources...
Wondering if I should stick with testing on my local IIS install or just use the Express version. Any reason why or why not?
generally, I would try to have the development / testing environment resemble your live environment as closely as possible.
so if you're using IIS in production, I'd recommend using it in development also.
I cannot tell you how many times I've seen web apps working perfectly on the development machine using IIS6, and crashing completely on IIS7.
I suggest this configuration:
IIS Express on the developer machine
same IIS as in production on a staging machine
IIS Express is the best choiche on your local computer because it's easy and fast to install and configure and doesn't require administrative rights to be installed.
It's completely integrated with Visual Studio and it has all the functionality of IIS.
And the configuration is in the source code repository so each developer can checkout the solution and is able to run it with minimal effort.
As sJhonny suggests is recommended to have an environment closer as possible to the production environment.
The best way is to have a staging server with the same software configuration of the production server, in your case with the same IIS complete version (it's enough a virtual machine).