I have an ASP.NET webforms app that is consuming a third party service via a WCF service proxy that I created in Visual Studio 2010 with the Add Service Reference command.
I have added several public methods to the generated Client class in a separate partial class definition so that they persist even if I regenerate the proxy. These methods are what the rest of my code calls instead of directly calling the proxy methods that map to the api calls.
The problem I run into is when I need to debug the methods I have added. When I place a breakpoint in one of the methods I created and then attempt to Step Over or Step Into the code, Visual Studio hangs for some time and then returns with the following error:
Unable to automatically step into the server. Connecting to the server machine '[address of service]' failed. The debugger cannot connect to the remote computer. This may be because the remote computer does not exist or a firewall may be preventing communication to the remote computer. Please see Help for assistance.
After this error occurs Visual Studio automatically Steps Out of the method I was debugging, preventing me from debugging my client-side code.
Visual Studio is attempting to connect to the remote 3rd party service to try and debug it. However, I have no control over this service and will never have access to let it do this.
Is there any way to tell Visual Studio to not attempt to debug this remote service and just debug the client-side code?
UPDATE
I was looking at the code of the generated Client, and I saw that it has the DebuggerStepThroughAttribute applied to it, so I guess that explains the problem I was having with it not letting me Step Into my code, but it still doesn't solve the larger issue of preventing VS from trying to debug the remote service.
I think Visual Studio has the WCF service host behavior built in for WCF Library projects now. As far as I can tell the only way to turn it off is to change the project type back to a normal Library. You can do that by editing the .csproj manually: remove {349c5851-65df-11da-9384-00065b846f21} (and the associated semicolon) from <ProjectTypeGuids>.
Related
I followed this tutorial to create a simple web job in Azure: https://learn.microsoft.com/en-us/azure/app-service/webjobs-sdk-get-started. The web job itself does its job, consumes the message in the queue and I see them appear in Application Insights.
However, I want to debug the function on my local machine by using the tools available in Visual Studio 2022.
I have published with following profile settings:
Next I've attached the debugger under het Hosting menu:
First thing I noticed is a message about no symbols being loaded when putting a breakpoint in the function:
When I add a message to my queue, it gets consumed by the web job but the breakpoint is never hit. I've been reading a lot of similar questions regarding a this issue but I'm not progressing any further.
In Azure Portal, I've enabled Remote debugging under Configuration > general settings
In Visual Studio 2022, I checked if the correct process is attached
Here I'm a bit confused thou, the connection target is connecting through port 4024, which is according to this document, the port for Visual Studio 2019. However, a connection target with port 4026 is not found.
What am I missing here? Am I forgetting another setting somewhere?
If have tried changing the stack setting .NET version from APS.NET V4.8 to NET 6 (LTS) but that didn't help.
Should the platform architecture match the architecture of my machine in order to get it to work? Or is this not linked in any way with the debugger?
Is there anything else that I should check or try? Because my hair is turning grey here :)
Apologies for the delay here!
It should be 4024 for both 32 and 64 bit.
See this Azure doc: Remote Debugger Ports on Microsoft Azure App Service
Typically, the error “The breakpoint will not currently be hit. No symbols have been loaded for this document.” -- This error message indicates we can start debug process and attach, but cannot set a breakpoint on any or some lines of code in the project.
Most, likely cause: Application is built without debug symbols or debug symbols are not available
Kindly try these steps:
Verify Debug Symbols are being used and published and in sync
Workaround the issue by disabling “Enable Just My Code” from the
Tools >> Options >> Debugging >> general menu in Visual Studio
Other things to narrow-down the issue:
Debug symbols must be available locally or deployed to the Azure App Service, and must match the local code you are trying to debug.
It is recommended to use Cloud Explorer over Server Explorer to
connect and debug which requires the Azure SDK.
You could optionally Manually Attach a Debugger to Azure Web Apps to troubleshoot this further or recommend this as a workaround.
(old blog, try similar steps)
Kindly verify the port (Visual Studio remote debugger port assignments ) required is open in the corporate firewall and on your local machine.
As a test, you may use tool like Wireshark/netmon, to see if the port successfully connects to the port (4024) needed by the process.
I'm trying to remote debug an asp.net core 1.1 api app (targeting .net framework 4.5.2) that's running on Azure.
I attach the debugger via Server Explorer. The debugger attaches to the correct process. But any breakpoint I set has the message "The breakpoint will not currently be hit. No symbols have been loaded for this document."
All answers I've seen to such a problem assume that the modules window shows all modules loaded by my project, but in my case the modules window is empty!
I'm on VS2017 15.4.
If I remember correctly, I was previously able to remote debug the same project with version 15.2. The problem started occurring when I updated to 15.3 but I didn't pursue it at the time.
I submitted the problem on the MS forums: Can't remote debug Azure API app
and now I have received an official reply that it is indeed a bug in VS, and a fix will be available in the pending release (15.6).
They also suggested a workaround, which I tried and indeed worked: Manually Attach a Debugger to Azure Web Apps
Which involves:
Going to the web app Application settings in the Azure portal, and making sure that Remote debugging is enabled,
In the VS menu: Debug > Attach to Process..., entering the web app url with the debugging port, e.g.:
myapp.azurewebsites.net:4022
Then in the credentials that appears, entering the username & password that are available in the app's Publish Profile, which can be downloaded from the portal. If the username is $myapp, it should be entered like this:
$myappp\$myapp
Then choosing Managed(v4.6, v4.5, v4.0) code and then the name of the Core app.
Actually, I had found and unsuccessfully tried similar approaches before. The key for me was step 3. The others had suggested entering the username as .\$myapp, or myapp\$myapp. So make sure to enter it as written above.
BTW, seeing that the above blog post is from almost 2 years ago (Feb 2016), whereas the problem I'm experiencing was introduced only a few months ago, it seems to be a cure-all, and it is therefore worthwhile, for anyone who has to deal with remote debugging Azure apps, to save this information for future reference.
UPDATE:
After updating VS 2017 to version 15.5.2 the problem seems to have been fixed.
I have had the same issue with Visual Studio 2019. The fix for me was just to go in the VS menu: Debug > Attach to Process, and try to connect as describe by #Dan Z. The connection was not established, saying No connections found, but attaching a debugger from Cloud Explorer again, right after an attempt in "Debug > Attach to Process" is always successful. That is most probably a bug in VS
I have had to do some repairs to a legacy classic asp website that uses some VB6 activeX dll's
All of the changes that I have made work completely and have been fully tested on my local machine (windows 8.1), I have deployed to the servers.
drainstop
iisreset
copy files
regsvr32 any new dll's
start after drainstop.
All of the code is working on each of the servers after deployment, but when I use the public side of the site, the changes do not work.
I have looked at the event log and cannot find any problems
This is either permission issue in your Component Services for the objects you've registered, or a setting in your Application pool. Make sure you have Enable 32 bit applications to true and see how often it's recycling. But since you're not seeing anything in the event log about it, it's probably not the recycling.
We have a SharePoint farm configured with one SQL server, an Application server and one Web Front End. All assemblies run from the GAC on the WFE, except one. This one dll has to be forced (using gacutil) into the GAC on the App server in order to see changes in our SharePoint application.
My question is, what determines that this dll must run on the App server and not with the rest on the WFE? I assume because of this, I cannot debug in Visual Studio from the WFE. Do I have to install Visual Studio on the App server as well?
When setting up a timer job, it's possible to use the constructor to specify a specific server. That's likely how things got set up for this solution and associated .dll file. More info on that here:
http://www.martinhatch.com/2009/08/sharepoint-timer-jobs-and-multiple.html
As for adding Visual Studio to servers on your farm, if this is your production farm I do not recommend doing this. If you really need to debug in production (you really, really should have a development box set up for this), do it via remote debugging.
I'm developing a Windows Mobile application for internal company use, using the Windows Mobile 6 Professional SDK. Same old story: I've developed and tested on the emulator and all is well, but as soon as I deploy to advice I get an UnauthorizedAccessException when writing files or creating directories.
I'm aware that an application installed to a device needs to be signed but I'm running into roadblocks at every turn:
Using the project properties 'Devices' window I select 'Sign the project output with this certificate, and choose one of the sample certificates from the SDK. This results in a build error: "The signer's certificate is not valid for signing" when running SignTool.
If I try to run SignTool.exe from the commandline, I get an error telling me to run SignTool.exe from a location in the system's PATH.
I can't use the 'Signing' tab in the Project Properties to create a test certificate - this is greyed out (presumably for WinMobile projects?).
If at all possible, I would like to avoid having to go through Versign or the like to get a Mobile2Market certificate. If I have to go this route for a final version that's fine, but I need to at least be able to test the app on real devices.
Any advice would be most welcome!
First, make sure you really do need to sign it (you might be able to adjust the device security model).
If you do, then run signtool.exe, but from a Visual Studio command prompt. The easiest way to get there is fromt he Start menu, select Microsoft Visual Studio 2008->Visual Studio Tools->Visual Studio 2008 Command Prompt. This will set up all the proper pathing for you.