Search gotdotnet for:
GotDotNet User Sample: CoverageEye.NET

   GotDotNet User Samples will be up and running - further update in Fall, 2007
   We will not phase out User Samples until we can provide customers with a great alternative. We will update you with futher schedule information in Fall, 2007.
 
 

   The GotDotNet site is being phased out

   Microsoft will be phasing out most features of the GotDotNet site by July 2007.
      
  • More about the GotDotNet phase-out
  • Contact the GotDotNet Support Team
  •  
     

    Return to User Samples home

    CoverageEye.NET
    Uploaded by Stuart_Richardson
     
    Description CoverageEye.NET is a Microsoft Windows application that analyzes managed assemblies and reports information about the IL instructions that have been executed. At the core of CoverageEye.Net is a COM component that was written to work against the .NET profiling API. CoverageEye can be automated to work against your build process and provide code coverage percentages for your assemblies. It works at an IL level, so it works with all .NET languages. CoverageEye also color codes your source code so you can view which lines have been executed. Source code is not needed to run the tool. If source code is not available, you still get coverage information for your assemblies. Extract and install the Microsoft.Sdc.CoverageEye.Install.msi from the downloaded zip file. The application requires MSXML 4 sp2. A shortcut is placed on your programs menu to the application, and to the "Getting Started Guide."
    Downloads 8640 Target audience Beginner
    Uploaded date 2/19/2004 Edited date 3/19/2004
    Technologies
  • .NET Compact Framework
  • Web Services
  • ADO.NET
  • .NET Framework
  • Windows Forms
  • Remoting
  • ASP.NET

  • Languages
  • VB.NET
  • C#
  • J#


  • Rating for CoverageEye.NET
    Rate this resource
     
    Overall rating Number of votes 37

    Comments
    The comments below are provided by GotDotNet users and in no way reflect the opinions of Microsoft Corporation and/or the GotDotNet team.
    Posted by  
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  02/20/2004 06:52:32


    is needed by this tool. It can be installed from http://www.microsoft.com/downloads/details.aspx?FamilyID=3144b72b-b4f2-46da-b4b6-c5d7485f2b42&DisplayLang=en

    Also: After you have run the application that you are performing code coverage on, the file you open in CoverageEye.NET is NOT the configuration file, but the log file that has been created.

    This is detailed in the getting started guide.

    Thanks
    Stuart.
    User Posts:
    3
    MSXML 4.0 Service Pack 2
    Posted on:  02/23/2004 07:14:52


    Nice work! Just a couple of comments, first the colors are horrible, I have to squint to see the yellow or the green... Maybe you could make this more of a configuable option!

    Also it would be good if I could view a summary for an entire module. At the moment I get this error when I select (for example) a module 'modGlobals':

    CoverageEye cannot display source code. The cause could be:

    - This function does not have any source code.
    - The .pdb file must be located in the same folder as the assembly.
    - The .pdb must have been produced (built) at the same time as the assembly.
    - The source code must be located in the same folder location on this machine that the assembly and .pdb were built from.

    Assembly Report can still be viewed.
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  02/23/2004 09:42:57


    Thanks for your feedback.
    Colours do need some work ... :-)
    Not sure I understand the summary point. What you should get in the Assembly Report tab, or just by opening the coverage report is the summary for the assembly that you have configured to get coverage information on.
    That summary is based on what got called in that assembly, in one process. If the assembly you are doing coverage on gets loaded into two processes, then you get two reports.
    I will have an MSBuild task to consolidate the two reports into one, but I cannot promise when. All the information to do this is in the coverage reports. You have the total number of IL instructions in the function, and which instructions got called. With a little bit of code you can merge any number of reports for the same assembly, write out a new report that is the union of the two, and then reload into CoverageEye.NET
    What I have not tested very well is multi module assemblies. You should actually get multiple report files for the same assembly if you have multiple modules in that assembly.
    What is modGlobals ?
    Does it have any code?

    Sometimes compilers emit IL that does not have a direct code mapping, and so you cannot view the code for the item. I have seen VB do this for a class derived from Windows.Form.Button

    Kind Regards,
    Stuart
    User Posts:
    3
    MSXML 4.0 Service Pack 2
    Posted on:  02/23/2004 10:11:06


    modGlobals is just a module I have with some global functions in it. I was trying to get an overall summary for my module, not just individual functions. There was nothing really special in the module, it was jsut a simple formless VB app that updated a database on a daily basis.

    Good work though, keep it up.
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  02/23/2004 11:42:52


    ah - I get it. Sorry...Yeah, the summary's are only at a function level, or assembly level in the assembly report tab.
    User Posts:
    1
    MSXML 4.0 Service Pack 2
    Posted on:  02/23/2004 14:33:42


    Hi Stuart,

    I'm interested in how your tool works. Does it inject IL into each method body, to keep track of which lines have been executed?

    Are you thinking of releasing source code too?

    Thanks,

    Kirk
    User Posts:
    1
    MSXML 4.0 Service Pack 2
    Posted on:  02/23/2004 17:37:58


    How well does this work with assemblies that contain a mixture of managed and unmanaged code?
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  02/24/2004 00:39:55


    Yes this is exactly what the tool does. All monitoring is at an IL level. CoverageEye.NET then maps the IL called to source lines. My current plan is to release the source code in the next month or so.
    Cheers

    Stuart.
    User Posts:
    2
    MSXML 4.0 Service Pack 2
    Posted on:  02/24/2004 11:06:21


    Great tool. I agree with the earlier post about the colors, they are hard on the eyes. The first thing I did with this is hook it to an nunit test I already had done. Unfortunately because of the way nunit is shadowcopying the assemblies CoverageEye won't/can't show me my source code. I had to create a dummy console app to test my class. Any chance of getting a work around for this?

    Thanks
    Tim
    User Posts:
    3
    MSXML 4.0 Service Pack 2
    Posted on:  02/24/2004 12:57:19


    Sure ... there is a real easy work around. Take the log file that got generated, and open it up for editing. Notepad will be just fine. Amend the path from the shadow copy directory to the bin\release or bin\debug ... or whatever the directory is. Open again in CoverageEye.NET, and you should get source colouring working fine.

    Stuart
    User Posts:
    3
    MSXML 4.0 Service Pack 2
    Posted on:  02/24/2004 12:59:05


    CoverageEye.NET only works on functions that get Jitted ... not un-managed code, so you will not get any coverage statistics from un-managed code in your assemblies.

    Stuart.
    Post edited by stuartri on 02/24/2004 13:38:46
    User Posts:
    2
    MSXML 4.0 Service Pack 2
    Posted on:  03/01/2004 11:58:48


    We see great potential for CoverageEye! Thanks for posting it. We hope to use it with our nunit test suite to be sure we have written test cases that cover all the code. While this won't make our code "bug-free", it might keep us honest :-)

    We are having a problem though. Some of our code is returning a System.InvalidProgramException when we run it with CoverageEye. Any ideas on what's happening?
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  03/02/2004 05:57:47


    Thanks ...Its great to think the tool can help you improve the quality of your software. Now for the not so good news ....
    The tool works by hooking into the JIT function of the CLR, and then replacing the functions original IL with an instrumented version of your IL. If this process goes wrong (which during dev/test happened a lot :-) ) you can get IL that is produced that is not valid.
    I have not seen an invalid program exception due to this reason for some time, but that does not mean that a bug does not exist... and my guess is that you have found one.
    Do you know which function is causing the problem?
    If you follow this up with me directly I can help you to narrow this down... help you with a workaround, or get this fixed.

    Regards,
    Stuart
    User Posts:
    2
    MSXML 4.0 Service Pack 2
    Posted on:  03/02/2004 06:21:47


    I've seen the invalid program issue as well. So far it has showed up in two places. In a section of code that passes a dataset to a private method and in another place where we are making an interop call to a COM component.

    Here is dataset offending call:
    CreateProfileTable(DataSet ds);
    The call never makes it into this method. It fails on the actual call.

    The dataset in question has been instantiated, but contains no tables or data.



    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  03/02/2004 07:47:58


    Can you send me directly the code for the method CreateProfileTable please.
    Regards,
    Stuart
    User Posts:
    2
    MSXML 4.0 Service Pack 2
    Posted on:  03/02/2004 14:34:54


    Stuart --- I sent along the code you requested. Have you received everything yet?
    Thanks again, Doug
    Post edited by DougClutter on 03/02/2004 14:37:03
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  03/04/2004 10:12:04


    yes I have your sample. It is a bug in CoverageEye. I also have some information, (its in the CalculateFromToUsingRangeName method, and is due to the 6th block in your switch statement - ThisMonthToDate) .. I will continue to look at it to get a fix.
    Stuart

    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  03/05/2004 06:58:43


    I have fixed the bug that you were seeing Doug, and I think yours is the same issue Tim. I have a private build that I can share with you, and I will re-post CoverageEye.NET with the fix.

    Thank-you both.

    The issue for those interested, was that switch branches that branched further than 256 bytes from the end of the switch table in IL were not being correctly calculated. (C++ Byte * -> unsigned int *) ..sorry !

    This will fix the issue.

    Kind Regards,
    Stuart

    User Posts:
    3
    MSXML 4.0 Service Pack 2
    Posted on:  03/11/2004 14:38:16


    I have tried this on two machines now and I cannot get anything to happen. I’ve tried a simple console application, read through the instructions, installed MSXML from the link provided, re-registered the CodeCoverage.dll etc… I’m not sure what I might be missing. Is there anyway to try and diagnose the problem?
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  03/12/2004 09:14:07


    Sorry to hear you cannot get this working Scott. I can help you. Send me a mail to stuartri@microsoft.com. I will try to help you get this working.
    User Posts:
    4
    MSXML 4.0 Service Pack 2
    Posted on:  03/12/2004 13:30:32


    I tried to start a new thread, but that doesn't seem possible. CoverageEye.NET seems quite cool, however I'm having trouble getting run our customised version of NUnit. 

    1) I'm not getting any feedback when I start coverage with the following configuration:
    <Assembly Owner="xxxxx" Description="Beagle Unit tests Assembly"
    AssemblyName="C:\darwin\xxxx\build\debug\test\beagletest.exe" ReportDirectory="c:\temp">

    it just fails silently - it would be nice if there was an output/console window that helped my debug the circumstances.

    2) The problem is almost certainly related to our test cases need to be run from the same directory they're found in (ie C:\darwin\xxxx\build\debug\test\). Is there any to force CoverageEye to launch from there?

    Thanks for the help - the tool looks quite interesting.
    Mark Levison
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  03/13/2004 00:45:08


    Mark,
    You need to change your AssemblyName="C:\darwin\xxxx\build\debug\test\beagletest.exe"
    to
    AssemblyName="beagletest.exe"
    then you should be fine.

    Regards,
    Stuart
    User Posts:
    3
    MSXML 4.0 Service Pack 2
    Posted on:  03/14/2004 23:44:56


    Hi Stuart

    I haven't been able to get any output from CoverageEye.NET.

    This is the configuration file that I'm using :

    <?xml version="1.0"?>
    <c:CoverageConfiguration xmlns:c="urn:CoverageConfiguration">
    <Assembly Owner="codecoverage@microsoft.com" Description="Test Assembly" AssemblyName="testapp.exe" ReportDirectory="c:\temp"></Assembly>
    </c:CoverageConfiguration>

    I've just compiled a small console app called textapp.exe, and run it after turning code coverage on, but don't get any output at all in my temp directory. Have I missed something here?

    I'm running on Windows Server 2003.

    Thanks.
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  03/15/2004 02:51:05


    Sorry to hear that Craig ... I will help you sort your issue. Email me at stuartri@microsoft.com
    It sounds like the environment variables are not being set for your process when it starts. These control if CodeCoverage is performed.
    If they are not set, then that is the problem, and I can help you figure out why these are not being set. In CoverageEye.NET start code coverage, and then start a new command prompt. So... Start CoverageEye.NET. Select start code coverage. from the start menu, select RUN and then type CMD and bring up the command promt. TYpe SET and get the list of environment variables. You should see Cor_Enable_Profiling and Cor_Profiler set to 1 and the GUID of the CoverageEye.NET profiler. If these are not set this is the issue. If they are, in your test add code to list the environment variables to see if they are set. If they are not set then you need to figure out why. If they are, then send me an email and I will send a debug version of CoverageEye.NET to figure out what the issue is.

    Kind Regards,
    Stuart
    User Posts:
    3
    MSXML 4.0 Service Pack 2
    Posted on:  03/15/2004 07:52:13


    Stuart, Craig & All:
    I had a similar problem to what Craig reported, where no output files were generated and I have solved it. The problem was that launched the testing exe's (NUnit, and other exes) from a custom shell named "Total Commander" and apparently any processes it spins up do not get the environment variables. Go get everything to run properly, I use Start>Run and enter cmd, navigate to the exe, and run it from the console. So long as I run from the console everything works fine. I also found, launching NUnit-gui from the start menu works fine too.
    Great Tool! Thanks Stuart!

    Scott Willeke
    User Posts:
    3
    MSXML 4.0 Service Pack 2
    Posted on:  03/15/2004 14:25:16


    Hi Stuart

    Many thanks for the post. I’ve run some tests on the environment variables as you pointed out.

    When I examine the environment variables in a dos shell I can see them fine – both Cor_Enabling_Profiling and Cor_Profile are set correctly. However, when I run my test application via VS.NET and list the environment variables to the console, they are not set, which explains why I’m not getting any output.

    I've just tried one other thing - I have run the exe directly rather than through VS.NET. In this case my environment variables were set, and the report was produced correctly.

    So for some reason it seems that the variables are not being set if you launch through VS.NET. No idea why but I can work around this for now.

    Thanks!
    User Posts:
    3
    MSXML 4.0 Service Pack 2
    Posted on:  03/15/2004 15:17:05


    I've had allot of success today with CoverageEye, no doubt a useful tool. However, I have noticed a few problems. For some assemblies the CoverageEye.exe cannot find the source code when I double click on a method in the treeview. I haven’t been able to determine exactly what circumstances this occurs under. I noticed the status bar says “The system cannot find the file specified”, and when I attached a debugger the exception occurs in Microsoft.Sdc.CoverageEye.SymbolStore.SymbolHelper.GetSymUnmanagedReader.

    I also noticed that in the temp folder it writes two xml files for one of my projects. When I open one of these files in CoverageEye, the treeview lists the classes of one of the dependent dll assemblies of the exe that is under coverage (the classes are listed without any namespaces, directly under the xxx.exe filename). The other xml file in the folder appears to be for the correct assembly and have the contents that I expect. I happen to run this project from NUnit, not sure if that’s related.

    Another thing I’d like to get working (admittedly I didn’t try very hard at all) is coverage on DLL’s loaded in the IIS process via ASP.NET. Any suggestions on this? If you haven’t done it I’ll be giving it a shot here in the next couple days, and I’ll let you know what happens.

    All in all CoverageEye is great!

    Scott Willeke
    http://blogs.pingpoet.com/overflow
    Post edited by ScottWilleke on 03/15/2004 15:18:50
    User Posts:
    3
    MSXML 4.0 Service Pack 2
    Posted on:  03/15/2004 15:32:15


    Hi Stuart

    I think I spoke too soon. I got the report generation fine working for my console application by doing what i mentioned in my previous post.

    However, the real thing that i want to analyse is an asp.net web app. I inserted the names of the assemblies that i wanted to analyse, but was getting no output again. So I did the same trick to see whether the environment variables were getting set - turns out in this case they are not being set regardless of whether i start the web site through the VS.NET IDE or through IE (bypassing VS.NET altogether).

    Can you suggest a way of how i might ensure that my environment variables are always correctly set?

    Thanks
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  03/16/2004 01:16:14


    So environment variables are inherited from the launching process. When you start code coverage via the CoverageEye.NET application it sets the environment variables at a system level. It then sends a broadcast message to the system to tell all the processes to update there environment variables that they have. The trouble is some processes do not respond to this message, one such example is the service control manager (SCM) that controls windows services. Consoles launched are another, however explorer does listen to this broadcast message, this is the reason why when you launch a new console its has the environment variables.

    So in IIS 6 it is the job of http.sys living in the kernel to spin up a new process as defined by assigning your app to an app pool. Will the environment variables get set correctly ??... I am not sure. What you can do is Start Code Coverage and then reboot the box. That will cause it probably work. It works for windows services.

    The reports get written when the process goes away, so you may need to recycle the app pool to get the results from the tests.
    I am sorry that this is a little difficult to get to work for some scenarios, but it is the only way to hook a profiler into a .Net process.
    I will do a little more research into the specifics around ASP.NET, but you can try the reboot option for now. Remember, that CoverageEye.NET will be hooked into all you .NET processes if you do this, so Stop Code Coverage and reboot when you are done.

    Kind Regards
    Stuart
    User Posts:
    2
    MSXML 4.0 Service Pack 2
    Posted on:  03/16/2004 10:05:58


    Nearly there ;) This is due to the Service Control Manager issue that you outlined at the start. If you use a tool like tlist.exe from the system debuggers you will see that your w3wp.exe is a child task of Service Control Manager e.g.

    E:\debuggers>tlist -t
    System Process (0)
    System (4)
     smss.exe (356)
      csrss.exe (492)
      winlogon.exe (524)
       services.exe (572)
        [..stuf removed..]
        inetinfo.exe (3680)
        svchost.exe (2556)
         w3wp.exe (3884)
       lsass.exe (584)

    For a various reasons Service Control Manager only refreshes its environment variables on startup. So, the only course of action is to start code coverage in CoverageEye.NET and then restart the machine. I have confirmed this works with a simple asp.net app. One gotcha, remember to verify that the app pool you are workign with has access to the reports destination e.g "c:\temp" for Default App Pool User.

    If you need any more help with this let me know.

    Cheers!

    -jim

    Software Design Engineer in Test - Microsoft Ltd
    User Posts:
    3
    MSXML 4.0 Service Pack 2
    Posted on:  03/17/2004 02:42:27


    Hi all,

    Amazing piece of software and free! I'm continously amazed with the altruism demonstrated by some folks. Congratulations Stuart. But as you might imagine, I'm not writing only to praise the goodness of the human race.

    I tried to instrument RssBandit (www.rssbandit.org), an open source rss aggregator, and when I launch the application I get the following exception:

    RSS Bandit 1.2.0.90 Unhandled Exception occurred on: 17-03-2004 10:22
    System.InvalidProgramException: Common Language Runtime detected an invalid program.
      at RssBandit.WinGui.Controls.CollapsiblePanels.CollapsiblePanel.UpdatePanelState()
      at RssBandit.WinGui.Controls.CollapsiblePanels.CollapsiblePanel.set_PanelState(PanelState value)
      at RssBandit.WinGui.Forms.WinGuiMain.InitializeComponent()
      at RssBandit.WinGui.Forms.WinGuiMain..ctor(RssBanditApplication theGuiOwner, FormWindowState initialFormState)
      at RssBandit.RssBanditApplication.StartMainGui(FormWindowState initialStartupState)
      at RssBandit.RssBanditApplication.Main(String[] args)

    All the environment variables are ok, I guess. This is what I see in the command window:
    Cor_Enable_Profiling=1
    Cor_Profiler={18656C37-035D-41CD-82C2-85DEF2DD5F7B}

    Edit: I forgot to mention the version of CoverageEye.Net: 1.1.1525.0

    Can anyone help me? I'm trying to persuade my team to use this tool, on a ongoing battle to increase the quality of our code.

    Thank you all
    Post edited by jhosm on 03/17/2004 02:44:25
    User Posts:
    2
    MSXML 4.0 Service Pack 2
    Posted on:  03/17/2004 03:42:05


    Hi,

    Thanks for the info, we will setup a repro and debug.

    Cheers!

    -jim
    User Posts:
    3
    MSXML 4.0 Service Pack 2
    Posted on:  03/17/2004 09:48:10


    Hi jhosm,

    Yeah sorry its a bug. I think I have it fixed now. If you send me a mail to stuartri@microsoft.com I will send you a private build of the CodeCoverage.dll to fix the issue. .. I will re-post the installer with the update once we have done a little more testing.

    Kind Regards,
    Stuart
    User Posts:
    4
    MSXML 4.0 Service Pack 2
    Posted on:  03/18/2004 13:28:38


    Stuart - it appears CodeCoverage.dll is causing me problems - even when I'm not trying to use it. When I run caspol -l now I get the following error:
    "Faulting application caspol.exe, version 1.1.4322.573, faulting module codecoverage.dll, version 1.0.0.1, fault address 0x0000639b."

    the call stack is:
       CodeCoverage.dll!1000639b()   
        CodeCoverage.dll!1000e284()   
        mscorjit.dll!79437586()   
        mscorjit.dll!794375b8()   
    .... (more available if you need it)

    When will you be releasing a new version?

    Mark Levison (levisonmark atlessspam hotmail com)
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  03/19/2004 01:19:25


    You need to make sure that you have turned off CoverageEye.NET. CoverageEye.NET will hook all managed processes until you do so. The only way that my codecoverage.dll would be in that process was if it was still enabled. Turn off CoverageEye.NET when you have finished profiling your application. If you are testing windows services, ASP.NET, etc, which require you to reboot the box to perfrom profiling, then you will need to Stop Code Coverage and reboot again ...(I know this is a pain, and Jim is investigating if he can solve the issue.)

    All of that said... it should not cause an error. I will look into it, I may need a dump file from you. I suggest you make sure that CoverageEye.NET is not enabled.

    Cheers...

    Stuart
    User Posts:
    3
    MSXML 4.0 Service Pack 2
    Posted on:  03/19/2004 01:27:41


    Hello all,

    Stuart, I'm happy to say that the build you sent me solves the problem. Keep up the good work!

    João

    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  03/19/2004 04:40:08


    Build 1538 has just been uploaded, with the fix.

    Regards
    Stuart
    User Posts:
    4
    MSXML 4.0 Service Pack 2
    Posted on:  03/23/2004 09:33:29


    Where do I find build 1538? I just tried the installer that I just downloaded via the link in the top left. It was build 1525. Just to be certain I deleted my copy of the old installer.

    Mark - still hoping for code coverage
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  03/24/2004 01:45:26


    Mark.... I just downloaded CoverageEye.NET, and the version that I downloaded is 1538... so it seems to be working now, or you have some other issue ??

    Kind Regards,
    Stuart
    User Posts:
    4
    MSXML 4.0 Service Pack 2
    Posted on:  03/24/2004 06:55:21


    Strange - now it is version 1538. I must of made a mistake - although I did delete the old copy before hand just to be sure.

    Off to write some unit tests.

    Cheers
    Mark
    User Posts:
    9
    MSXML 4.0 Service Pack 2
    Posted on:  03/24/2004 11:52:32


    Stuart - of all the tools that I've looked at, CoverageEye seems to be the most promising. Good job!

    I have two suggestions for you:

    1) To make it easier to automate coverage tests as part of a build, allow overriding the location of the configuration files via an environment variable. We're already dependent on env vars, and it's pretty easy to launch unit tests with an env var set just for that process. The flexibility this would add would, I think, be very helpful.
    2) I notice you're talking about releasing source. Having hosted several projects on GotDotNet and elsewhere, let me suggest that you look elsewhere. GotDotNet is unreliable, buggy, and slow as a project site. Lack of tool integration for things like continuous builds and automated builds is particularly crippling. I've used SourceForge with much better results, although I'm sure there are other capable sites. Just a suggestion - hoping to save you some pain so you can carry forward your project in the most successful manner possible.
    User Posts:
    9
    MSXML 4.0 Service Pack 2
    Posted on:  03/24/2004 12:45:52


    Just thought of another one:

    3) Allow overriding of the report location with an environment variable.
    User Posts:
    9
    MSXML 4.0 Service Pack 2
    Posted on:  03/25/2004 07:21:04


    And another one! (Can you tell I'm actually integrating it into the build now? :) )

    4) Put the reports XML into a namespace, to allow me to more easily merge it into a build log without having to worry about conflicts. Also, it would be cool to change the root element from 'root' to 'coverageEye', although that's not particularly necessary.
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  03/25/2004 07:22:29


    Thanks for your feedback.

    The configuration files are always located in a directory below the location of the CodeCoverage.dll. It just made it easy for the dll to locate it, but I understand your need for flexibility.

    After my experiences of env. variables though, and the problems associated with them not propagating through test tools, windows services, asp.net applications etc, it may prove difficult to implement reliably. The env. variables not being in processes is the number one reason why CoverageEye.NET fails to perfrom its job.

    As for GDN, I will pass your feedback onto the team. I know they listen to users comments, and I hope that we (Microsoft) can improve to meet your expectations. Thanks again for your feedback...

    Stuart.
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  03/25/2004 07:35:52


    The reports are always going to get conflicts. One report is generated for every instance of the dll that is loaded and jitted. If your dll is loaded in say two exe's as a result of your tests, you will get two reports. You will need to merge these to get a true reflection of the coverage. All the data is needed in the files to perform the merge.

    As a result of debugging João's issue I have noticed something interesting. You may get different numbers of IL instructions for the same exe ...Why. ..? Because some code like the XmlSerialiser will create code that attaches to your module.

    I do have an MSBuild task for merging reports, and will try and get this feature added in the next version.

    Stuart.
    User Posts:
    9
    MSXML 4.0 Service Pack 2
    Posted on:  03/25/2004 08:14:16


    Yeah, it's a tough problem: I've written a CLR profiler, and you're really pretty limited in your ability to pass information in to the profiler. Environment variables are one way. Your use of the registry is a clever one, but obviously suffers from the issue of being machine-global. That just seems like a real issue for a build tool. What I'm suggesting is a way to *override* the settings - keep the registry setup you have now, but allow me to override it with an environment variable. This, I believe, would give a reasonable solution for both nunit and service-based scenarios, which I suspect are your two main use-cases.

    Anyway, I understand writing this isn't your day job, and that you've been thinking about the problem a lot longer than I have. Just letting you know what I'm encountering as I integrate CoverageEye into our build.

    Oh, and I've already sent an email to Andy at GDN with my specific concerns. My feedback was meant more for you personally - hoping to save you pain when you get around to setting up the project on a public workspace somewhere. My experience has been that wrestling with the system eats a good 10% of the time I spend working on the systems, and that's time I'd rather spend adding features. Not to mention that it tends to lose changes if you're not careful.

    I've worked at MSFT with some of the people that implemented GDN, so I know they're definitely clever enough to get it right. I just don't think they have yet.
    User Posts:
    9
    MSXML 4.0 Service Pack 2
    Posted on:  03/25/2004 08:18:42


    Sorry if I wasn't clear: the conflicts I'm referring to would be conflicts between the XML in your coverage report file, and some other piece of XML that decided "root" made a good root element name. Because build tools like CruiseControl.net result in a single XML logfile that contains the output of all tools run by the build, being able to distinguish between coverage information and information from some other part of the build is necessary. Using an XML namespace is a near-zero-overhead way to accomplish this.

    As for the merge tool - that would be excellent. It won't be too hard to implement the merge myself, but having it built in to the tool is obviously far preferable.
    User Posts:
    1
    MSXML 4.0 Service Pack 2
    Posted on:  04/04/2004 15:33:03


    I am extremely interested in this application. 

    Any idea on when you might release the source code?

    I am having a problem using the tool though. I have been able to generate some xml reports, but don't seem to be able to view the source code (line by line) coverage.

    When I attempt to open a configuarion file I get the following error:

    ************** Exception Text **************
    System.NullReferenceException: Object reference not set to an instance of an object.
      at Microsoft.Sdc.CoverageEye.MainForm.LoadFile(String fileName)
      at Microsoft.Sdc.CoverageEye.MainForm.openAction()
      at Microsoft.Sdc.CoverageEye.MainForm.menuItem2_Click(Object sender, EventArgs e)
      at System.Windows.Forms.MenuItem.OnClick(EventArgs e)
      at System.Windows.Forms.MenuItemData.Execute()
      at System.Windows.Forms.Command.Invoke()
      at System.Windows.Forms.Control.WmCommand(Message& m)
      at System.Windows.Forms.Control.WndProc(Message& m)
      at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
      at System.Windows.Forms.ContainerControl.WndProc(Message& m)
      at System.Windows.Forms.Form.WndProc(Message& m)
      at System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m)
      at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m)
      at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


    ************** Loaded Assemblies **************
    mscorlib
      Assembly Version: 1.0.5000.0
      Win32 Version: 1.1.4322.573
      CodeBase: file:///c:/winnt/microsoft.net/framework/v1.1.4322/mscorlib.dll
    ----------------------------------------
    CoverageEye
      Assembly Version: 1.0.5000.0
      Win32 Version: 1.1.1538.0
      CodeBase: file:///C:/Program%20Files/Microsoft/Microsoft%20UK%20SDC%20CoverageEye.NET%201.1.1538.0/CoverageEye.exe
    ----------------------------------------
    System.Windows.Forms
      Assembly Version: 1.0.5000.0
      Win32 Version: 1.1.4322.573
      CodeBase: file:///c:/winnt/assembly/gac/system.windows.forms/1.0.5000.0__b77a5c561934e089/system.windows.forms.dll
    ----------------------------------------
    System
      Assembly Version: 1.0.5000.0
      Win32 Version: 1.1.4322.573
      CodeBase: file:///c:/winnt/assembly/gac/system/1.0.5000.0__b77a5c561934e089/system.dll
    ----------------------------------------
    System.Drawing
      Assembly Version: 1.0.5000.0
      Win32 Version: 1.1.4322.573
      CodeBase: file:///c:/winnt/assembly/gac/system.drawing/1.0.5000.0__b03f5f7f11d50a3a/system.drawing.dll
    ----------------------------------------
    interop.AxSHDocVw
      Assembly Version: 1.1.0.0
      Win32 Version: 1.1.0.0
      CodeBase: file:///C:/Program%20Files/Microsoft/Microsoft%20UK%20SDC%20CoverageEye.NET%201.1.1538.0/interop.AxSHDocVw.DLL
    ----------------------------------------
    System.Xml
      Assembly Version: 1.0.5000.0
      Win32 Version: 1.1.4322.573
      CodeBase: file:///c:/winnt/assembly/gac/system.xml/1.0.5000.0__b77a5c561934e089/system.xml.dll
    ----------------------------------------
    interop.shdocvw
      Assembly Version: 1.1.0.0
      Win32 Version: 1.1.0.0
      CodeBase: file:///C:/Program%20Files/Microsoft/Microsoft%20UK%20SDC%20CoverageEye.NET%201.1.1538.0/interop.shdocvw.DLL
    ----------------------------------------
    Accessibility
      Assembly Version: 1.0.5000.0
      Win32 Version: 1.1.4322.573
      CodeBase: file:///c:/winnt/assembly/gac/accessibility/1.0.5000.0__b03f5f7f11d50a3a/accessibility.dll
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  04/05/2004 01:39:53


    Do not open the configuration file with CoverageEye.NET. You need to drag the reports into the UI treeview, or using the File->Open dialog to navidate to the location of the reports that you set in the configuration file.

    Kind Regards
    Stuart
    User Posts:
    1
    MSXML 4.0 Service Pack 2
    Posted on:  04/08/2004 04:00:24


    Warning! You're shipping and installing another copy of msxml4.dll.

    After installing CoverageEye.Net I got this: C:\Program Files\Microsoft\Microsoft UK SDC CoverageEye.NET 1.1.1538.0\msxml4.dll registered on my machine.

    It was interfering with our comercial product builds till I spotted it and re-registered the correct one in system32

    Matt
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  04/08/2004 05:12:56


    Thanks Matt- I will check why this is in the installer, and remove.
    User Posts:
    9
    MSXML 4.0 Service Pack 2
    Posted on:  04/08/2004 08:36:12


    I wrote a tool that merges coverage files together. I have permission to open-source it. Where would you like me to put it?
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  04/08/2004 10:00:26


    Sounds great! Post it as a user sample with the code, and place a link from this thread. I also have some msbuild tasks that do the same, and will post those when the next version of whidbey ships.

    Stuart
    User Posts:
    3
    MSXML 4.0 Service Pack 2
    Posted on:  04/16/2004 11:56:43


    Note that uninstalling this application actually removed my MSXML 4.0 files from my system - when they were still being used by other applications. Please check your un-installation so that it will not do this for others in the future.

    thanks

    Sam
    User Posts:
    1
    MSXML 4.0 Service Pack 2
    Posted on:  04/29/2004 13:29:40


    Is it possible to use this tool to get coverage on assemblies located in the GAC? If not, does anyone know of any tools that would allow me to do that. 
    User Posts:
    1
    MSXML 4.0 Service Pack 2
    Posted on:  05/11/2004 03:06:29


    Graig,

    You will notice that you mention the AssemblyName="testapp.exe" and that you have just compiled an app called textapp.exe. The difference in the name will be the probable cause of your problem.

    Cheers
    Andrew Jones
    User Posts:
    9
    MSXML 4.0 Service Pack 2
    Posted on:  05/12/2004 11:19:46


    I finally got around to posting the tool I wrote to merge CoverageEye.NET report files. It's not showing up on the user samples page yet, so I can't post a link, but it should be there before long. The tool is called cemerge, and I've included the readme in this post. Ping me if you have any problems with it.

    ==================

    Usage: cemerge <output> <dir> <file1> [ <file2> ... ]

     output  : The path to merged XML file that will be created
     dir   : The path to the assemblies in the report file will be changed
           so that it seems like they live in this directory
     file<n> : The unmerged input files
     
    CEMerge is intended to merge report files output of the
    CoverageEye.NET code coverage tool (available at
    http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=881a36c6-6f45-4485-a94e-060130687151).

    CoverageEye.NET is an excellent tool, but has the problem that
    multiple runs against the same assembly produce multiple
    report files. Each of these reports represents coverage information
    for *that particular run*, which is not helpful in getting a picture
    of overall code coverage.

    Additionally, CoverageEye.NET records the full path of the assembly at
    the time the coverage data was gathered. While this may not be a
    problem in many situations, it is problematic when using NUnit
    (http://nunit.sourceforge.net) to generate coverage data, as NUnit
    copies assemblies to a shadow directory that is created specifically
    for that run of the assembly. This precludes using the report to
    display code coverage against source code, as the CoverageEye.NET
    tool cannot display source when the assembly cannot be found at the
    location in the report file.

    CEMerge addresses both of these problems by combining and rewriting
    multiple reports into a single report file, while also changing the
    assembly paths to a directory of your choosing.

    CEMerge uses the filename part of the assembly path to determine
    assembly identity. That is, if it finds one assembly called
    "C:\foo\bar\blah.dll" and another called "C:\this\that\blah.dll", it
    will assume they are the same assembly and merge the coverage data.

    I am using CEMerge in my production builds, so it's good enough to go
    on with, but probably doesn't do everything you'd like. Feel free to
    modify the code to meet your needs, and consider posting your changes
    if you add something worthwhile.

    -Craig Andera
    candera@wangdera.com
    May 12th, 2004.
    User Posts:
    2
    MSXML 4.0 Service Pack 2
    Posted on:  05/14/2004 06:57:32


    I have been trying to get CoverageEye.NET to work on my dev box and my build box with no luck. When I try to load any configuration file I ge the following error.

    See the end of this message for details on invoking
    just-in-time (JIT) debugging instead of this dialog box.

    ************** Exception Text **************
    System.NullReferenceException: Object reference not set to an instance of an object.
      at Microsoft.Sdc.CoverageEye.MainForm.LoadFile(String fileName)
      at Microsoft.Sdc.CoverageEye.MainForm.openAction()
      at Microsoft.Sdc.CoverageEye.MainForm.toolBar1_ButtonClick(Object sender, ToolBarButtonClickEventArgs e)
      at System.Windows.Forms.ToolBar.OnButtonClick(ToolBarButtonClickEventArgs e)
      at System.Windows.Forms.ToolBar.WmReflectCommand(Message& m)
      at System.Windows.Forms.ToolBar.WndProc(Message& m)
      at System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m)
      at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m)
      at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

    If I click to continue through the error the assembly name is shown in the tree view but is not expandable. No report is generated if I start coverage and run the subject assembly.

    Thanks,
    Jay
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  05/14/2004 09:20:40


    Do not open the configuration file with CoverageEye.NET. You need to drag the reports into the UI treeview, or using the File->Open dialog to navidate to the location of the reports that you set in the configuration file.

    Kind Regards
    Stuart
    User Posts:
    1
    MSXML 4.0 Service Pack 2
    Posted on:  08/19/2004 04:35:11


    I tried this tool and I find it very good, I am trying to use it in our nightly test suite but I have two problems that prevent me from doing it currently.
    When I launch some application (written in c#) with coverage enabled I got an pop up window on when the application that the runtime requested the application to end in an unusual way. It is not easily replayable but when it occurs it locks the test suite. Any Idea where it comes from?

    We also have some test wich uses ASP.NET. The coverage works fine with a reboot but as we intend to run the test suite on our test server it is quite annoying. Is there a less disrupting way to have coverage on ASP.NET tests?

    regards
    Maxime
    User Posts:
    4
    MSXML 4.0 Service Pack 2
    Posted on:  08/23/2004 02:11:25


    Hi,

    I have been trying to integrate this tool with NAnt to test the coverage of NUnit test cases. I have a question - Should we specify the name of the executable or can I also specify names of dll files in the assembly list (in the config file).

    I have not been able to get any reports when I specify only .dll file names. I do get a coverage report when I specify nunit-gui.exe as the assembly name, but this contains coverage info for nunit and not my assembly.

    Any help will be greatly appreciated.

    Thank u,
    pradeep
    User Posts:
    4
    MSXML 4.0 Service Pack 2
    Posted on:  08/23/2004 02:24:41


    This is my config file:

    <?xml version="1.0"?>
    <c:CoverageConfiguration xmlns:c="urn:CoverageConfiguration">
       <Assembly Owner="abcd@xyz.com" Description="Test Assembly t" AssemblyName="xmlservicestest.dll" ReportDirectory="C:\TEMP\ic\"></Assembly>
    </c:CoverageConfiguration>

    Does CoverageEye work with class libraries as well? Do we explicitly need a console app to analyse the code coverage using this tool?
    Post edited by Pradeep_MCSD on 08/23/2004 02:25:29
    User Posts:
    4
    MSXML 4.0 Service Pack 2
    Posted on:  08/25/2004 06:30:34


    I have been desperately trying to get this tool running, but with no luck :(
    This is my config file:

    <?xml version="1.0"?>
    <c:CoverageConfiguration xmlns:c="urn:CoverageConfiguration">
       <Assembly Owner="ballaln@ttt.com" Description="cxp controller classes" AssemblyName="cxpvc.dll" ReportDirectory="C:\TEMP\CEReports\"></Assembly>
    </c:CoverageConfiguration>

    I start NUnit after I have started CoverageEye.NET and run the tests that test the classes inside cxpvc.dll. When the tests are finished I open the folder (with great anticipation)...but find nothing.

    Is anything wrong with what I am doing? I am trying to get my developers to use this - but need to know how to get it working.

    Please help...
    Post edited by Pradeep_MCSD on 08/25/2004 06:39:48
    User Posts:
    4
    MSXML 4.0 Service Pack 2
    Posted on:  09/07/2004 00:25:27


    Hi,

    No replies?? Can anyone hear me?

    Cheers,
    Pradeep
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  09/07/2004 00:51:16


    It looks fine to me. It sounds like the profiler is not started. Add some debug code to your test dll to dump out the environment variables. You are looking for cor_enable_profiling to set to 1 and cor_profiler to be set to a guid. (the CoverageEye guid) Try this and get back to me.

    Stuart
    User Posts:
    9
    MSXML 4.0 Service Pack 2
    Posted on:  09/07/2004 07:49:33


    Problem using CoverageEye on Windows 2000.

    We've recently moved our build to a Windows 2000 machine. When we run code coverage as part of the build, we get the error, "Fatal execution engine error" from NAnt. I've tracked this down, and I believe it to be a result of a dependency on shlwapi.dll, which in turn imports ApphelpCheckShellObject from AppHelp.dll. This appears from http://bugs.php.net/bug.php?id=14464 to be a problem with other applications as well, and appears to stem from some weirdness around differences between those DLLs in XP and 2000. I assume the tool was built on an XP or 2003 machine.

    Any advice?
    User Posts:
    1
    MSXML 4.0 Service Pack 2
    Posted on:  09/14/2004 11:47:08


    I'm trying to get CoverageEye working, and I'm not having any success. Here's my config file:

    <?xml version="1.0"?>
    <c:CoverageConfiguration xmlns:c="urn:CoverageConfiguration">
    <Assembly Owner="lakeman@somewhere.com" Description="LaunchApp" AssemblyName="launchapp.exe" ReportDirectory="c:\temp"></Assembly>
    <Assembly Owner="lakeman@somewhere.com" Description="dataimport" AssemblyName="somewhere.something.dataimport.dll" ReportDirectory="c:\temp"></Assembly>
    </c:CoverageConfiguration>

    The documentation states that the assembly name needs to be in all lowercase. Do the filenames of my dll on the filesystem have to match and be in lowercase as well?
    I changed my exe filename from LaunchApp.exe to launchapp.exe but that didn't get it working either.
    I printed out my environment variables and could not find cor_enable_profiling or cor_profiler.

    Any suggestions?

    Brian
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  09/15/2004 01:56:56


    Not sure .. The Coverage dll does no use this (I think) so I am not sure why you are getting this error. I am releasing a new version really soon .. it will include lots of new features, like automatic support for services and web services, but the package will have the source code, so you can debug. I am trying to get it out ASAP but I have other commitments.

    Stuart
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  09/15/2004 02:00:32


    Blakeman, you config look ok. You need to Start Code Coverage and then start a new console window from explorer... STart -> Run -> cmd
    Look for the environment variables. If they are not there then CoverageEye.NET will not get hooked into your process. If they are there then run you exe from that cmd window. When your process exits you will get the reports. If your process exits due to an exception then no report will get written.

    STuart
    User Posts:
    36
    MSXML 4.0 Service Pack 2
    Posted on:  09/24/2004 04:36:23


    I have just uploaded the new version of CoverageEye.NET - 2.0
    I have submitted it as a new sample with just the installer, but I have created a workspace for it at :
    http://www.gotdotnet.com/workspaces/workspace.aspx?id=4d56495b-0799-4ede-898f-7f07637d2dfc
    The source code is available in the zip, but I hope you all join and contribute to the shared source.
    The new features include support for Web Services, Asp.NET apps and Windows services WITHOUT a reboot :-)
    Also improved config management interface (not notepad) .. and a sample showing how to integrate into a build environment. I am sure bugs exist, but now you can fix them rather than wait for a provate build from me.
    Thanks
    Stuart
    User Posts:
    9
    MSXML 4.0 Service Pack 2
    Posted on:  09/24/2004 04:42:31


    Congrats, Stuart! I know how hard it is to get something out the door. I'm looking forward to the new features.
    User Posts:
    4
    MSXML 4.0 Service Pack 2
    Posted on:  07/13/2005 14:36:03


    First of all this is an excellent tool. 

    Second, I have an issue. It seems that any method with a C# foreach statement in it does not reach 100% coverage. The opening parenthesis that directly follows the foreach does not turn green and I end up with 92 or 93 percent coverage depending on how much code I have in the method.

    You can use the money example that comes with NUnit to replicate this. Methods such as FindMoney, Multiply and GetHashCode on the MoneyBag class fall into this situation.
    User Posts:
    1
    MSXML 4.0 Service Pack 2
    Posted on:  08/24/2005 13:14:11


    Is this tool available for code coverage of .net 2.0 (whideby). If not do you know of any tool taht would do this?
    User Posts:
    1
    MSXML 4.0 Service Pack 2
    Posted on:  10/21/2005 03:23:40


    Hi!

    I have installed CoverageEye.NET 2.0 on my system with WIn2k Professional and VS.NET 2003. I am not able to generate when i am DLL as the assembly.

    Is there any other settings need to be done to check the code coverage for ASP.NET Application using CoverageEye.NET 2.0?

    Thanks,
    Baren
    User Posts:
    1
    MSXML 4.0 Service Pack 2
    Posted on:  05/24/2006 10:41:29


    I having this problem <br/>See the end of this message for details on invoking <br/>just-in-time &#40;JIT&#41; debugging instead of this dialog box.<br/><br/>&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42; Exception Text &#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;<br/>System.NullReferenceException&#58; Object reference not set to an instance of an object.<br/>&#160; at Microsoft.Sdc.CoverageEye.MainForm.LoadFile&#40;String fileName&#41;<br/>&#160; at Microsoft.Sdc.CoverageEye.MainForm.openAction&#40;&#41;<br/>&#160; at Microsoft.Sdc.CoverageEye.MainForm.menuItem2_Click&#40;Object sender, EventArgs e&#41;<br/>&#160; at System.Windows.Forms.MenuItem.OnClick&#40;EventArgs e&#41;<br/>&#160; at System.Windows.Forms.MenuItemData.Execute&#40;&#41;<br/>&#160; at System.Windows.Forms.Command.Invoke&#40;&#41;<br/>&#160; at System.Windows.Forms.Control.WmCommand&#40;Message&#38; m&#41;<br/>&#160; at System.Windows.Forms.Control.WndProc&#40;Message&#38; m&#41;<br/>&#160; at System.Windows.Forms.ScrollableControl.WndProc&#40;Message&#38; m&#41;<br/>&#160; at System.Windows.Forms.ContainerControl.WndProc&#40;Message&#38; m&#41;<br/>&#160; at System.Windows.Forms.Form.WndProc&#40;Message&#38; m&#41;<br/>&#160; at System.Windows.Forms.ControlNativeWindow.OnMessage&#40;Message&#38; m&#41;<br/>&#160; at System.Windows.Forms.ControlNativeWindow.WndProc&#40;Message&#38; m&#41;<br/>&#160; at System.Windows.Forms.NativeWindow.Callback&#40;IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam&#41;<br/><br/><br/>&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42; Loaded Assemblies &#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;&#42;<br/>mscorlib<br/>&#160;&#160;Assembly Version&#58; 1.0.5000.0<br/>&#160;&#160;Win32 Version&#58; 1.1.4322.2032<br/>&#160;&#160;CodeBase&#58; file&#58;&#47;&#47;&#47;c&#58;&#47;windows&#47;microsoft.net&#47;framework&#47;v1.1.4322&#47;mscorlib.dll<br/>----------------------------------------<br/>CoverageEye<br/>&#160;&#160;Assembly Version&#58; 1.0.5000.0<br/>&#160;&#160;Win32 Version&#58; 1.1.1538.0<br/>&#160;&#160;CodeBase&#58; file&#58;&#47;&#47;&#47;C&#58;&#47;Program&#37;20Files&#47;Microsoft&#47;Microsoft&#37;20UK&#37;20SDC&#37;20CoverageEye.NET&#37;201.1.1538.0&#47;CoverageEye.exe<br/>----------------------------------------<br/>System.Windows.Forms<br/>&#160;&#160;Assembly Version&#58; 1.0.5000.0<br/>&#160;&#160;Win32 Version&#58; 1.1.4322.2032<br/>&#160;&#160;CodeBase&#58; file&#58;&#47;&#47;&#47;c&#58;&#47;windows&#47;assembly&#47;gac&#47;system.windows.forms&#47;1.0.5000.0__b77a5c561934e089&#47;system.windows.forms.dll<br/>----------------------------------------<br/>System<br/>&#160;&#160;Assembly Version&#58; 1.0.5000.0<br/>&#160;&#160;Win32 Version&#58; 1.1.4322.2032<br/>&#160;&#160;CodeBase&#58; file&#58;&#47;&#47;&#47;c&#58;&#47;windows&#47;assembly&#47;gac&#47;system&#47;1.0.5000.0__b77a5c561934e089&#47;system.dll<br/>----------------------------------------<br/>System.Drawing<br/>&#160;&#160;Assembly Version&#58; 1.0.5000.0<br/>&#160;&#160;Win32 Version&#58; 1.1.4322.2032<br/>&#160;&#160;CodeBase&#58; file&#58;&#47;&#47;&#47;c&#58;&#47;windows&#47;assembly&#47;gac&#47;system.drawing&#47;1.0.5000.0__b03f5f7f11d50a3a&#47;system.drawing.dll<br/>----------------------------------------<br/>interop.AxSHDocVw<br/>&#160;&#160;Assembly Version&#58; 1.1.0.0<br/>&#160;&#160;Win32 Ver
    Post edited by dmurillo on 05/24/2006 10:46:37


    [Printer friendly version]
    © Copyright 2008 Microsoft Corporation. All Rights Reserved.
    Terms of Use | Privacy Statement | Code of Conduct | About the team | Contact Us