Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Wednesday, February 13, 2019 10:18 AM
Hi,
for some time now I am struggling to understand what happened to Visual Leak Detector. VS Marketplace says it's supported up to VS 2015. At the moment, there are no installers to be found, not even for older MSVS versions -- I recall on my old machine I installed version 2.5.1 as an VS extension and somehow it still worked with VS 2017. Now I am on a new machine and I am failing to find installers and I'm also failing building vld from source, which makes some sense, as there are only MSVS14 solution and project files on github, so maybe it isn't meant to be, just speculating.
So I cannot find a proper statement or recommendation about how to use it with 2017. I am wondering if I am missing something -- maybe is it obsolete due to some built-in features in 2017? If so, what is the recommended way to detect mem-leaks? If not, how do you use vld with 2017?
Thanks
All replies (6)
Wednesday, February 13, 2019 1:45 PM ✅Answered | 1 vote
Hi rAigner,
Welcome to the MSDN Forum,
Currently, the latest version of VLD v2.5.1 does not currently support Visual Studio 2017 and only supports Visual Studio 2008 to Visual Studio 2015.
If you want to use VLD in VS 2017, please refer to my experience as below:
The source code and installation files for VLD are currently hosted on codeplex.com. The address is: https://vld.codeplex.com. Download the latest version (v2.5.1) installation file and install it. (My installation path is: C:\VLD\Visual Leak Detector). Please note you have to remember your own installation path, which we will use later.
Check out the " Using Visual Leak Detector " section of the help documentation on the github website. Follow these instructions to create any C/C++ project with Visual Studio 2017 and then find View -> other windows -> Property Manager.
Select debug|win 32 -> right click “properties” of Microsoft.Cpp.Win32.user to navigate VC++ Directories -> include directories to replace the path below with your actual path (in my side the path is: C:\VLD\Visual Leak Detector\include).
Then in library directories to replace the path below with your actual path (in my side the path is: C:\VLD\Visual Leak Detector\lib\Win32).
Same steps to add the path in debug|win64 - Microsoft.Cpp.Win32.user. please note the library path is C:\VLD\Visual Leak Detector\lib\Win64.
Go to C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow\Extensions\Cpp (This is my installation path for my Visual Studio 2017).
- Copy (overwrite) \dbghelp.dll to D:\Apps\x86\Visual_Leak_Detector\bin\Win32
- Copy (overwrite) \x64\dbghelp.dll to D:\Apps\x86\Visual_Leak_Detector\bin\Win64
Run the program in Debug mode, and you can see the memory leak information in the output window.
Hope my solution is helpful for you. any update would like to hear from you.
Sincerely,
May
MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [email protected]
Thursday, February 14, 2019 8:13 AM
Thanks a lot for the extensive reply, this seems to be real helpful -- however, I still can't find the installers, not even on the codeplex link you provided. There is an archive available for download, containing source code (which, as I mentioned, I am failing to build) and much more (including a "releases" folder which contains file I cannot interpret). Is it possible the installers were moved? Virtually everything I find about vld forwards me to the vld github page. Any more ideas where I can find the installer? Thanks!
Thursday, February 14, 2019 8:16 AM
Hi rAigner,
Here is installer download link, please check it: https://github.com/KindDragon/vld/releases/tag/v2.5.1 .
May
MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [email protected]
Thursday, February 14, 2019 5:42 PM
Okay, this is embarrassing: seems like I was just too stupid to find it. I didn't expect I have to scroll past older versions all to the bottom to get to the installer of the current version. THANKS!! Anyways, it's now safely stored in my OneDrive for the future ;)
Friday, February 15, 2019 8:26 AM
Hi friend,
that’s fine and I am happy to share my experience and offer any little favor to you J.
if my reply is helpful and solved your issue, please mark it as answer. You know that, other members need to solve same issue, could find our discussion quickly.
After that, I will help you close this issue.
Thank you for your understanding.
May
MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [email protected]
Friday, February 15, 2019 10:55 AM
Microsoft recommends against customizing properties through the .user files. From Working with Project Properties
".user files and why they are problematic
Past versions of Visual Studio used global property sheets that had a .user file name extension and were located in the <userprofile>\AppData\Local\Microsoft\MSBuild\v4.0\ folder. We no longer recommend these files because they set properties for project configurations on a per-user, per-computer basis. Such "global" settings can interfere with builds, especially when you are targeting more than one platform on your build computer. For example, if you have both an MFC project and Windows Phone project, the .user properties would be invalid for one of them. Reusable property sheets are more flexible and more robust.
Although .user files are still installed by Visual Studio and participate in property inheritance, they are empty by default. The best practice is to delete the reference to them in Property Manager to ensure that your projects operate independently of any per-user, per-computer settings This is important to ensure correct behavior in a SCC (source code control) environment."
A custom property sheet for vld usage would be easy to create and simple to use for any project where vld is desired.