martes, 29 de noviembre de 2011 9:56
I know how to do a code coverage analysis if the component was compiled with the /Profile switch. But the problem is...
I have a huge set of EXEs and DLLs with their corresponding PDBs and source code. These were not compiled with the /PROFILE switch. Is there a way to instrument and do a code coverage analysis of the code without having to recompile all the binaries?
- Cambiado Jack Zhai - MSFTMicrosoft Contingent Staff, Moderator miércoles, 30 de noviembre de 2011 5:47 (From:Visual Studio Debugger)
Todas las respuestas
miércoles, 30 de noviembre de 2011 6:27Moderador
Welcome to the MSDN forum!
Would you mind letting us know what language are you using?
Do you mean that first of all your project must be compiled using the /PROFILE link option? If we bring up the project properties it can be found here:
Configuration Properties -> Linker -> Advanced -> Profile
Another way to get code coverage report, we can create a test, then double-click local.testSetings ( it called LocalTestRun.testrunconfig in VS2008 ) in Solution Explorer to open the properties for the file, then we can obtain code coverage information in Visual Studio, like following screen shot. For detailed steps, see “Tutorial: Generating a Code Coverage report from within the IDE” in this link: http://msdn.microsoft.com/en-us/library/dd299398(v=vs.90).aspx.
Jack Zhai [MSFT]
MSDN Community Support | Feedback to us
miércoles, 30 de noviembre de 2011 10:10
If you want to instrument a large set of Assemblies at once, the VSInst command line utility might be the easiest option:
My blog: blog.jessehouwing.nl
jueves, 01 de diciembre de 2011 9:09
Sorry for not giving enough information.
Like always, the entire code is divided into multiple components ( EXEs and DLLs) each getting developed in different parts of the world. Some are COM services and some are .net components too. About 80% to 90% of the code is in VC++ ( MFC ). I am currently worried only about the VC++ portion.
There is a build machine in a remote place which compiles the entire code and send us the output files( EXE, DLL), their PDB files and the entire source code. We use this while debugging. Now, I cant open the project and change the Linker options of all the workspace/project files. It will take days to complete it. And even if I still do it, I would have to create 2 separate builds every time, one for existing user and one for me doing the code coverage analysis.
I need a better way to do it.
jueves, 01 de diciembre de 2011 11:26
It should be possible to link your native dlls after the fact using the link.exe command. It looks like you should be able to just run Link.exe with the /PROFILE option from the commandline. But I haven't tried this myself.
After running link, you should then procede to run VsInstr to instrument the application.
My blog: blog.jessehouwing.nl
jueves, 01 de diciembre de 2011 16:11
Forgive me for being blunt, but why are you bothering?
There is little (or, I would argue no) value to profiling, instrumenting, or analyzing code if you are not able or willing to recompile it. The purpose of performing any analysis is to identify potential trouble spots where the code can be improved. If it cannot be, then what's the point?
jueves, 01 de diciembre de 2011 18:36You can use DotTrace. You can profile your binaries if they are already compiled but If you modify the code you will need to recompile.
- Propuesto como respuesta Jia Xuan 2010 lunes, 05 de diciembre de 2011 8:31
viernes, 02 de diciembre de 2011 3:50
I would if I could. It takes about 1/2 day to compile the source codes and get a build. We have a huge code base. This build will be used by developers and testers everyday.
I dont want to create 2 builds everytime- One for normal users and one for us, the team doing the analysis. I am planning to automate (as much as possible )the various profiling and performance analysis and give reports for the builds being created.
lunes, 05 de diciembre de 2011 8:31
I don't have any good idea, but I think you could try as everyone's idea, maybe it is better than your. Maybe your idea can't make true, because as I know, if we want to get get code coverage, we have to call the .exe or .dll file. Then call your code with it.