I have Visual Studio 2013 in one machine and I have published the code in remote machine using ccnet. The remote machine has only the published code which can be run on IIS.
I want to remote debug this code from VS 2013 in local machine. I followed steps as in msdn, but when I attach to process, breakpoint turns hollow - with message, no symbol file loaded for this document.
I then changed the attach to option from AUtoimatic to Native 4/4.5. Then debug point became active, but when I debug, the points are not hit. Looks like it is enough if pdb files for vs 2013 are placed within app root directory itself. Not sure why am not able to debug.
In VS2013 you can set the symbol file locations.
Tools --> Options --> Debugging --> Symbols --> Symbol file (.pdb) locations --> New (icon on top right)
Make sure that on the bottom part of the screen your module is allowed to load symbols automatically, either by choosing "All modules" or by choosing "Only specified modules" and then specifying your module.
Related
I'm able to successfully publish symbols to the VSTS symbol server as part of the build execution.
Followed this link to setup visual studio and everything good until this point. My symbol settings shown below:
When trying to debug, visual studio hits VSTS symbol server but return error message “Cannot find or open PDB file”
Below is the symbol load information provided by visual studio after trying to fetch from VSTS symbol server
As of November 15 2017 Visual Studio Online (also now known as Azure DevOps) the Index Sources and Publish Symbols build step handles the new portable PDB's create by dotnet build
You should tick Publish symbols and select your Subscription. The free tier has 5 users. You need to assign each user access to symbol server.
Ticking the Index Sources check box makes no sense though as the source files are on the build server, usually in an obscure location such as C:\agent\_work\34\s\... which will not match your local (or network path) to the source files.
To help Visual Studio find the source files you can do this... (you can avoid this by using SourceLink as described below)
Select the solution in Solution Explorer and then choose Properties from the shortcut menu.
Under the Common Properties node, choose Debug Source Files.
Click the folder Tools/ Options/ Debugging/Symbols folder icon icon. Editable text appears in the Directories containing source code list.
Add the path that you want to search.
When you start debugging all the symbols will download and you can step into the source code now.
This does NOT require disabling just my code and you do not need to enable source server either.
Unless you are using, or would like to use source server. It is pretty easy to do now by adding a few packages...
With AzureDev ops you can modify your build pipeline to make use of soruce files stored in GIT byt following this guide.
The prerequisite is .NET Core SDK 2.1.300 or desktop msbuild version
15.7.
On your package project project you need to add NuGet package "SourceLink.Create.CommandLine" which will enable your build server (and your local build machine) to rewrite parts of the Portable PDB's without changing anything in the build pipeline.
You also need to add a package to the correct source control. As described in this article. - I am using VSTS so I just install "Microsoft.SourceLink.Vsts.Git" package (must enable Include Prelease as of writing now)
To verify this works all you need to do is build the project and look inside \obj\{config}\{tfm}\ for a file called *.sourcelink.json and has the correct URL's inside it.
Then the usual pack and publish you would do.
In Visual Studio you just need to enable
Enable Source server support
Enable Source Link support
You need to run the application built in the same build as the build to publish symbols to VSTS Symbol server, the identity will be different in the different builds.
You can find that there is the GUID (0CD368C47775439…) in the Symbol load information, also you can check the Publish symbols task’s build log, there is the GUID too. Within a build the GUIDs will be the same and the symbols will be loaded correctly during debug.
Did you enable Source Server Support in the VS.NET debug options ?
You might also uncheck 'Enable Just My Code' in the VS.NET debug options.
There's a blogpost that I've recently written where I explain setting up and using a symbol server; might find some tips that might help you with your problem.
I have a Visual Studio "solution" which contains a Web application project (among a few other projects). Visual studio "typical" setup seems to be to insist that the output directory for binaries is smack in the root of the project source directory. In particular, each time the web application project is opened, Visual Studio will reset the physical path of the IIS virtual directory to point to the project directory.
This is problematic on many levels:
It's never wise to mix binary output directories and source trees
If the web application is buried deep within a directory hierarchy of other source, wherein many projects produce libraries which may be used as support libraries in the web application, then all the other supporting projects must have their binary output directories set to a bin directory a some non-obvious, nonsensical location somewhere in the source tree.
This "typical" VS setup does not have your web app setup duplicate the "production" setup you would get from a publish: there may be files in your source tree (an old .js file there there from a repository extraction, for example) that are not referenced in your projects, and so would not be in the production published package, but are there in your debugging setup.
It is very possible and very easy to configure all the projects in a Visual Studio solution to build to a bin directory in some subdirectory cleanly placed outside the source tree. It is also easy to ensure that the web app build places all content cleanly in this directory. It is also easy to configure an IIS virtual directory to point to this build output directory. And then Visual Studio, unannounced and unbidden, screws this up by arbitrarily changing the physical directory of the carefully configured virtual IIS app, to point to the middle of one's source tree.
How can this crazy-making behaviour be stopped? I.e. how do I prevent Visual Studio from automagically re-setting the physical path of the virtual web directory each time the web app project is opened?
This question has been asked many times here on Stack Overflow, but I have seen no real answers:
The response to this question (IIS8.5 is automatically changing Physical Path property) simply indicates how to control the order in which Visual Studio does its repointing.
This question and response (Visual Studio creating IIS virtual directories when solution opened) simply confirm the behaviour.
The response to this question (Opening projects changes iis settings) is simply wrong, as are some of the comments.
These questions (Visual Studio 2012 changes IIS application directory without asking), (Visual Studio changes local IIS configuration) have no responses.
Basically, no one has said it can't be done, but no one has give a decent solution either.
I have my application in IIS pointed at %SystemDrive%\inetpub\wwwroot\web, and would like it to stay that way. Like others, I discovered that every time I opened the solution in Visual Studio (I'm using 2017), it would change the application's path in IIS to point to the path that Visual Studio uses.
I've made the following change to the project settings (web tab) for my project. In the servers section, I've set the drop-down to "External Host", and then entered the project URL as https://localhost/web. I'm now able to open the solution in VS without it updating the path in IIS.
When using Visual Studio 2008 under MPI cluster debugger, each execution is launched without moving the generated binaries (.exe, .lib).
When using Visual Studio 2010 under MPI cluster debugger, each execution is launched by moving the generated binaries (.exe, .lib) in two directories :
- all the .lib are first copied inside the .exe directory
- once done, all the .exe directory is copied inside a temporary directory containing by default the user login name.
So with Visual Studio 2008, each execution of a medium size C++ project takes a few seconds to be launched.
With Visual Studio 2010, each execution of a medium size C++ project takes several minutes.
Is there a way to change the behaviour of Visual Studio 2010 in order to work like Visual Studio 2008 did ?
Or if not possible, is there a way to improve the launching time of each execution ?
I am using MPICH2 for MPI and execute my project only locally (localhost/2 environment with -localonly mpiexec argument), for Visual Studio 2008 and Visual Studio 2010.
Thanks for any help.
Do review the MSDN page that describes the MPI debugger configuration. Note how the descriptions of the Deployment Directory and Working Directory properties describe what you see.
However, you are not actually debugging on a cluster so you don't need to have these copies made. Without otherwise knowing what your config looks like, or any way to test it, I'd guess that you have these properties set wrong. As documented on the page, for local debugging you should select:
Deployment Directory: none
Working Directory: the output directory of your project.
Which should avoid the copying.
Here is my situation...
I have to maintain a website with multiple applications. We no longer have any of the solution files and the code is deployment code (so it uses DLL's instead of the original classes).
I basically grab the code from the website and stick it in a Visual Studio projects folder (This is generally C# code with Javascript that was originally developed on VS). I then open Visual Studios's 2010 Professional (VS) and open website, using the path in the project folder. I then add references to all the DLL files and if all the includes, images , and css files paths are referenced correctly, I can hit F5 and get the webpage to appear with some functionality. This creates a Project file in the Projects folder which I can then open instead of opening a website.
The problem is that I am unable to debug. If I set a breakpoint, it goes from solid red to outline red upon start of debugging. The standard message is "The breakpoint will not be currently hit. No symbols have been loaded for this document".
I have cleared out the symbols and reloaded.
I have debug = true in all my Web.config files.
I have gone into project properties and set the startup project action to "Start".
Any ideas why I can't debug ? My other projects that I develop from scratch work fine, but it is these projects that I am trying to get working from website files that won't debug.
My goal is to get every one of the Website apps under VS control were I can fix bugs and make improvements. Not very easy when the original source code is no longer available.
Please Help !
Thank You,
Eric
I fought this issue for a half of a day. I'm currently maintaining a website application. What worked for me is going into the project's Property Pages >> Start Options and changing the server to "Use Custom Server". I believe this setting will use IIS and not IIS Express. I started the project and was immediately able to debug.
I've been using CMake for quite some time to generate VS 2008 solutions to build a program, its installer, and its packager (as well as several test programs). In order to run, the program needs several dlls which the install project puts into a bin directory, along with the generated executable. Under VS 2008, if I want to debug the created program, I build the INSTALL project, and then click Debug->Start Debugging. The first time I do this after generating the solution, this presents me with a dialog from which I can browse to the bin folder and then the desired executable.
However, under Visual Studio 2010, after clicking Debug->Start Debugging, I do not get the dialog, but rather get the message that it can't find the ALL_BUILD program (which does not, and should not, exist). I can change the start up project to be the executable in question (or right click on it and choose debug), but then that loads the executable from the wrong path and is therefore unable to find the dlls. I know that I could either add the dlls to my system path or copy the dlls into the same directory where the executable is initially created, but these are less-than-ideal solutions (for testing and portability reasons), and these steps were not required in VS 2008.
This is the exact same CMakeLists.txt file for both cases, and the exact same source code. The only difference is that CMake is run with the "Visual Studio 9 2008" generator in the first case and the "Visual Studio 10" generator in the second case.
I can run the generated program from the bin directory using Windows Explorer, but I am not able to debug it (e.g., step through a problem area line-by-line).
You need to edit the debug properties of your start up project so the command line and working directory match your install location.