Related
Pls don't mark it as duplicate .. bcoz I have seen all the solutions but nothing is working for my case..
I have two machines devMachine and serverMachine
in devMachine I am developing application with Visual Studio and Now I have a simple Console Application..my need is I need to run this Console Application in serverMachine and debug from devMachine via Remote Debugging.
As told in Microsoft document, I have installed Remote Debugging tool in serverMachine and set the Authentication mode as Native (No Authentication) and run the Console Application in serverMachine.
Now , I have attached the remote process in devMachine's Visual Studio. All are working fine
But only problem is breakpoint is not hitting in Visual Studio
Note: I have placed required .pdb file in serverMachine and set that .pdb file path in devMachine's Visual Studio (Tools->Option->Debugging->Symbols).
Can anyone help me to resolve this issue?
What does the error message on the breakpoints say (if you hover over the breakpoint) - that it's different from the source? --> You can try disabling (from Tools/Options/Debugging) - Enable source file to exactly match the original version
What does the Modules window say - do the PDB's appear as loaded? if not, have you tried loading them manually (from the Modules window, right click the PDB and load)? - Is there an error message if it fails?
--> you might be in a case where the source files in the local machine are different from the ones on the remote one. Try copying everything over and see if that works (PDBs would be in the same folder as the EXE)
There are two reasons for the remote debugger to not hit the breakpoint
Wrong symbols.
Using the wrong .Net framework while debugging ( you can select on the "attach to process" window in visual studio).
Don't attach and just set remote debugging on. Copy all the project files to the identically placed and named folder in the server during post-build.
I had an issue with Visual Studio not breaking at my breakpoints although it looked like everything was setup correctly for the remote debugger on an IIS machine. I searched everywhere for an answer. The issue finally presented itself when I tried to manually attach the VS debug to a process (VS menu --> Debug --> Attach to process...) For some reason, there were multiple processes for the same application pool (there should only be one process, not sure where the others came from) I logged into my IIS server and killed all the processes for my application pool and then restarted the IIS application. When I saw there was only one process for the app pool (as I expected), I tried debugging in Visual Studio and it attached to the correct process. It turns out that when there were multiple processes for the same application pool, it attached to the "wrong" one.
Looking at your screen shot, could it be simply because the break points are in the "main" function which could already have finished before you can attach the debugger?
Suggestion:
Maybe put some artificial wait/delay code of say 20 secs in "main" above the first break point to give yourself enough time to attach to the process before "main" completes.
While debugging through the code, I am getting following error.
A debugger is attached to w3wp.exe but not configured to debug this unhandled exception. To debug this exception, detach the current
debugger.
I tried the fix from the following link, but it won't work for me.
http://social.msdn.microsoft.com/Forums/vstudio/en-US/373e738f-1bc7-4dcb-88b4-ee8e78d72dc1/an-unhandled-exception-was-raised-from-microsoft-net-framework-v-10-11-or-20-but-the-current?forum=vsdebug
It works fine when I use Visual Studio 2012, but it fails when using Visual Studio 2013. I tried repairing Visual Studio 2013, but It never worked.
Do anybody know the fix for it?
Thanks.
Try This
Go to Project Properties
Debug
Change Debug type to Mixed(managed and native) from managed only for both Application and Background process.
You may be encountering this issue if you have native C code (unmanaged) and C# (managed) code in the same project.
Changing the debug type to mixed makes debugging significantly slow.
I've just had this issue and it was solved by enabling 32 bit applications on the website's App Pool, as detailed here (thanks Colm!):
http://colmprunty1.azurewebsites.net/a-debugger-is-attached-to-w3wp-exe/
Sounds like maybe you have just in time debugging turned on. Your program throws and exception that your current debugger is not configured to handle and perhaps the system is launching the just in time debugger. This is a registry setting but can also be controlled via options in Visual Studio.
http://msdn.microsoft.com/en-us/library/k8kf6y2a(v=vs.85).aspx
To disable Just-In-Time debugging by editing the registry
On the Start menu, search for and run regedit.exe
In the Registry Editor window, locate and delete the follow registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\DbgManagedDebugger
If your computer is running a 64-bit operating system, delete the following registry keys also:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\DbgManagedDebugger
Take care not to accidentally delete or change any other registry keys.
Close the Registy Editor window.
Had the same problem. Got this message all the time I wanted to start my app in debug-mode.
Turned out the problem was, that I still had appverifier (http://msdn.microsoft.com/de-de/library/windows/hardware/ff538115(v=vs.85).aspx) linked to my app. Once unlinked everything went back to normal and I could debug normally.
Not sure if anything to do with your problem. Just saying :)
Are you able to modify the source code so that it thows a meaningful exception?
Also try to recompile the source with VS 2013 and check if the debugger runs fine this time.
I can't seem to be able to debug. When I try to, I don't get any build errors, and the layout changes to debug mode, but the windows never pops up. I have an orange bar at the bottom of VS, which I think is standard, but nothing happens after that. It's not just in the project I'm working on. I have started a new WFA and tried to debug without adding any code and the same thing happens. Anybody have similar issues?
I've encountered this before. Not sure what causes it, but generally it is one of a couple of things to fix it.
make sure you are building in debug and not release
close VS, go to the project's dir and delete the obj and bin directories. Reopen in VS and rebuild.
there is an option under tools - options - build (iirc) that allows for checking if source is same as code file. However, you should see a message in output window if this is the case.
on the project properties in the build (iirc) you can throttle the pdb file from full debug symbols to no pdb at all. If you are not the only person on the project check this setting still has full pdb enabled (low probability this got changed though)
make sure you're on the right platform that you are building to (x64 vs x32)
...lots more, but a starting place...
Addendum as per comment...
So, those messages are good. It is saying there are no problems (but it sounds like you already know that :) ). I would start with the general debug options you mention. Do this on a hello world app. That way you can troubleshoot the lowest common first. Here are my settings. Try to match them and see if that works. For example, I know "ask before deleting breakpoint" is irrelevant, but "break all processes when one process breaks" is important. So, I just added them all to make it easier to troubleshoot.
ALso, make sure you are getting a red dot here like so in your code in visual studio (I've seen instances where VS won't let you put this here):
Right click on the project
Click on the properties.
go to web.
Check the Box for Enable Edit and Continue .
Hope that helps :)
This is an issue with visual studio 2012. It doesn't ALWAYS show up. I've found that if you stop your program during debugging, or if you close the console window, this will almost always trigger.
However, letting it run to completion isn't enough either, sometimes this just happens.
Also you can build your application in debug mode, go to the output, run the program, and attach to that process. :P
Amazing answers already given but they dont help in the purpose. So here is my finding, no matter if i am late in answering, but it really works for me.
Even if you are developing a web app, just go to the website properties by right-clicking the project and then you see a "Web" tab on left as i have highlighted. Then just check the box saying "Enable Edit and Continue". Thats all you need to do. it works for me!
I had a similar problem, and solution was absolutely dumb. VS was confused with two instances of Internet Explorer in “Browse with” setting. So, I set Google Chrome (any browser) as default, and then set IE as default again. It deleted the other instance of IE (only one remained) and debugging was enabled.
Hope it help!
I had a similar issue.
I added up:
using namespace std;
and this solved the problem
For me, uninstalling the Redgate's Reflector plugin that had expired fixed it. I spent more than 4 hours uninstalling, rebooting, reverting to older code, etc etc..
When my default browser was changed to CHROME, I could no longer debug my User Interface. Setting IE back to the default browser fixed it. Alternatively you can attach the process plug-in during debug.
I had the same problem with my desktop application and as this forum says you should mark your project as a startup project, since visual studio has unmarked. It worked just fine for me an I believe it will help other people that may have this problem, since I believe you have finished this project.
One of my VB .NET Winforms projects wouldn't allow debugging.
This was due to the configuration manager set to 'Release' even though the toolbar dropdown indicated 'Debug'.
You need to select the mode dropdown and select the last option 'Configuration Manager' and ensure that the main project is set to 'Debug' and not 'Release'
Install Microsoft SSDTSetup.exe 450Kb and Close the SSDT tool during install. After installation open the SSDT tool and execute the script task and Component with breakpoint. Worked for me
try checking your output without debugging
Ctrl + F5
good luck
After installing Visual Studio 2012 and opening my solution I get a series of errors in this form:
The Web Application Project Foo is configured to use IIS.
Unable to access the IIS Metabase. You do not have sufficient privilege to access IIS web sites on your machine.
I get this for each of our web applications.
Things I have tried:
Running Visual Studio as Administrator
Running aspnet_regiis.exe -ga MyUserName
Running aspnet_regiis.exe -i
These seem to be common solutions for this problem but I have not had any success with them.
Is there anything else I can try to do?
On Windows 8 Pro:
%systemroot%\inetsrv\config
On Windows 7 and 8.1 and 10
%systemroot%\System32\inetsrv\config
(Where %systemroot% is usually C:\Windows)
Navigate to the appropriate location above in Windows Explorer. You will be blocked access with a popup which says:
"You don't have access to this folder - Click continue to permanently get access to this folder"
Click 'continue' for this folder, and with the Export folder underneath. I changed the shortcut back to "Run as me" (a member of the domain and local administrators ) and was able to open and deploy the solution.
I think you are not running visual studio with administrator permissions. Look that:
http://bloggingabout.net/blogs/rick/archive/2012/10/04/unable-to-access-the-iis-metabase.aspx
To quote
The solution to this is simple: start your Visual Studio with "Run as
Administrator". You can do this by right clicking the shortcut and
selecting "Run as Administrator".
I think we encountered a similar problem at work. For us, the solution was to go into Control Panel -> Programs and Features -> Turn Windows Features on or off... inside that, we had to select Internet Information Services -> Web Management Tools -> IIS 6 Management Compatibility -> IIS Metabase and IIS 6 configuration compatibility.
Give that a try and let me know if it helps!
Note: We're running IIS 7.5 on Windows 7 using both Visual Studio 2005 and 2010 and doing stuff with super-old-school WebServices (.asmx)...
I resolved this issue by granting IIS AppPool identity permissions to the %systemroot%\inetsrv\config
If you are working on a project which does not require the use of IIS, then a workaround to open the project with this error is to simply right click on the unloaded project and click edit, search for:
<ProjectExtensions>
<VisualStudio>
<FlavorProperties GUID="">
<WebProjectProperties>
<UseIIS>True</UseIIS>
</WebProjectProperties>
</FlavorProperties>
</VisualStudio>
</ProjectExtensions>
</Project>
and set USEIIS to false
<UseIIS>False</UseIIS>
reload the project by right clicking on it after saving changes.
I have had two seperate types of problem lead to this error, and thought I'd share...
1. The directory was on an network share and due to UAC restrictions, was
unable to be accessed -- even when running as an admin.
2. The directory was on a drive that didn't exist...
Both of these stem from an unfortunate (imo) choice by MS to put things in the Documents or My Document directory, combinee with really lousy error messages. In both of the above cases the fundamental problem was that the IISExpress Config file goes in My Documents, and it either didn't exist or couldn't be accessed.
Thank you to everyone that answered. Since this was closed for a long time I couldn't provide much feedback, but I did eventually fix my problem. I tried many of these other solutions and they didn't fix my issue, but I'm sure they help when the root cause is different.
My Solution
I solved this problem by turning off the IIS and .Net Framework features within Windows 7 and then turning them back on. It seems like this re-installation is what fixed my issue. I still don't know what caused the problem, but at least one other developer on my team had the same issue.
Navigating to folder: %systemroot%\System32\inetsrv\config presents a security dialog. Click continue and this may resolve the issue. This has worked on two separate Win 10/VS 2017/IIS machines.
On a windows 81, from an admin command prompt, use:
icacls "C:\Windows\System32\inetsrv\config" /t /grant "IIS AppPool\DefaultAppPool":(R)
Then go back in VS, right click on the failed project, choose Reload.
Credit to: IIS7 Permissions Overview - ApplicationPoolIdentity
I had this problem - the symptoms were the same, but the issue I had was that I had set the "My Documents" folder to be on a network share, and the share was not accessible.
The root problem was that the IIS config files located at %USERPROFILE%\Documents are not accessible. Once I changed the "My Documents" folder location (I modified the reg value), it started working again.
I know that this may not be a common scenario that you might run into, but I've posted it here because it gives the same symptoms.
I came across this today and fixed the problem by removing the IISUrl from the Project file:
Right click project
Click Edit
Delete the following line:
<IISUrl>http://localhost:xxxxx </IISUrl>
Reload project
Now add a new IIS virtual directory by right clicking Project > Properties > Web and selecting Use Local IIS Web Server (Uncheck Use IIS Express) and clicking the Create Virtual Directory button.
You might run across this problem and have same problem as me. I "solved" it before and then power outage and computer crashed, not sure why a registry setting reverted but it is the SOURCE of my problem.
I tried all the running as adminstrator
All the IIS / IIS express re-installs.
Various "hacks"
Came down to having to fix the registry again.
Could not as administrator even open regedit (Need to access registry since problem is not with gpedit.msc admin template )
UnHookExec.inf on desktop
Just save UnHookExec.inf and install it by right clicking and selecting install. Installing the file will not show any popup or notice box.
http://www.tweakandtrick.com/2011/04/enable-regedit-registry-editor.html
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Personal pointing to non-existant fileshare. Changing that to local path solved this problem for me. – Pasi Savolainen Jul 14 '14 at 8:41
(changed from \\cs2data\home\stickelt\my documents to c:\dev )
Now ALL is good and Visual Studio opened solution with 15 projects and connects to IIS and does not complain about not being able to access iis metadata
I had never ran into this before, as nobody at current job had this problem ( many have been here a long time, some got clones of other machines that "worked" and many are on another domain etc.. )
I just had this issue today and I found that I didn't open VS as 'Run as Administrator'.
After doing this, I was able to publish the Service.
If you have administrator permissions, Right Click to Visual Studio icon > properties and then advanced, "Run as administrator" check.
You can run visaul studio as administrator directly anymore.
This way, formal and so basic.
In addition to the answer by #nologo, I also had to use IIS. So I changed the
<UseIIS>True</UseIIS>
to 'False' first.
Opened the solution and ensured that the project could be loaded.
Close solution and that instance of Visual Studio
Change the value to 'True' again
Open the solution.
This time, I didn't get any error/warning. I could also run with Ctrl+F5 or F5 without any problem while my project was mapped to an IIS website.
Changing this key worked for me:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Personal
The location didn't exist.
Go to the root directory of your project and find the following file:
YourProjectName.csproj.user - inside it, make sure UseIISExpress is set to false:
<UseIISExpress>false</UseIISExpress>
If that alone doesn't work try the following as well and try again:
YourProjectName.csproj - inside the main project file, make sure both UseIIS and UseIISExpress are set to false:
<UseIIS>True</UseIIS>
<UseIISExpress>false</UseIISExpress>
After changing these I was able to load the project again.
Note: Make sure you run your VS as an Administrator, as mentioned in the other answers.
I also had a similar problem. My solution is an extension to the answer "Run as admin" which I hope someone might find useful.
I was running VS2012 and almost every time I had to do the Right Click, Run As Administrator. I got tired of this so instead I went into its properties on the shortcut, clicked advanced, and then clicked the "Run as Administrator" option. Now VS2012 always runs as administrator whenever I open it from that shortcut.
The from that shortcut bit is important. I proceeded to branch my project, and download the branch to a new local folder. Then, when I opened it from the shortcut I had no problem. But if I went directly into the folder, and ran the project locally without the shortcut, it did not run as administrator and I got this error.
Once I opened VS2012 as usual first, then using File/Open/Project It worked again no problem. (because I was running as admin). But I wasn't running as admin when I opened the solution using windows file manager.
The other suggestions seem somewhat extreme, but this is pretty simple so I would tend to give this a try first.
Hope this was helpful.
This seems like one of those "All errors lead to this message" type of bugs.
Mine was that the App Pool was just turned off. I turned it back on, and everything worked fine.
One more thing you could try:
Check if you have pending Windows updates.
If you do, please reboot before trying anything else.
I tend to never shut down my machine, so I had plenty of them waiting for a reboot. And that fixed it.
I tried everything above. The credit goes to all of the responses above. Having tried all of the suggestions on their own, I just assembled this combination of suggestions in an order that made sense to me. Note my Documents folder is on a shared drive. The subst/IISExpress stuff is not applicable unless you're in the same boat.
Configure VS to run as admin
Uninstall IIS via Add/Remove Programs, Windows Features
Reboot
Run WinRAR or something similar as admin and archive C:\windows\system32\inetsrv\
Run cmd as admin and rmdir /s c:\windows\system32\inetsrv\ to completely remove all traces of the last install. Leave elevated cmd prompt open for later.
Reinstall IIS with IIS 6 Metabase compatibility (doubt this was necessary)
Leave Default AppPool and Default Website as-is (I had previously deleted both)
Ran C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -ga MYDOMAIN\scottt732
Ran C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -i
Also, because my Documents folder is on a share drive, I was having IIS Express issues. I don't use/like IIS Express, but Visual Studio complained about it.
From elevated cmd prompt, ran subst U: c:\Temp. Created C:\Temp\Documents\ and copied the IISExpress folder from my U drive.
Created CustomUserHome key in HKCU\Software\Microsoft\IISExpress with C:\Temp\Documents\IISExpress
This allowed me to get Visual Studio to open my web projects and edit the properties. I tweaked the projects to store web server settings in a user file and adjusted it to use a Custom URL (not sure if this was necessary)
I may/may not have to run the subst command each time I restart. Don't care.
And after throwing in the towel 3 times and spending roughly ~6 hours I can open web projects in Visual Studio (2015 Update 2).
I just had the same issue with me today. And I found it annoying. Though I have other two websites already under development from the same IIS but still was not able to create new site. Strange, but I did this.
Delete the site from IIS
Create new site, give it a name "new_site"
Select Application Pool other than the site name itself. So it wont be messing up with default settings.
Keep IP "unassigned" if you are running it from same machine
give it some unused port
Run Visual Studio as "Run as Administrator" by right-clicking on VS executable shortcut.
You are done!
You do not need to turn off/re-install anything other than what I have stated since it works.
Let me know if anybody had the same issue just like me and solved the same way. I think it was not the issue but a wrong way of creating website on localhost which Visual Studio rejects to open.
I hope this will help newbies.
Create a shortcut to the "devenv.exe"
select the "Run as administrator" option for the shortcut
doble click on the short cut and reopen your project
I had the same problem after Adding feature from this link afterward I followed this article the issue was gone.
I did a repair of Visual Studio 2015 to solve this.
The repair took a long time, but it solved the issue while doing much of the above did not. I am running Win 7 enterprise.
Open visual studio command prompt and type below command and run
aspnet_regiis -ga machinename\ASPNET
After running the above command Reset the IIS and test the application that resolve your issue.
If above command doesn’t resolve your problem then try to run below command in visual studio command prompt:-
aspnet_regiis -i
Alternatively we can run above command from our windows command prompt also
Go to the Start menu and open Run and enter and click OK
%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe –I
After that Reset the IIS and test the application that resolves your issue
In Visual Studio 2015:
I changed UseIIS in .csproj file to false and it worked for me.
<UseIIS>False</UseIIS>
In my message, beside complaining about "Unable to access the IIS metabase", it also mentions can't access "<IISUrl>http://localhost:6416/</IISUrl>". Right click on the unload project, click Edit, find the line "<IISUrl>http://localhost:6416/</IISUrl>", comment it out. Reload and it should work. This has to do with administrator doesn't have permission to access that address.
I had a similar problem. Visual Studio would not load any web projects and showed the error: creation of virtual directory <myproj:myport> failed. Unable to access the IIS metabase.
In my case it was actually IISExpress that was at the root of the problem. Right clicking on IIS Express in Programs and Features in the control panel and choosing repair fixed the issue in less than two minutes.
I'm using Win 8 Pro and VS 2013.
After trying everything in this page... I simply reinstalled IIS Express 8 and everything works fine now (even without running as an admin).
My conclusion is that this is a rather generic error and there are multiple root causes.
I'm working on a moderately sized WebForms project. Due to the peculiarities of management here, I have to upload the site to a remote server in order to test (no localhost testing). I'm using the 'Publish' command in Visual Studio 2008. Sometimes, it even works. Most of the time, I inexplicably get a "publish failed" in the bottom left corner, with no further details.
The few googled articles/forum posts I read suggested making the target local folder for the publish operation readable/writable for everyone. Doesn't help.
Is there are way to get further details as to WHY a publish fails in VS2008, and if not, is there a better way of doing these deployments? I'm spending more time building/pushing to the web server than actually debugging.
It's worth checking the output window. I've just had a publish fail because I had deleted an image outside of VS so VS was complaining that the image couldn't be found, but this information was only displayed in the output window.
See this link for more information:
http://ericfickes.com/2009/08/find-out-why-visual-studios-publish-fails/
It happens to us when there is an error in markup (!). Bad thing is that VS will just swallow the error and just tell you Failed.
What I suggest is to run your publish from command line using MSBuild. It's not that straightforward but it works (once you get into it).
I've since discovered that the reason for these particular publish failures was due the "Delete Existing Files" option being checked. Using Visual Studio 2008 under a non-administrative account on Windows Vista could cause a permissions error while attempting to delete the existing files. The publish would fail silently after encountering a file that Visual Studio had insufficient access to delete. Once the files were deleted manually outside of Vidual Studio, the publish functioned normally.
I have not had this issue with Windows 7; I assume the UAC changes in Windows 7 fixed the problem.
I mostly work with Web Forms, and I encounter this problem daily.
It seems to me that publish fails when it fails to delete a file it is trying to replace. Even if I don't have any files open, it still fails sometimes. Not sure why.
Not only VS publish fails very often, it is painfully slow as well.
I just publish to empty local directory and use separate FTP client to upload files. It's more work, but works.
This is probably not the case for you, but I've seen this happen when I'm publishing a web site. If the app_offline.htm file is not excluded from your project (if you use this file), the publish will fail.
Same happened to me.. what I did was include images files that was not included in the project and delete images that were not used.
After struggling with a similar issue for about 30 mins with no clue as to what was causing it closed down VS and reopened my project. Started working fine. No idea why but it worked.
You should always stop the IIS instance running on the machine your are publishing to. Google the word "iisreset". Other hosting providers like DiscountAsp and Arvixe offer you tools to "Stop" and "Start" your app pool on their IIS remotely. This is very necessary because IIS may have locked some files as "in use", so your publish fails when it tries to write over them. When your publish is complete, then just restart IIS (or press "Start" from a web tool if you're using a 3rd party hosting provider).
When all else fails, check your "Output" window (the tab to the right of your "Error List" at the bottom of Visual Studio). Scroll through all of it after a failed publish and look for anything that says "Unable to add". If you keep seeing the same "Unable to add" errors on the same publish, then ftp into the folder, delete the the problematic files manually, and try publishing again.
I got this when my ProjectName.Publish.xml file was read-only. Once I checked the file out of source control, I no longer got the error and could publish.
Just to add to this thread, I found that, for some bizarre reason, only the Mercurial files were being published to the server, everything else just wasn't being copied across.
Another strange thing was that only the Debug configuration was available; Release was nowhere to be seen.
After reading other threads around S.O., I found that there were many for VS 2010 and 2012, but not much to cover the same problem with 2008.
The fix, I found, was to delete the [solution].suo file and then attempt a publish. That seemed to do the job, though it took a long time to complete.
What I found and work in my case. It is to use a different version of VS.
I recently had the problem, the solution works perfectly in VS2015 build, compile and tested.
However, when I try to publish was failing silently.
So, I closed the solution and open it with VS2017 that use the same file structure for the projects/solutions. Then rebuild it and publish without any problems.
I believe it could be VS related and it is complicated to debug.
This is a workaround if you work with multiple Vs instances in your local machine.