(Unable to start debugging on the web server. An error occurred that usually indicates a corrupt installation. If the problem persists, repair Visual Studio installation via ‘Add or Remove Programs’ in Control Panel) I saw this happening on a Vista x64 while trying to debug an ASP.NET application and needless to say (☹️), repairing Visual Studio does not help. This is a misleading error message which might appear when you try to debug an ASP.NET application on a 64 bit OS and you configured your application pool to run a 32 bit worker process; I know it will be changed to a more meaningful message, but I’m not sure about the timeframe (I can’t repro so I’m not able to check how Visual Studio 2008 behaves). What to do then? Check the advanced settings for your application pool and set “Enable 32-bit applications” to “False” By the way, I was this error in conjunction with this one so pay attention if you’re hitting one of the two… Carlo Quote of the Day: Sincerity is the highest compliment you can pay. –Ralph Waldo Emerson
-
-
The error indicates that IIS is not installed on the machine. Please install IIS before using this tool
Yesterday I was working on a sample project got from a customer, when Visual Studio 2005 showed this dialog: Ok I thought, let’s fix the application mappings. I did, but got the following: What? Are you kidding me? ? Of course IIS is installed, I’m using it every day… But wait a minute, I’m running on Vista x64 and this rings a bell to me… Let’s use the x64 Visual Studio command prompt and give it another try: Much better… and now Visual Studio does not complain anymore! ? Carlo Quote of the day: We are inclined to believe those whom we do not know because they have never deceived us. – Samuel Johnson
-
Visual Studio designer, CodeDom and InitializeComponent()
The code problem A few days ago I had the chance to work on a case not concerning ASP.NET or IIS, but rather an interaction with Visual Studio designer with classes from System.CodeDom namespace. The customer was developing a custom control meant for other developers to use it in their projects, and upon adding the control to the form, the former had to automatically modify the some codebehind files for example to add some custom methods and register itself in the InitializeComponent method to add events etc… The problem was that we were able to add new methods to the form, but despite our attempts nothing was added to InitializeComponent ? Here’s the chunk of code we were using: private void AddCode(Form form) { IDesignerHost host = null; host = (IDesignerHost)form.Site.GetService(typeof(IDesignerHost)); //Add method "Form1_Load" on Form1 //--------------------------------------------------------------------------- CodeMemberMethod member = new CodeMemberMethod(); member.Name = "Form1_Load"; member.Parameters.Add(new CodeParameterDeclarationExpression("System.Object", "sender")); member.Parameters.Add(new CodeParameterDeclarationExpression("System.EventArgs", "e")); CodeSnippetExpression sn; sn = new CodeSnippetExpression("MessageBox.Show(\"Hello world\")"); member.Statements.Add(sn); member.Attributes = MemberAttributes.Private; CodeTypeDeclaration typedecl = (CodeTypeDeclaration)form.Site.GetService(typeof(CodeTypeDeclaration)); typedecl.Members.Add(member); //--------------------------------------------------------------------------- //This code will add the following line to the "InitializeMethod" method // this.Load += new System.EventHandler(this.Form1_Load); //--------------------------------------------------------------------------- member = new CodeMemberMethod(); foreach (CodeTypeMember typememb in typedecl.Members) { if (typememb.Name == "InitializeComponent") {…
-
My goodness, were’s gone my Properties window?!?
I had a funny half-hour this afternoon, when one of my colleagues took a new call from a customer whom had some troubles with the Properties window in his Visual Studio 2005… The customer reported a weird behavior within the Visual Studio IDE in particular with the Properties window, which was not available despite his attempts to display it both pressing the F4 keyboard shortcut and from the View > Properties Window menu command. Moreover this had the effect to remove the focus from the Visual Studio IDE but apparently nothing else was getting it, and there was a weird Format menu appearing and disappearing… ? It was kind of fun to see Stefano on the phone with the customer, listening to his description and his face getting more and more puzzled… ? Until after some quick research in our internal docs he found a reference to a similar problem, and after a quick test he triumphally called the customer back with the solution after just 20 minutes! ? As I guess you know the Properties window (like other windows in Visual Studio) can be detached from the IDE and left float around the screen; the point here was that…
-
Visual Studio as the definitive text editor?
That’s a clever question and I have to admit I’ve never thought to Visual Studio in this way, even if I tried different text editors and I still have more than one on my machine (Notepad2, Notepad++, PSPad). Anyway, while you thing about it take a few moments to leave a comment on Noha’s post to express your opinion and request features you are missing to turn Visual Studio into the editor for you ? Carlo Quote of the Day: What single ability do we all have? The ability to change. –George Leonard Andrews
-
Quickly arrange icons on your toolbars
This is a trick I learnt a few years ago in Office (don’t remember exactly if was 97 or 2000 ?) since I like to customize my working environment “in my way” (like everyone else, I guess ?), but I don’t like to waste time digging into menus, config files etc if possible… It’s easy: hold the ALT key and simply…: Drag the button to move it in the position you like, also in a different toolbar Slightly drag the button to the right to insert a vertical separator on the left of the icon you are touching Slightly drag the button on the left to insert a vertical separator on the right of the icon you are touching Drag the button down (outside the toolbar) to remove it Of course this works only for icons and button you already have on the toolbar, if you need to add a new one you must do it the usual way (right click on the toolbar and chose the “Customize” command). Oh, this does not work with the Ribbon in Office 2007. Carlo
-
Visual Studio debugger conflicts on port 80
I personally got this problem on my laptop a while ago where IIS and Skype where involved, and even if this time the customer reported two different applications involved (Visual Studio 2005 and Cisco IP Communicator), the symptoms where the same: with Visual Studio 2005 and Cisco IP Communicator running ad the same time, he was unable to debug his web application with the message “Unable to start debugging on the web server. Could not start ASP.NET or ATL Server debugging. Verify that ASP.NET or ATL Server is correctly installed on the server“. If he stopped the IP Communicator the problem went away; clearly a conflict between IIS and Cisco Communicator. Just to be sure we had a look at “netstat -a -b”, and found (as expected) that both applications were listening on the HTTP port TCP computername:http computername.domain.com:0 LISTENING 492 [inetinfo.exe] TCP computername:http computername.domain.com:0 LISTENING 3872 [Communicator.exe] Since I don’t know how Cisco IP Communicator works (and we can’t support third party apps anyway), we decided to change the IIS port to 81, but this time the customer was getting “Unable to start debugging on the web server. Unable to connect to the web server. Verify that the web…
-
Debugger not debugging, and Response.Redirect() not redirecting…
The customer was working on a WinXP machine joined to a domain, but had logged in using a local account (I’ve not tested if this may have contributed to the problem so this may be a useless information). Anyway to make things easy I connected to the faulting machine using EasyAssist to have a better look at the configuration: everything looked fine both in IIS and Visual Studio. Interestingly browsing the application from IE directly we found that even if he was using “http://localhost/app” the page was shown in the “Internet” zone (hence the debugger error). This usually happens when the application is created using either the IP address or the FQDN (Fully Qualified Domain Name) of the web server; to verify, we created a new test project as “http://localhost/test” but got the same debugging problem, and again the page belongs to the Internet zone. As a test we enabled “Automatic logon with current username and password” for the Internet zone and then the debugging started working fine. Talking about this with my team colleagues they suggested uncheck “Automatically detect intranet network” in the “Local Intranet” settings and enable the three remaining checkboxes; this because under some circumstances IE may…
-
Compiler Error Message: CS0433 in ASP.NET 2.0
A few days ago a friend of mine had the Compiler Error Message: CS0433 error in his precompiled site, and proposed me a deal: a dinner for my help 😊, and since also Support Engineers sometimes need to eat, I accepted 😉. The exact error message was the following: The type <typename> esists in both <path 1> and <path 2>. Sometimes the error message is quite self explanatory, especially if one of the two assemblies is in BIN and the other is in the GAC (remove the one in the BIN, you don’t need two copies of the same file!), but my friend was getting the following one: Exception information: Exception type: HttpCompileException Exception message: c:\WINNT\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\customers\30216428\89bd3cad\App_Web_default.aspx.27046288.rpug8fan.0.cs(112): error CS0433: The type ‘App_Items_63_pgs_default’ exists in both ‘c:\WINNT\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\customers\30216428\89bd3cad\assembly\dl3\d1307a39\42cbc228_01a6c701\App_Web_tzn10d4k.DLL’ and ‘c:\WINNT\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\customers\30216428\89bd3cad\assembly\dl3\5493a6b9\8880bf21_01a6c701\App_Web_7jlq-fy_.DLL’ Thread information: Thread ID: 1 Thread account name: <server>\ASPNET Is impersonating: False Stack trace: at System.Web.Compilation.AssemblyBuilder.Compile() at System.Web.Compilation.BuildProvidersCompiler.PerformBuild() at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath) at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath virtualPath, HttpContext context, Boolean allowCrossApp, Boolean noAssert) at System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp, Boolean noAssert) at System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath…
-
Are you profiling your application and now you can’t debug anymore?
This is an interesting case I got very recently and that made me scratch my head a lot, wondering what was going wrong on customer’s machine for a while… until I called Doug on the rescue and we (he) drove the call to an happy ending 😊 I got this case from a colleague on the Visual Studio team; the customer reported a weird problem with the debugging of their ASP.NET 1.1 application (with Visual Studio 2003): when trying to step into the code line by line with F11, the debugger actually stopped only on the signature of every method skipping completely the body of the method, and to add something more, this happened only when they were using a specific namespace (e.g. MyCompany.MyNamespace.Group); if they used the same exact code but in a different namespace, everything worked fine 😲. Moreover, this was happening on that very specific web server only, if they moved the code to another machine the debugger worked like charm (but moving to a different machine was not an option for them). My first thought went to the .pdb files, some kind of mismatch between the between the code esecuted in memory and the symbols used…