• 1 reply
  • Latest Post - ‏2011-05-10T16:40:16Z by SystemAdmin
2 Posts

Pinned topic Scanning Binaries Built on Different Machine

‏2011-04-27T19:11:38Z |
When we initially began our static analysis code scanning process, our code was being built on the same machine that scanning took place. So, when scanning our .NET assembly projects, all sources pointed back to a local directory.

Recently, we've migrated to TFS and builds are occurring on a separate machine. The problem is now all of the source locations in AppScan Source point to a drive mapping that doesn't exist on the code scanning machine. This impacts our ability to inspect scan results. We've tried defining a variable, but this seems to need resetting after every scan.

Is there a best practice for handling source mappings when scanning .NET assembly projects?
  • SystemAdmin
    49 Posts

    Re: Scanning Binaries Built on Different Machine


    We passed this question around internally and it sounds like you were taking the correct approach: setting a variable to abstract away the relative source root on the TFS server.

    We have a couple of guesses about what might be going wrong.
    1. Are you re-creating the project every time? That might cause the variable to reset depending on how the configuration is done.
    2. Does the variable refer to code on another physical volume? I'm not exactly sure how it could happen, but I was thinking that once the variable is applied we attempt to refer to the code via a relative path, which cannot span volumes (drive letters) on Windows.

    Ultimately, I think the best approach is to contact support. Setting up a screen sharing session sounds like the simplest way to troubleshoot the issue (or investigate it as a possible feature request if that's appropriate).

    My apologies for not having a more concrete answer for you!