Hi All ,

One of my application shortcuts takes path to a file in the [USERPROFILE] directory as a command line argument .

1) I had tried handling it by using [USERPROFILE]My Documents property in my package , but this property gets translated to logged on user's profile path during installation . For every new user who logs on to machine it still points to the profile of the user it got translated to during installation . It can be resolved by running repair for every new user

2) Furthermore %USERPROFILE% env variable was also not of much help as the MY Documents folder is redirected to a network location and the %USERPROFILE% variable still points C:\Documents and Settings \

I need suggestions , on the best way to handle such issues .

Cheers ,
V
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
How about using [%HOMESHARE] or [%USERNAME] to resolve the path?
Answered 08/15/2005 by: MSIPackager
Third Degree Black Belt

Please log in to comment
0
%username% - gives only the logged in user name .
%HomeSHARE% - did not work , I don't think its a valid variable . However I tried %HOMEPATH % but that gives a relative path not the complete .

Quickquestion: How does windows installer translates [USERPROFILE] during installation as the installation seems to be dropping the files in the redirected My Documents .

Cheers ,
V
Answered 08/15/2005 by: viv_bhatt1
Senior Purple Belt

Please log in to comment
0
Are you sure you're using a property called "USERPROFILE"??

Aren't you using "PersonalFolder"?

Most of these "special" folders are most likely resolved using the "SHGetFolderPathW" function in "shfolder.dll"?

I can think of lots of ways of achieving what you're trying to do, but personally, I'd move the file somewhere else that has an environment variable. The location I'd choose would depend on the requirements and the environment but "%APPDATA%" might be a good choice?
Answered 08/15/2005 by: WiseUser
Fourth Degree Brown Belt

Please log in to comment
0
Yes Indeed .

I am passing a command line argument to my shortcut which goes like

[USERPROFILE]MyDocuments\Attachmate\Sessions\User1.edp

The above gets translated to the logged in user (Administrator) during installation time .Now when I log on as standard user the shortcut still tries to access Mydocuments of Administrator .

I have also tried %USERPROFILE%\MyDocuments\Attachmate\Sessions\User1.edp
The above works fine on machines where user My Documnets is not redirected to a Network drive .But fails in the other case as it still gets translated to lcal My Documents .

I haven't tried SHGetFolderPathW in Commandline argument to shortcut . I believe it will require some script to extract the path .

Cheers ,
V
Answered 08/15/2005 by: viv_bhatt1
Senior Purple Belt

Please log in to comment
0
Getting the correct path is easy, as the following couple of lines demonstrate...

Set oWsh = CreateObject("Wscript.Shell")
msgbox oWsh.SpecialFolders("MyDocuments")

But this path must be resolved at application runtime, which requires some scripting.

It will be easier for you to use a different path (like "%AppData%"). Besides, I'd say the file "User1.edp" is better described as "data" than "document"??
Answered 08/15/2005 by: WiseUser
Fourth Degree Brown Belt

Please log in to comment
0
I can't use appdata as these files are copied to the my Documents of the logged in user by the application exe .

Coming back to my documents
I can write a script which uses Wsh to identify location of My Documents and then launch the main exe and pass this resolved path as command line argument . In which case I have to provide this script as a shortcut to the user instead the main exe .

Is this a good practise ? I feel this is slightly dirty way of achieving this , can there be a better way for the same ?

Cheers ,
V
Answered 08/15/2005 by: viv_bhatt1
Senior Purple Belt

Please log in to comment
0
I have been forced to do this many times myself when delpoying with SMS Software installation account.
Nothing is good practice in the wonderful world of packaging.. Usually you cant't initiate a selfrepair based on a "non-standard"-file like a *.edp -file for instance..

Scripting is the best way in this case, use the following key to find the redirected folder: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Personal
Answered 08/15/2005 by: mgroover
Senior Yellow Belt

Please log in to comment
0
This type of script can be very useful at times, although maybe not required in this case. If you do use this type of script, beware of file associations that may bypass the functionality provided by the script.

How about using "[PersonalFolder]" and then creating an "Allusers\Startup" shortcut to repair the shortcut at logon?

msiexec /fs [ProductCode]

Seems the easiest option to me (other than moving the file).
Answered 08/15/2005 by: WiseUser
Fourth Degree Brown Belt

Please log in to comment
0
Running a repair is a good idea but is there a way I can restrict it to only first logon . I have tried runonce but it runs only for the user who logs in for the first time on the machine .

If I can run repair for every user who logs on to the system for the first time only , then my problem will be solved .

I am trying Personal Folder in the meanwhile .

Thanks .

Cheers ,
V
Answered 08/15/2005 by: viv_bhatt1
Senior Purple Belt

Please log in to comment
0
If your shortcuts are machine-specific, you'll have to repair them EVERY time.

But repairing just the shortcuts should be quick, and shouldn't require the original source files.

Other option is to set a permanent user environment variable at first logon that holds the path to "My Documents".
Answered 08/15/2005 by: WiseUser
Fourth Degree Brown Belt

Please log in to comment
0
Sorry mate.

I ran into a different issue now . I got around the issue by running repair but my exe is giving an error , the commandline argument contains path to mydocuments , now after repair the path is translated to a long filename(contains servername etc.) which the application exe is refusing to expect , perhaps the path to file has exceeded the limits set within application exe .

I have no clue how to get around this issue now .
However if i open the file directly from my documents then it works . I am not sure may be I have to convert longpath to a shortpathname first and then pass it as an argument to the appliction exe .

Cheers ,
V
Answered 08/15/2005 by: viv_bhatt1
Senior Purple Belt

Please log in to comment
0
Sounds like the "long" path as a space in between, hmm surround (correct word?) the path with the " character.
Answered 08/15/2005 by: AngelD
Red Belt

Please log in to comment
0
It is not a case of space between characters . If I keep the file in question one folder above the current level and pass thenew path as argument then application exe accepts it and works . I believe its purely a case of path exceeding the acceptable limit by the application exe .

I am planning to write a custom action which during repair will convert the longpathname to a shortpathname and store it in an environment variable . I am not sure if a vbscript custom action can do this or if I have to write a C++ dll to achieve this .

If anyone has past experience with such issues then please do let me know .

Thanks guys for your brilliant suggestions , I will update forum if Iam able to crack this .

Cheers ,
V
Answered 08/15/2005 by: viv_bhatt1
Senior Purple Belt

Please log in to comment
0
Can you give us the contents of your "Shortcut" table?

Does the application (Extra or Exceed or whatever it is) accept UNC paths?

Verify the command line that is actually being executed using ProcNTXP (SysInternals) - copy and paste the command line into a "run" dialog and try that.
Answered 08/16/2005 by: WiseUser
Fourth Degree Brown Belt

Please log in to comment
0
Sounds like a complicated solution to me..

Can't you have your MSI shortcut point to a vbscript which you include in you package and have the script build the command line with arguments each time it's run?

Cheers,
Rob.
Answered 08/16/2005 by: MSIPackager
Third Degree Black Belt

Please log in to comment
0
ORIGINAL: MSIPackager

Sounds like a complicated solution to me..

Can't you have your MSI shortcut point to a vbscript which you include in you package and have the script build the command line with arguments each time it's run?

Cheers,
Rob.



What a great idea - "Poptastic" mate![:D]

Except we already been there... too "dirty" according to Mr Bhatt.

http://www.appdeploy.com/messageboards/fb.asp?m=10688
Answered 08/16/2005 by: WiseUser
Fourth Degree Brown Belt

Please log in to comment
0
Oh yes, must learn to read sometime [8D]

Well I'd wouldn't say it's bad practice and certainly not 'dirty' .. where as this is filthy.

Good luck on your mission viv_bhatt1..


Cheers,
Rob.

I do a lot of work for charity - don't like to talk about that though.
Answered 08/16/2005 by: MSIPackager
Third Degree Black Belt

Please log in to comment
0
Thanks again for your suggestions guys .

I got around this issue by a different approach :

1) Creating an advertised shortcut to edp file instead of shortcut to exe and passing the commandline argument
2) Use file association to open .edp file with Extra.exe

This resolved the issue , everytime a new user logs onto the machine and launches this shortcut for the firsat time MSI runs self heal and copies the edp file to USERPROFILE directory and launches the exe with the edp file .

I am not sure if this one of the best approaches but it saved quite a lot of time to write a script for shortnames .

Cheers ,
V
Answered 08/17/2005 by: viv_bhatt1
Senior Purple Belt

Please log in to comment
Answer this question or Comment on this question for clarity