Topic
IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
1 reply Latest Post - ‏2011-05-10T16:40:16Z by SystemAdmin
littonuser
littonuser
2 Posts
ACCEPTED ANSWER

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?
Updated on 2011-05-10T16:40:16Z at 2011-05-10T16:40:16Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    49 Posts
    ACCEPTED ANSWER

    Re: Scanning Binaries Built on Different Machine

    ‏2011-05-10T16:40:16Z  in response to littonuser
    Hello,

    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!

    /eh