Profiling binaries already created

Question

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?

 

 

Answer 1

Hi Vijay,

 

Welcome to the MSDN forum!

Would you mind letting us know what language are you using?

 

Like step1 in this link http://blogs.msdn.com/b/cellfish/archive/2008/11/16/native-c-code-coverage-reports-using-visual-studio-2008-team-system.aspx

 

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.

 

 

Thanks,

---

Jack Zhai [MSFT]
MSDN Community Support | Feedback to us

Answer 2

If you want to instrument a large set of Assemblies at once, the VSInst command line utility might be the easiest option:

http://msdn.microsoft.com/en-us/library/ms182402.aspx

---

My blog: blog.jessehouwing.nl

Answer 3

Hi all..

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. 

 

 

 

 

---

Vijay Praveen

Answer 4

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

Answer 5

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?

Evan

Answer 6

You can use DotTrace. You can profile your binaries if they are already compiled but If you modify the code you will need to recompile.

---

aelassas.free.fr

Answer 7

@Evan:

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.

---

Vijay Praveen

Answer 8

Hi,

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.