I'm having some trouble debugging policies through the Visual Studio Code extensions.
Whenever clicking on the test operation button the HTTP rest-client extension opens.
The extension presets your HTTP call to be executed however, the versioning scheme is automatically defined as a template parameter instead of a query parameter (api-version=v2.4)
There is no possibility to amend it in the settings of visual studio code. (extension)
Whenever clicking the start policy debugging
The debugging starts but is unsuccessful to connect.
I can clearly see the debugging logs where the client tries to connect however it is failing to do so because of a gateway error.
The APIM must be on Developer tier to be able to debug policies
Related
I have a .net core application deployed to IIS. There is a signalr hub in the application.
My problem is that when my client hits the hub it receives a 500 error back.
I have put logging in the hub and can see that it is being hit correctly and no exceptions are being thrown.
The setup works perfectly when run from Visual Studio.
I am thinking something might not be set up in IIS correctly.
Does anyone have any ideas that this might be?
I enabled the generic error page in the api and looking at the network tab in the browser I was able to see the call that signalr was making.
I looked at the content of this request and found that an error with the following message was being returned by the server...
The data protection operation was unsuccessful
After some searching I found that this was being caused due to a setting on the IIS application pool.
The steps to change the setting were...
Open IIS Manager
Select Applications Pools, and go ahead and select the App Pool used by your app
Right-click on it, and select Advanced Settings, Go to the Process Model Section and Find the “Load User Profile” Option and set it to True
These steps were taken from http://puresourcecode.com/dotnet/post/ASPNET-The-data-protection-operation-was-unsuccessful
I'm trying to setup webdeploy on IIS8, but why am I getting 404 when accessing both https://[servername]:8172/msdeploy.axd and https://localhost:8172/msdeploy.axd locally.
I've installed management service.
I've installed webdeploy 3.5 using web platform installer. In Program and Features a changed the instalation of webdeploy to include all features including the handler.
In IIS Manager I've chosen Configure Web Deploy Publishing for default website's context menu.
I've restarted management service.
when i tried https://[servername]:8172/msdeploy.axd I was asked to enter credentials and accept the certificate. after that I got 404.
I've uninstalled webdeploy and installed using MSI manually including all features.
restarted entire server.
getting 404.
I don't believe you can open the service from a browser. I attempted that against a dev server that we deploy to many times a day and also received a 404. I would try deploying from VS instead as a test.
Also if anyone comes here and is using Visual Studio Publish dialog and the "Validate Connection" button fails: do NOT use the button when creating. Just click Ok, then Edit (in More actions menu).
In the Connection tab, click Validate Connection. This time it will asks you to accept an invalid certificate (since you likely self-signed it on your server). Accept it and the connection should go through.
Visual Studio 2015 (Loaded as Admin), Web API 2, Windows 10.
I have Local IIS with a subdomain sub.mylocalsite.com mapped through the hosts file to 127.0.0.1. The Web API 2 is loading and I am able to debug and do all the activities as expected.
On IIS, if I add a secure binding, with the proper self-signed certificate (without disabling the non-secure binding, i.e. keeping two bindings) and do an IIS Reset, I am able to access the https Web APIs as expected, however, when I click run to start debugging I get the standard error from VS of Unable to Start Debugging.
Please note that I tried both setting the start URL as http://sub.mylocalsite.com and https://sub.mylocalsite.com to no avail
Any solution?
I experienced the same thing, then saw this blog post. Try attaching to worker process, per this blog post:
https://blogs.msdn.microsoft.com/vijaysk/2007/10/17/visual-studio-debugging-websites-that-require-client-certificates/
The most important requirement for the pretty F5 key to work in Visual Studio is NTLM/Windows Intergated Authentication. Only then can it auto-attach to the IIS worker process. And this is where our trouble starts. Client certificates is a kind of an authentication mechanism. When you configure a website to require client certificates you are changing the authentication mechanism.
So if you are developing a website off an IIS server and you need to debug it with client certificates then you cannot just open your web project in visual studio and start debugging it. But what you can do is attach to the process running your code manually.
Open your project in Visual Studio and set a breakpoint as you usually do
Debug menu > Attach to Process > Select the process running your code.
Trying to debug azure mobile service running in the cloud. I have published debug configuration, in the options indicated to allow debugging non JustMyCode and use source server.
Attach to running process works and I could put break points and step through the code, though I could not get the values of any variables. Even 'this' would not show the values in the watch window.
Prior to that I was trying to debug a release published configuration and the watch used to display values of some of the variables. Others were indicated that due to optimizations values are not available.
Thanks for help,
Ruben
I think you did something wrong, because if you did the remote debug the break point should be hit and you can see all data.
Please see this article
Cconnecting a menu app to azure mobile service > How to do the remote debugging
If it not help, provide a movie with that you are doing :)
I recommend to have Azure SDK 2.5 and Visual Studio 2013 update 4
There are a million links like this one http://blogs.msdn.com/b/cie/archive/2014/01/24/windows-azure-remote-debugging.aspx, which more or less would seem to take care of the remote debugging setup. I have done this many times in VS 2013 Update 2, deployed, then attached to debugger and it simply does not work. Well, the debugger seems to attach, but I continually get the message when I hover over a break point informing me that 'The breakpoint will currently not be hit. No symbols have been loaded for this document' A while back I recall seeing a channel 9 presentation and they seemed to configre the symbol store. I tried configuring this and it still gives me the same message when hovering over the breakpoint.
VS 2013 Update 2 Remote Debugging - I can only get it to work with a 'Debug' build. I have set the Debugging Option "Enable Just My Code" and loaded all symbols -- this seems to work fine. I can now set breakpoints and do not receive the message you (and I) noted earlier.
This is probably not the ideal situation as it would be nice to be able to attach the debugger to a production release but it seems to be a semi-reasonable workaround for now.
EDIT:
Important points:
You must enable Remote Debugging in the Azure Portal for your Cloud Service or Web Site -- Configure Tab (it only remains enabled for 48 Hours)
The debug attribute of the compilation element in your Web.config file must be set to "true". This means, you either have to do a 'Debug' build or manually edit the Web.config file. Here is a link to official Microsoft documentation with a full explanation and a great example of how to do that without redeploying your application:
http://azure.microsoft.com/en-us/documentation/articles/web-sites-dotnet-troubleshoot-visual-studio/#remotedebug
If you still have problems you may have to disable the Debugging Option Enable Just My Code in Visual Studio
I had the same problem - also with VS 2013 Update 2.
The crucial bit I missed was selecting the w3wp.exe process in the pop-up that shows the running processes before hitting the Attach button.