I've got a scenario where I want to launch a locally hosted service via IISExpress through the command line, and then debug it with Visual Studio. The problem comes when I attach a debugger to the IISExpress process, however, as it doesn't appear to be loading the symbols from my service's components.
The service is operational. I added some traces to verify that my local components are being run by the service. I just can't hit a break point.
Some information about my situation:
This is with Visual Studio 2015.
I'm using the /path option from IISExpress.exe, launching with minimum configuration possible.
This is an ASP.NET Web Api application.
Sometimes when the debugger attaches it shows the underlying dependencies (my assemblies), but I'm unable to load symbols from them as VS doesn't recognize the .pdb's I have on disc for them.
I found the application.config files for both my service and a service that was set up by Visual Studio. The files are configured differently, but they don't appear to be meaningfully different.
Most of the service's components are release builds and are deployed without symbols. One assembly is a debug build and does contain symbols.
The compilation tag's debug attribute seemed to have no effect on my ability to debug.
The idea here is to be able to pull a build from our build pipeline with a testing tool and load components from a local development project.
I discovered the problem after taking a closer look at the Debug -> Processes panel. It turns out that when IISExpress was initially being launched it was selecting the Native debugger by default instead of the Managed (4.6, 4.5, 4.0) debugger.
I installed and used EnvDTE80 to elect for which debugging engine I would like to attach with and everything worked like a charm!
Related
I have an ASP.Net application who's code is sitting in an Azure Repo. The project has a build pipeline that builds on master branch merges. I then have a Deployment pipeline that takes the latest build and deploys local on my web server through a deployment pool I have running on my server. The web application builds with the VS Build task and deploys with the IIS Web App Deploy task. Both work fine.
I have one VM in with Visual Studio that I am trying to use to remote debug the web server. I have VS Remote Tools on the web server and it successfully runs. On my VM, I am able to open VS, attach debugger to a remote process on the web server successfully. The problem is that the symbols are not loading and I'm not sure what the correct sequence of items is here.
First, it doesn't appear that there are any .pdb files in the build produced by the Azure Pipeline. Second, I'm not sure what is the proper way to get the code onto the VM for debugging (Clone repo, vs download zip, etc). Third, I attempted to add a Publish Smybols task to my deploy pipeline, however its generating .pdb folders not files, and I'm not sure where to place these either on the web server, or on the vm.
My background is in classic local TFS setups, so working, building and deploying from Azure DevOps has me confused on how to get remote debugging to work.
OK this is not for the faint-hearted. It has taken me 3hrs to slowly work through this - but it's worth it. Many times has something worked locally, but then when you trigger an Build Agent with CI on a remote server you can't Step through the code with breakpoints.
So this info is if you are using the above situation - Azure build agent and Continuous Integration. If you are using a Publish Profile this doesn't apply.
First things first... The most important parts of this answer can be found in this blog:
https://willys-cave.ghost.io/i-have-a-dream-of-a-single-build-consistent-x-and-simple/
I've added that Url to the wayback machine at archive.org in case it disappears.
So yes the problem is the .PDB files - they need to be included by adding Publish symbols task. in your VSO pipeline.
Note: I had to change the BuildConfiguration parameter to debug (different from Willy's instructions). Otherwise when you eventually start to hit breakpoints the code is optimized and you won't see variable values in the hover-over etc.
In VS 2019 Willy's instruction for Link to the symbols during remote debugging sessions needs reading carefully. I didn't. There is a better image on:
https://devblogs.microsoft.com/devops/vsts-is-now-a-symbol-server/
I include the screen capture here:
Importantly you need to add your VSTS hostname into the list of Symbol Servers
Now mine still wasn't hitting the breakpoints and I found this page (which is generally about using the slightly different method of Publish Profiles), but I noticed some more components were loaded into IIS... Yes! You may need these too.
https://learn.microsoft.com/en-us/visualstudio/debugger/remote-debugging-azure?view=vs-2019
So the most important image I will paste here:
You need to add IIS Management Scripts and Tools to your IIS installation.
That should do it. Also I run my remote debugger as Administrator, attach it to the w3wp.exe (show All Users Processes) and if it doesn't appear - reload the remote page and Refresh as if the pool goes to sleep you won't see it in the list
Good luck!
Whelp, I avoided it as long as possible, but the time has finally come to make some changes to some ancient VB6 code. I'm a recent college grad so I was hoping to stay away from this code that is almost as old as I am.
The DLL is compiled in a local installation of VB6 and deployed via Component Services. That component is then called by VBScript in a Classic ASP application running on a windows 2003 Server.
I've tried just about everything to debug this code using the VB6 debugger, but I can't get it to work. I've compiled the DLL to the same location that Component Services has it deployed to (a random folder on a non-system drive), and set binary compatibility to that same DLL. Each class file has instancing set to MultiUse and MTSTransactionMode set to '1 - NoTransactions.' The component works fine until I attach the debugger, then I get 'ActiveX component can't create object' when trying to instantiate the object. If I detach the debugger, it works again.
I noticed that in Component Services when I attach the debugger, the DLL location changes to C:\Program Files\Microsoft Visual Studio\VB98\VB6DEBUG.DLL, which I assume is just VB6 intercepting calls to the component. When I detach the debugger, it changes back. I should also note that the component is configured to use a specific user identity separate from my logged-in user account, however everyone has been granted access to the component via a user role. The component activation type is also 'Server Application,' however setting it to 'Library Activate' doesn't seem to make a difference.
I've also tried using the VC++6 IDE, and VS2010, but had no luck. I was able to debug the dllhost.exe in VS2010 and was able to hit some breakpoints, but the symbols weren't loaded properly. I tried compiling the DLL with debugging symbols and loading those to the VS2010 environment via the Debug settings menu, however that didn't resolve the issue.
I also didn't find the component services JIT Debugger to be very useful. I'd much prefer to just be able to debug in VB6.
What amazes me most is that this code is thousands of lines and has been maintained without the use of any debugger whatsoever. My young, spoiled self isn't ready to accept that this code can't be debugged.
I have a solution A with a web site project that it needs to call another web site project B that is in another solution. I mean different visual studio instances
I don't know how to attach them to debug them at the same time like in a single trace.
Does anyone knows how can i do that?
Thanks
You can do this using two running Visual Studios:
You set up one of the projects in IIS and the other you can run out of Visual Studio directly then you can debug in both.
On the first project (the one running in IIS) you can 'Attach to a process' and attach to the w3wp worker process. See this:
Attach Debugger to IIS instance
Then in the second project just run the project using Debug --> Start Debugging option from the VS menu.
Optionally you can run them both out of IIS and attach to both processes.
Make sure you have debug allowed in your web.config files.
What i can think of is, you can deploy project B with pdb file onto a server and attach remote debugger to that server.
Is there a way to precompile the ASP.NET MVC views on an Azure Web App (specifically when published via Release Management on VSTS)?
Once each view has been hit once, the page subsequently renders very quickly. But that first delay can be a doozy for users and there's no way to script touching each page.
I'm not sure if I need to change something in the build/release processes on VSTS (I am using the Visual Studio Build build step and the Azure Web App release task) or if I need to run something on the Azure Web App instance after it is released (or something else altogether).
It seems like finding some way to call aspnet_compiler after publish might be what I need (and I have seen that in reference to Web Roles on Cloud Services) but I can't get that to work.
Calling
%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler -v "/" -p "d:\home\site\wwwroot"
via the Console in the Azure Portal executes just fine (and finds errors if there are any) but doesn't have any impact on startup time - hitting a view the first time still takes a long time.
So maybe that isn't the right direction.
I've looked at RazorGenerator (including the .MSBuild nuget package) and I couldn't quite get it to work, but really I was hesitant to make so many changes to the projects just to get precompilation on release.
Also note that I am currently using TFVC, not Git, in VSTS, so the Kudu/Git integration (that does seem to trigger the precompilation according to some articles) isn't available to me as far as I can tell.
Other ideas?
You can add "/p:PrecompileBeforePublish=true" argument in "Visual Studio Build" step:
Then the task will call aspnet_compiler during the build process and generate a precompiled output for deployment.
In visual studio 2013+, choose Build->Profiles. Select the profile, then choose "Settings". Underneath "Configuration", expand "File Publish Options", and then check the "Precompile during publishing" option.
In some of the solutions we have ASP.NET/WCF web project and a test project. Some of the tests run against ASP.NET development web server using http://localhost:port/.... In VS2010 while the ASP.NET/WCF web project was being debugged, the test runner could run the tests and if there were any breakpoints in web project, the debugger would break the execution. This seems to have been disabled/removed in VS2012.
When the ASP.NET/WCF web project is debugged (launched by pressing F5 or via attach process), both the TEST->Run and TEST->Debug sub-menus are disabled. In VS2010 only Test->Debug sub-menus were disabled while Test->Run sub-menus were still enabled. We use this way to easily debug the services within the web project. Any way to get that behavior back or workaround?
Debugging While Running on ASP.NET Development Server doesn't seem to be applicable to VS2012 or at least I can't get it to work.
In VS2013 the situation is the same: the options for running / debugging tests are greyed out while the project is being run/debugged. This is a shame especially for projects like web API's where tests for calling the API via HTTP (as opposed to creating an instance of the Controller class and circumventing any network traffic) are very useful as they are closer to what the end users of the API will experience.
As a workaround, you can either open the same solution in a separate instance of VS, or create a separate solution with the same projects, specifically for testing. Debug in the first VS instance, run tests in the second one.
If you have a solution with WCF applications and tests calling them, you can debug the applications using the tests by calling Debug All Tests or Debug Selected Tests without a previous Start Debugging (F5).
Configure your solution to Multiple Startup Projects with None set in all actions and configure your WCF applications to the start action Don’t open a page. Wait for request. With this configuration the development web server starts if you select Debug All Tests or Debug Selected Tests.
Here is a workaround to debug a single unit test along with a web server. It relies on Debugging Multiple Processes (excludes MSVS Express):
Start web server (non-debug), note its process id (IIsExpress icon -> Show All Applications)
Place a breakpoint at first line in test
Start Debuging the Unit Test, wait for it to stop at the breakpoint.
Debug -> Attach To Process, enter web server process id
Both the test and server are running live in the debugger.
I ended up writing a quick addon. It turns out that like VS2012, VS2012 test runner can also run the tests when the web project is being debugged. It is just that menu options are disabled.
Try this:
Place a breakpoint in the first line of your unit test method.
Start debugging your unit test.
Once it hits the first line in your unit test, start a new instance of the other projects you need running.
This is not a pretty solution, but it works. Using Azure DevOps TFS Version Control, create a branch of your current project. Open the solution for your project, in the other branch, in another instance of Visual Studio at the same time as your main project is running in the first/original instance of Visual Studio. Then, run your web project in your first/main Visual Studio instance. Now, run your unit tests from the other instance of Visual Studio. Voila.
To keep them in sync, you can do Merges from one branch to the other.
I still ran into this on VS 2022.
If you have multiple projects you can run. Try to set the startup projects and set at least two of them. (solution->right click)
If two instances are running in debug mode, VS also allows you to start unit tests.
(I just started two aspnet api-s from my project)