App-V'ed program knows it's running in c:\programdata\microsoft\appv\guid

Question

I have a package for some software called RelayCare.  It sequences fine, and the package runs, 99% of the functionality works.
One part does not work - there's a .rpt viewer built in, might be Crystal, not 100% sure.  The rpt files regularly get updated so I do not want them in the package.
The primary application virtual directory is c:\program files (x86)\relaycare
In relaycare\cecclient\reports, those .rpt files sit.
So, if I delete the folder when packaging, the report folder gets excluded.  
I can copy the files to the local PC running the published appv package, to c:\program files(x86)\relaycare\cecclient\reports
The app, however, does not see the files.  When I try to run a report, it says xxx.rpt file not found in c:\programdata\microsoft\appv\guid\root\relaycare\cecclient\reports 
How the heck does it know where it's running? 
If I run cmd /appvve:guid_vid, I can see that the files are merging properly in 
c:\program files(x86)\relaycare\cecclient\reports - the local folder is taking precedence as desired
Long story short, how does this app know about the c:\programdata folder, is that avoidable, so it looks in the right place for the reports?  
If it's not avoidable, can the appv programdata package folder have files dropped in there?  If I try - I get permission denied even as an administrator.  
The .rpt files really can't go into the package, they change too much.
Figured I'd try to ask here, I'm out of ideas...
Thanks!

Answer 1

Is there a setting that you know of to change the report directory?  What do you do in a traditional install?  Do you ACL the report folder for the user and they can drop in new reports whenever they want?  Do you not have to update the package
now when the reports update?
Even though App-V sets up a virtual environment, that doesn't mean an exe can't know where it is.  I believe the term is called  reflection, but if the exe basically asks where it is, it gets the literal path, ie C:\Programdata\....
What could be happening is the exe is always assuming that a subfolder (a relative path) to itself has the reports.
If you can package the software to VFS that may solve the issue... I don't know off the top of my head if App-V redirects calls made to the non-virtualized path (C:\Programdata\....\root\VFS\PROGRAMFILES86 as a bad example) and treats them like calls made
to the VE.   My gut is no, that if the app tries to write that way it will get an access denied it has to go to the virtualized path of C:\Program Files (x86)\....
Also about including the reports in the package... how are users expected to update the report files?  If the user typically (for example) goes into Windows explorer, and drags new report files into the dir that won't be user friendly anymore.
However if the software itself has an import where the user selects new files and then the program puts them where it wants, that may work.
Obviously this is all theoretically speaking, my main point is you have to consider the user interaction that is appropriate before you can determine what you do next.  A good place to start that conversation is what do they do normally, outside of
App-V.  People have had success create a junction point inside the VE to redirect reads/writes to a different location.  I haven't done so myself but that may also help you out.
Worst come to worst, you might be able to drop the exe onto the real file system, and treat it like an outside application.  We had to do this for an app with a similar problem...it wanted to write to a subfolder and used its own current directory as the
starting point, and you can't write to C:\Programdata\...
We used the Add package scripting to drop the exe 'outside', and because the exe is now outside, App-V will create the shortcut like app.exe /appvve:guid_vid, and if the exe looks at its own location it will see where you drop it to, not the virtualised
path.
EDIT: Just thought of this...I wonder if you could use a shim to trick the app into believing it is launching from C:\Program Files instead of the C:\Programdata location.