Create Portable Application
Hi Experts,
I would like to have Expert help to create a portable application. I've tried few times using Thinstall but, for some reason, the portable file seems not working.
The reason I need this file is some of my client intents to use this service (DigiDelivery) but the client software installation requirements caused rejection. I hope Experts could help me to create a portable file for this application so that the user can avoid an installation requirement.
I can't upload this file in EE, therefore I use RS.
http://rapidshare.com/files/373163337/DigiDelivery-2.1.1.zip.html
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi BillDL,
Thanks for detail explanation and the links. Its very helpful for me.
Thanks to dbrunton and rindi
Thanks for detail explanation and the links. Its very helpful for me.
Thanks to dbrunton and rindi
Thank you Theva. I should have mentioned that it looks like the folder the program would be installed to is:
%SystemDrive%\%ProgramFile
So, if you were to test it out, the "Parser_pts-1-1.dll" belongs in a "Plugins" sub-folder like this:
YourTestFolder
| |
| Digid3PUtil.dll
| DigiDelivery 2.0 Read Me.pdf
| DigiDelivery Client Guide.pdf
| DigiDelivery.exe
| DigidSupport.dll
|
\---Plugins
|
Parser_pts-1-1.dll
I can immediately see that DigiDelivery.exe tries and fails to load (because it can't find) "ATL70.DLL" and "MFC70U.DLL". These, along with atl70.dll, atl70.dll (unicode), mfc70.dll, mfc70u.dll, msvcp70.dll, msvcr70.dll, are the files that dbrunton was referring to.
What you do not want to be doing is placing copies of these files in the same folder as "DigiDelivery.exe". It may seem like a good idea because a program will usually look for its support files in the same folder as the program's EXE first, and it may work with the odd DLL for some other programs, but these files are intended to be in a System Folder and shared by other applications.
If you already have a program running that is using a particular DLL file, and then run another that finds and uses the same DLL from another folder, you can end up with a bunch of conflicts.
Windows XP improved this aspect of different DLL versions of the same name clashing with each other by using what they call "Side by Side Versioning" (SxS). DLL files such as those mentioned above are usually stored in separate sub-folders of "C:\WINDOWS\WinSxS" with manifests, etc, so as to keep them apart but available for use by the specific applications that need that particular version:
http://msdn.microsoft.com/en-us/library/aa376307(VS.85).aspx
I'm not really in the position to mess around too much with it on this system though. As I mentioned, if you have a system you can use to test out things and not worry if it gets messed up, then try and move ATL70.DLL and MFC70U.DLL into the test folder with DigiDelivery.exe and run it. If it errors out, then try the other DLLs in there and see what happens.
In the end though, I don't think you will get this program to run as a "portable" application that doesn't mess with the system it is being hosted on.
%SystemDrive%\%ProgramFile
So, if you were to test it out, the "Parser_pts-1-1.dll" belongs in a "Plugins" sub-folder like this:
YourTestFolder
| |
| Digid3PUtil.dll
| DigiDelivery 2.0 Read Me.pdf
| DigiDelivery Client Guide.pdf
| DigiDelivery.exe
| DigidSupport.dll
|
\---Plugins
|
Parser_pts-1-1.dll
I can immediately see that DigiDelivery.exe tries and fails to load (because it can't find) "ATL70.DLL" and "MFC70U.DLL". These, along with atl70.dll, atl70.dll (unicode), mfc70.dll, mfc70u.dll, msvcp70.dll, msvcr70.dll, are the files that dbrunton was referring to.
What you do not want to be doing is placing copies of these files in the same folder as "DigiDelivery.exe". It may seem like a good idea because a program will usually look for its support files in the same folder as the program's EXE first, and it may work with the odd DLL for some other programs, but these files are intended to be in a System Folder and shared by other applications.
If you already have a program running that is using a particular DLL file, and then run another that finds and uses the same DLL from another folder, you can end up with a bunch of conflicts.
Windows XP improved this aspect of different DLL versions of the same name clashing with each other by using what they call "Side by Side Versioning" (SxS). DLL files such as those mentioned above are usually stored in separate sub-folders of "C:\WINDOWS\WinSxS" with manifests, etc, so as to keep them apart but available for use by the specific applications that need that particular version:
http://msdn.microsoft.com/en-us/library/aa376307(VS.85).aspx
I'm not really in the position to mess around too much with it on this system though. As I mentioned, if you have a system you can use to test out things and not worry if it gets messed up, then try and move ATL70.DLL and MFC70U.DLL into the test folder with DigiDelivery.exe and run it. If it errors out, then try the other DLLs in there and see what happens.
In the end though, I don't think you will get this program to run as a "portable" application that doesn't mess with the system it is being hosted on.
>> I can immediately see that DigiDelivery.exe tries and fails to load (because it can't find) "ATL70.DLL" and "MFC70U.DLL". These, along with atl70.dll, atl70.dll (unicode), mfc70.dll, mfc70u.dll, msvcp70.dll, msvcr70.dll, are the files that dbrunton was referring to.
>> What you do not want to be doing is placing copies of these files in the same folder as "DigiDelivery.exe". It may seem like a good idea because a program will usually look for its support files in the same folder as the program's EXE first, and it may work with the odd DLL for some other programs, but these files are intended to be in a System Folder and shared by other applications.
I actually did try it without and with some of those dll files dropped into a folder with DigiDelivery. Without it complained about missing dlls. I found copies in my Visual Studio folder and copied across and tried again. This time I got a missing location in dll file such and such so that was where I stopped my testing.
>> What you do not want to be doing is placing copies of these files in the same folder as "DigiDelivery.exe". It may seem like a good idea because a program will usually look for its support files in the same folder as the program's EXE first, and it may work with the odd DLL for some other programs, but these files are intended to be in a System Folder and shared by other applications.
I actually did try it without and with some of those dll files dropped into a folder with DigiDelivery. Without it complained about missing dlls. I found copies in my Visual Studio folder and copied across and tried again. This time I got a missing location in dll file such and such so that was where I stopped my testing.
I never got that far. Wasn't brave enough to mess, although I sometimes do. I stuck to dependency walker, and that's what flagged up the first two.
ASKER
Hi BillDL & dbrunton,
Thanks for the extensive test and wiliness to share your finding with me.
Thanks for the extensive test and wiliness to share your finding with me.
To do that you need to modify the program, and that would be in breach of licence for the program you are talking about.