I'm trying to implement a CD/CI pipeline on TFS. I've created the build, and all the steps has been successfully, except Publish symbols path.
I'm receiving this error message:
2019-09-12T11:34:17.9788901Z ##[error]Indexed source information could not be retrieved from 'E:\buildAgent_work\96\s\Branch\Branche\Api\bin\AWSSDK.CognitoIdentity.pdb'. Symbol indexes could not be retrieved.
Anybody know how to fix this?
Thanks!
I Fixed the problem. I had just to change to Release, instead of Debug. Thanks!
How to stop generate pdb files in Release package
This issue seems to be:
The default value for is portable - the new portable PDB.
TFS 2017 can't read the new portable PDB format.
Some possible workarounds for:
upgrade to TFS 2018
exclude AWSSDK.CognitoIdentity.pdb when publishing symbols
Build AWSSDK.CognitoIdentity from source and set the <DebugType>None</DebugType> in the project.
Since the AWSSDK.CognitoIdentity.pdb comes from the nuget package AWSSDK.CognitoIdentity, we could not use the following setting to disable PDB Generation:
<DebugSymbols>false</DebugSymbols>
<DebugType>None</DebugType>
So, we could update TFS to 2018 or exclude AWSSDK.CognitoIdentity.pdb when publishing symbols.
To exclude AWSSDK.CognitoIdentity.pdb when publishing symbols, we could use File matching patterns reference in the option Search pattern of Publish symbols path task:
**/bin/**/*.pdb
!**/bin/**/Microsoft.WindowsAzure.Storage.pdb
Hope this helps.
Related
I'm receiving the message below when I attempt to start the Local Windows Debugger on this project in Visual Studio 2022 . I had some earlier challenges adding and linking the additional include libraries and files for MySql as well as some earlier notifications about missing .dll files. I thought these were resolved since I was able to successfully build. What do I need to check to start trying to fix this? Let me know if any additional information is needed.
I was able to resolve the issue by re-writing the project from scratch on my laptop, starting with an empty C++ project. In the course of doing that, I did run into some of the same messages regarding missing .dll files. This was resolved by copying and pasting these into the appropriate /debug folder for the project directory. As suggested, I did implement the scan for corrupt files, which fortunately did not turn up any issues. Once this was completed, I achieved a successful build and execution of the program.
I'm making a dll for python using c++ and importing functions using ctypes library.
I know that to do remote debugging you go to Debug -> Attach to Process.
I put a breakpoint in python code before imported function is called, but I don't know what process to attach to. I tried attaching to python.exe, but that didn't work.
What process should I attach to or do I need to do remote debugging differently and if so then how?
Thanks
The process which need to be attached to is the process that needs to call the dll. If you want to remote debug dll, I suggest that you could refer to this link about Remote Debugging a C++ Project in Visual Studio. Also, you could refer to this link about Debug DLLs in Visual Studio.
I suggest that you could look in the modules windows. There are several situations:
1.No Symbols have been loaded for this document
Go to the Modules window (Debug > Windows > Modules) and check whether your module is loaded.
If your module is loaded, check the Symbol Status column to see
whether symbols have been loaded.
a.If symbols are not loaded, check the symbol status to diagnose the issue. From the context menu on a module in the Modules window, click Symbol Load Information... to see where the debugger looked to try and load symbols. For more information about loading symbols, see Specify Symbol (.pdb) and Source Files.
b.If symbols are loaded, the PDB does not contain information about your source files. These are a few possible causes:
If your source files were recently added, confirm that an up-to-date version of the module is being loaded.
It is possible to create stripped PDBs using the /PDBSTRIPPED linker option. Stripped PDBs do not contain source file information. Confirm you are working with a full PDB and not a stripped PDB.
The PDB file is partially corrupted. Delete the file and perform a clean build of the module to try to resolve the issue.
If your module is not loaded, check the following to find the cause:
a.Confirm that you are debugging the right process.
b.Check to see that you are debugging the right kind of code. You can find out what type of code the debugger is configured to debug in the Processes window (Debug > Windows > Processes). For example, if you are trying to debug C# code, confirm that your debugger is configured for the appropriate type and version of .NET (for example, Managed (v4*) versus Managed (v2*/v3*) versus Managed (CoreCLR)).
2.… the current source code is different from the version built into...
You could go to Debug > Options and Settings. On the Debugging/General page, clear the Require source files that exactly match the original version option. Make sure to reenable this option when you are finished debugging.
In addition, it may be that the dll has not been loaded into the .exe. You could set Properties->Debugging->Working Directory.
So the program works perfect fine, runs without errors, etc during a build/run in the IDE but when I move to the Installshield Install and attempt to install it all files appear to install but the program doesn't load any kind of display. I can see that the program is open when I do a ctrl+alt+del and go to task manager but it doesn't appear to be running any other way. I don't receive any kind of errors and I'm unsure of how else to check what's going on here. While building the projects the only indicator of a problem is the following warning which has been around since I've started my project it seems and previous builds of the install have worked
Warning: 2>ISEXP : warning : -7235: InstallShield could not create the software identification tag because the Tag Creator ID setting in the General Information view is empty.
Also during build of the program I get these:
1>SOIL.lib(image_DXT.obj) : warning LNK4099: PDB 'vc120.pdb' was not found with 'SOIL.lib(image_DXT.obj)' or at 'C:\Users\Daddy\Downloads\3 Jul 2016\Final New AI\Final\Battleship\Debug\vc120.pdb'; linking object as if no debug info
1>SOIL.lib(image_helper.obj) : warning LNK4099: PDB 'vc120.pdb' was not found with 'SOIL.lib(image_helper.obj)' or at 'C:\Users\Daddy\Downloads\3 Jul 2016\Final New AI\Final\Battleship\Debug\vc120.pdb'; linking object as if no debug info
1>SOIL.lib(SOIL.obj) : warning LNK4099: PDB 'vc120.pdb' was not found with 'SOIL.lib(SOIL.obj)' or at 'C:\Users\Daddy\Downloads\3 Jul 2016\Final New AI\Final\Battleship\Debug\vc120.pdb'; linking object as if no debug info
1>SOIL.lib(stb_image_aug.obj) : warning LNK4099: PDB 'vc120.pdb' was not found with 'SOIL.lib(stb_image_aug.obj)' or at 'C:\Users\Daddy\Downloads\3 Jul 2016\Final New AI\Final\Battleship\Debug\vc120.pdb'; linking object as if no debug info
Not sure if that means anything though. The vc120.pdb is located in the debug folder of the project.
If a program does not work once deployed to a fresh machine, then something is missing in the deployment. One of the more common cases is a missing dependency DLL, either one of your own, or something from a third party. However this often results in an error message when attempting to run your executable, so if your scenario is a missing dependency, it's a softer dependency than the typical static link dependency. So, rather than being told by Windows, you need to dive in to figure out what isn't there.
You will probably need to debug into the running but headless behavior of your app. Try a tool like Process Monitor to identify relevant missing files, registry? Or get a developer of the app to help if you're not a developer yourself; they may know better what missing dependencies would result in this behavior. Is it missing a registry key or configuration file? Is it missing a dynamically loaded DLL? Does it log anything, or can it be configured to do so? Can you figure out what it's doing by grabbing your PDBs and attaching with WinDbg? Can it be modified to log or to issue errors in these or similar scenarios so you can better debug deployment problems?
Once you identify what's missing, you can configure the installation to deploy those items as well.
I have used the Visual Studio 2012 Performance Analysis to profile my C++ code for a long time, but recently when I try to use it seems to be failing to load the symbols as I get this error when I try to view the details
Matching symbols could not be found. Choose the 'Symbol Settings..'
link to add the symbol file location and then reload the report.
I have visited Options -> Debugging -> Symbols but I don't know what I need to add so that the symbols load correctly.
Currently in that menu Symbol file (.pdf) locations: has one option available in it and it called Microsoft Symbol Servers and it is selected. In the Cashe symbols in this directory: I can see it is being set in a temp folder but when I go that folder I see it is empty.
What do I need to add so that the symbols load correctly?
I asked this question on MSDN and I was told that this is a known issue with Visual Studio 2012 and Windows 8.1. Microsoft has either by now fixed it or will fix it in a future update. Here is a link to the MSDN question.
make sure you build your project with .pdb files and add these to the list of symbol locations (possible library pdb's as well). I know this should be a comment, but i don't have the reputation for it yet :(
A question about pdb file. Is pdb file for debugging in Visual Studio? If so, why do they also exist in my Release folder? It's normal that pdb files are in Debug folder, but why they are also in Release folder.
So I have now a Release folder build by Integration team with all the pdb files. Now I can load all the corresponding source (in GIT) so I'm sure that the binaries correspond to the source. Then do I need to build again in order to debug in Visual Studio? If not, what I have to do in order to get thing done quickly?
As mentioned above, PDBs are as much important as release binaries! Once a software is released, you can debug it afterwards (depending on whether public and private symbols are available). Should the PDBs contain private symbols, please keep in mind that these describe your code (parameters, types, return values, symbols...). Here an article explaining the logical link that exists between an executable and its PDBs.
Actually you can debug your release build too - if you have the PDB files. So it's a good idea to keep the PDB files of your shipped product (release build).
For debugging you need the executable and the matching PDB and the matching source files. That's it.
You can debug a release build as well, it's just that it's not that useful because of all the extra optimizations. If you don't want a pdb file, you can specify it in the project properties for the release build.
Is pdb file for debugging in Visual Studio?
YES.
why do they also exist in my Release folder?
Go to "your project" Property Page (target release) -> Linker -> Debugging.
Set the option Generate Program Database File. i.e. Release/myExe.pdb