I am unable to debug a WASM project in VS 2022, v17.3.6 do to unbound breakpoints. The breakpoints look fine when not running but become an empty circle with the warning sign inside when running the project. The message is “The breakpoint will not currently be hit. Unbound breakpoint”. Other projects within the same solution can be debugged. Three developers on the team have this issue, one does not. All are now on the same version of VS. We tried a slightly older version of VS 2022 (v17.3.4) and it also had this problem.
Below are several ways I tried to fix the problem using many of the suggestions from other posts.
Cleaned the solution, restarted machine, restarted VS
Changed debug settings in Tools-Options-Debugging-Symbols to
checked Microsoft Symbol Servers
checked NuGet.org Symbol Server
Load all symbols
verified launchsettings.json for this setting: "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}"
Blazor WASM doesn't hit breakpoint
verified debug properties of the projects - Build-General-“Debug Symbols, portable across platforms”
Added code to delay the project start until everything is built
VS 2022 17.1.3 The breakpoint will not currently be hit
https://learn.microsoft.com/en-us/aspnet/core/blazor/debug?view=aspnetcore-5.0&tabs=visual-studio#breakpoints-in-oninitializedasync-not-hit-1
Verified https://stackoverflow.com/a/66808469
Deleted .vs folder for the solution, restarted machine, restarted VS
The solution in this case had to do with HTTPS. The developers exhibiting the problem (well, 2 out of 3 of them) have a persistent problem when they launch the app, where ASPNET pops up wanting to install a development certificate. They click yes, and it pops up and says it was unsuccessful. This is annoying but otherwise not something the devs worry about since it's been an ongoing annoyance for months if not years.
We tried many things to troubleshoot the problem, including creating a new Blazor WebAssembly project on the machine that couldn't debug. We were able to debug the brand new project! Upon closer examination, we saw that it was created with no authentication. Creating a second project with Individual User Accounts exhibited the same behavior as the production app - breakpoints could not be bound. While tearing apart the code in the non-working new project (with auth) we finally looked at the two launchSettings.json files and found that one of them had two application URLs (https://localhost:XXXX;http://localhost:XXXY), while the other had only the http URL. We deleted the https URL and suddenly the project could be debugged (and the annoying cert popup disappeared, naturally).
We made the same change in the production solution, removing the https application url, and we were able to debug once more. This fixed all three team members who had been unable to debug. Troubleshooting this issue took at least a dozen developer hours and slowed development for several calendar weeks while the team worked around it, so hopefully this helps someone else with the same issue.
I've had the same problem, breakpoint wasn't being hit when I was using 'dotnet watch' launch profile. I was able to start debugging after changing the launch profile back to the launch profile with a commandName: 'Project'.
Related
I am having some problems with my production asp.net v4.5.2 website when I add new dlls. I am developing on a standalone laptop with Visual Studio 2017 and I just added some telerik document processing library functions that need the PresentationCore and PresentationFramework dlls. On my development machine there was no problem, added the "add assembly" line to my web.config and added the reference in Visual Studio and it worked fine. I added the dlls to the bin folder on the production environment (2008r2 IIS 7.0), uploaded the new code and modified that web.config accordingly now it works but my users are randomly having controls and pictures not load and getting kicked out of the website with a 403 access is forbidden error. The users get kicked out after going through CAC authentication (production is a military server). Sometimes it's right after they login (CAC authenticate) sometimes there a few minutes into doing stuff and then bam, a control doesn't load or the 403 error pops. This happens in both Chrome and IE. The controls or pictures not loading generally are fixed with a refresh (not always though) but the 403 error the users have to reboot their machine to fix. I've even had them clear the browsing data (cache, cookies and ssl state) but they still have to reboot.
When I take those dlls out of the bin folder the problems go away. Google seems to always point to Visual Studio answers and the closest things I found here are adding custom .dll class library to asp.net/C# website and How do references work in ASP.NET WebForms websites (not web applications)? Which didn't help. I think you should also know that I have 2.5 years experience in professional coding and system administration and I am the Lead/Senior (and only) developer and the Sys Admin for this project, please use small words for me. Thanks for any help you can provide.
I figure out what was happening and it wasn't the dlls. Turns out the I was missing a CSS file which caused 404 errors and when enough of those piled up the web app would crash or IIS would give a 403 error. I found this by looking at the event logs for IIS on our production test site. It was so hard to find because that CSS was for 1 particular control and if you didn't navigate to the page with that control enough times it worked fine. I thought it was the dlls because I just added functionality to that control that required them and without that functionality the control was not used as much and so wasn't loaded enough times to cause the error.
Not sure why Visual Studio didn't say anything about the missing file but once I removed the call for that CSS file everything worked as expected. I took over this particular code recently and no other place in code are there custom CSS files so I never noticed the call for it. Luckily IIS is set to log everything.
I am using IIS 7.5; Visual Studio Community 2015; The website is MVC. Framework 3.5
This is the first MVC website I've worked on. After downloading the source from the repo I get this error when trying to debug. "Unable to start debugging on the web server. Could not start ASP.NET debugging. More information may be available by starting the project without debugging."
Research into this error has pointed to path redirects in the config file, of which there are none in the project.
Running the project without debugging results in
"404.17 - Not Found: The requested content appears to be script and
will not be served by the static file handler."
Which I believe to be a byproduct of the MVC format, but I've tried multiple variations of the url and none worked, some with 404.17 and some with 404.0.
I've tried moving the project to framework 4.0, which my tutorial on MVC used, but that caused a large number of dependency issues, so I'm abandoning that path for the time being.
What I have been able to do is make changes and publish them to a new test site on the production server. So I know the code is good, for a certain value of good. But I'd like to step through, see values, and have a shorter debugging turn around.
What other steps can I take to allow visual studio to debug this project properly?
I have a website in C# Visual Studio 2013, which was developed by another developer and is hosted on Azure cloud service. Whenever I make any changes and try to publish, Visual Studio hangs and I can't publish it. It is not showing any error message. Besides that I can successfully deploy it by building it, but as it's taking too much time and also costs money to client (as VS Team Services only provides monthly 60 minutes of free build, after that clients get charged for extra minutes). I am using following steps for publishing and it's works fine but after publishing starts Visual Studio hangs and is unresponsive.
The steps to publish the website are as follows:
1) Open the solution in visual studio.
2) Right click on the azure project in the solution explorer, and select publish.
3) The first step in the wizard is to sign in, make sure to select your credentials.
4) The next step is settings, make sure environment is set to production and build configuration is set to release, then click next.
5) The final step is a summary, simply click the publish button.
I am very new to Azure so let me know if I need to make any setting during set up my project.
I hit the same problem after installing the 2.8 SDK and tools. After checking out these answers I still had the problem, but found a solution.
Right click the Azure project in the VS2013 solution explorer, open project properties. Go to the application tab, and there's an "Upgrade" button to upgrade the project to the latest SDK. That did the trick for me.
It sounds like you are doing the right steps to deploy using the wizard. However I don't have enough information to know what would cause this to hang. There are some documentation details about the wizard that might help? https://msdn.microsoft.com/en-us/library/azure/hh535756.aspx
There are other ways to deploy to Azure, which may solve the issue. You can for example download a publish settings profile, and use this to deploy instead of the wizard. Details here: http://blogs.msdn.com/b/avkashchauhan/archive/2012/05/10/downloading-windows-azure-publish-settings-subscription-configuration-file.aspx
Or you can deploy continuously from Git - https://azure.microsoft.com/en-us/documentation/articles/web-sites-publish-source-control/#Step75
Both solutions will require some tinkering in the Azure portal or getting in with PowerShell but there's a lot of ways to deploy.
Doing these two things fixed it for me, not sure which:
Clean build
Server Explorer > (Had to re-enter Azure credentials)
VS2013 update 5.
A related post found here..
https://social.technet.microsoft.com/Forums/virtualization/en-US/4e51b1f0-91c3-4ce9-9a15-a8d10f912c5b/publish-cloud-service-causes-visual-studio-2013-to-hang-crash?forum=windowsazuredevelopment
One user was able to get past the publish freezing by doing the following..
So I did a line-by-line comparison between all of the files in that
new project and everything in my existing one and found only two
possible things wrong:
1) The version stamps (dates, really) in my
files were not upgraded to reflect the latest version of the Azure
tools. I manually changed those in my existing project to match the
garbage test project's date stamps.
2) My XML files had some empty
sections that did not exist in the new project's files, so I simply
removed those empty sections.
3) Beyond that, I also deleted my *.user
file.
Specifically, I was able to remove schemaVersion="2014-06.2.4" from my ServiceConfiguration and ServiceDefinition files and it fixed the issue.
My guess is that your installed sdk version is different than the specified schemaversion.
I tried all above methods none worked for me. So this is for people who already tried above and still couldn't make it work.
=> Publish in Release mode :-)
Yes I was trying to publish in Debug mode which was causing it to hang till death ;-)
I'm working on an ASP.NET Web Forms application (.NET 4.0 VS 2010). Lately we've been experiencing problems which have halted our release process.
Specifically, we have found ourselves unable to publish our website (to precompile it). Across all of our developer environments (3 developers), the build process appears to be stalling/hanging - without any report of error. Sometimes, it appears to succeed but only a couple of the compiled DLL's and .compiled files appear (less than 10 out of ~350 files).
I've loaded in various revisions of our projects from our source repository, both latest and very old versions which previously worked. The fact that it's happening across developer environments suggested that the problem was due to some change we committed, but the fact that the problem is occurring across latest and old revisions of the application perhaps suggest otherwise.
Internet searches for this issue reveal nothing significant. Things I've tried include the following:
Building and rebuilding
Clean solution
Deleting the .suo files for the solution
Deleting the contents of the ASP.NET Temporary Files solution and deleting the target location folder prior to publishing
Tried selecting the 'Allow this precompiled site to be updateable' option (produces an object reference error without a file or line number)
Restarting Visual Studio and PC
On examination of CPU usage during the build, the CPU usage for the devenv.exe process is in the sub 0.10% area for most of it (a few spikes at the beginning just).
I appreciate any assistance anyone can provide with this
UPDATE: We have found that eventually, the publish succeeds, but sometimes we get a long series of failures before it succeeds. There's no consistency at all... it seems random.
I had this same issue with Visual Studio 2015 on Server 2016. The issue was partially resolved by running VS as administrator. However the apparent root cause was virus scan - in this case ESET- installed not as a File Security but as workstation. This I discovered when every entry of the license codes for ESET appeared to work - then ESET reported it still required verification. Uninstalled the badly chosen ESET and reinstalled the correct license product and, presto, with or without pre-completion, the publish works! Thanks to the previous virus scan tip!
The issue seems to have been caused by the McAfee virus-scanning software that we have installed.
Only with admin privileges, we were able to temporarily disable the real-time scanning, and as soon as we done that the ASP.NET Publish would complete successfully almost instantly.
For anyone else in this situation, it was McAfee's anti-virus software that was causing the problem. I checked the logs for the anti-virus software and there was no evidence that the software was blocking anything related to the Visual Studio processes or the folders that are manipulated during the build and publish processes (e.g. The ASP.NET temporary files folder).
Specifically, the csc.exe (C# compiler) and devenv.exe (Visual Studio) processes were having problems with McAfee. These processes were added as 'Low-Risk Processes' to the 'On-Access Scanner' to resolve the problem.
McAffee removes any changes to it's settings every 15 minutes, meaning that the action of adding these processes to the McAfee exception list (low-risk processes) has to be repeated every 15 minutes when you are building your code. This could happen a lot during a working day.
I see you do not have Allow this precompiled site to be updatable checked, so your Publish may be attempting to update what it thinks has changed.
Try deleting all the files (copy existing files to a new location or rename the folder, if you want), and try your Publish again.
During our adventures of building a 'simple' API using WebAPI we've had our fair share of issues as any project does, however I am unable to find any such resource that can explain the following behavior:
Details :
Visual Studio 2013 with Update 2 (however, before updating, this was the same)
Windows Server 2008 R2
Web API 5.1.2
The issue seems to be related to the "Publish" command, specifically the "Precompile" option.
When running via IIS Express, we see no issues at all.
If we publish once, it fails to include the App_Global.asax.compiled & App_Global.asax.dll in the bin directory. If it is updating an existing instance of the application, it will actually delete the existing two files.
Note: This Happens regardless of WebPublish or FileSystem Publish
This behavior is causing 404.0 Errors upon loading to IIS, instead of our expected 201.
However, if I publish a second time no changes to the previous profile/configuration, it adds the two back.
For a while, we thought it was permissions issues, and weren't seeing consistent behavior. This happens on all of our development machines with the same behavior.
We've seen posts regarding mysterious behavior, but from our analysis, this is the root of the problem.
Just wanted to let everyone know that my problem was solved.
This was an issue with a virus scanner scanning the newly created temp directory for precompiling and actually locking the files in question.
So if anyone has issues such as this and is running any antivirus (especially enterprise level):
TLDR:
Check if your antivirus is locking files.
Turn off all compsec scanning utilities and turn on one by one to isolate which is causing problems.