Choosing installation file location

[John]

Hi

When I create a setup for my application, it installs all files for the app
in C:\Program Files\MyCo\MyApp folder. How can I have some of the files to
be installed under :\Program Files\Common Files\... folder instead?

Thanks

Regards

 

[Herfried K. Wagner [MVP]]

When I create a setup for my application, it installs all files for the app
in C:\Program Files\MyCo\MyApp folder. How can I have some of the files to
be installed under :\Program Files\Common Files\... folder instead?

In the setup project select "File System on Destination Computer" and
choose "Add Special Folder..." from the context menu.

 

[John]

Thanks. A related question; How to deal with the fact that the application
needs explicit paths to certain types of files; acess database, word/e-mail
templates, config files? The development and installation paths are normally
different, how to account for change in location of files against what is
expected by app?

Thanks

Regards

 

[Herfried K. Wagner [MVP]]

Thanks. A related question; How to deal with the fact that the application
needs explicit paths to certain types of files; acess database, word/e-mail
templates, config files? The development and installation paths are normally
different, how to account for change in location of files against what is
expected by app?

You will have to make the paths dynamic in your application. Where are
the files installed?

 

[John]

Well they all go under program files but as my development path is something
like C:\My App Suit\App 1\..., it is surely different from the installation
path. The app needs to dynamically read the file paths somehow. What would
be a dependable way to do this? May be have a file containing all paths in
the root folder of the app?

Thanks

Regards

 

[Herfried K. Wagner [MVP]]

Well they all go under program files but as my development path is something
like C:\My App Suit\App 1\..., it is surely different from the installation
path. The app needs to dynamically read the file paths somehow. What would
be a dependable way to do this? May be have a file containing all paths in
the root folder of the app?

You can use this function to get the application's path:

\\\
Imports System.IO
Imports System.Reflection
..
..
..
Private Function ApplicationPath() As String
Return _
Path.GetDirectoryName([Assembly].GetExecutingAssembly().Location)
End Function
///

 

[John]

That is great. This should work me.

Thanks

Regards

Well they all go under program files but as my development path is something
like C:\My App Suit\App 1\..., it is surely different from the installation
path. The app needs to dynamically read the file paths somehow. What would
be a dependable way to do this? May be have a file containing all paths in
the root folder of the app?

You can use this function to get the application's path:

\\\
Imports System.IO
Imports System.Reflection
.
.
.
Private Function ApplicationPath() As String
Return _
Path.GetDirectoryName([Assembly].GetExecutingAssembly().Location)
End Function
///

 

[Fergus Cooney]

Hi John, Herfried,

Dim SoManyChoicesForTheAppPath As String = _

vbCrLf & _
Path.GetDirectoryName([Assembly].GetExecutingAssembly().Location) _

vbCrLf & _
Path.GetDirectoryName(Application.ExecutablePath) _

vbCrLf & _
Application.StartupPath

Regards,
Fergus

 

[Herfried K. Wagner [MVP]]

Path.GetDirectoryName(Application.ExecutablePath) _

vbCrLf & _
Application.StartupPath

We previously had a discussion why 'Application.*' should not be used.

 

[Phil Wilson]

If you right-click on File System on Target Machine, there's an Add Special
Folder that lets you add the CommonFiles folder.

 

[Fergus Cooney]

Hi Herfried,

I must have missed that. Which topic was it?

Regards,
Fergus

 

[Herfried K. Wagner [MVP]]

I must have missed that. Which topic was it?

I am not sure, but I remember that Tom and Jeremy discussed a lot about
the topic.

 

[John]

Just a silly quickie, what would be the [assembly]? name of the exe file?

Thanks

Regards

Well they all go under program files but as my development path is something
like C:\My App Suit\App 1\..., it is surely different from the installation
path. The app needs to dynamically read the file paths somehow. What would
be a dependable way to do this? May be have a file containing all paths in
the root folder of the app?

You can use this function to get the application's path:

\\\
Imports System.IO
Imports System.Reflection
.
.
.
Private Function ApplicationPath() As String
Return _
Path.GetDirectoryName([Assembly].GetExecutingAssembly().Location)
End Function
///

 

[Fergus Cooney]

Hi Herfried,

I found 26 posts in Topic App.path, dated 27th Aug in Google
(unfortunately missing from my OE due to the newserver problems). That may be
the one you were referring to.

It gives no reasons not to use Application, apart from when a dll wants to
find its own path. But in that case, you shouldn't be calling a function
called ApplicationPath anyway, regardless of what it does inside. You should
be calling AssemblyPath.

Can you remember who said that Application shouldnt be used and why?

Regards,
Fergus

 

[Herfried K. Wagner [MVP]]

Just a silly quickie, what would be the [assembly]? name of the exe file?

You need not replace the "[Assembly]". 'Assembly' is a reserved
keyword, that's why you must enclose it in square brackets to use the
'Assembly' _class_.

 

[Herfried K. Wagner [MVP]]

I found 26 posts in Topic App.path, dated 27th Aug in Google
(unfortunately missing from my OE due to the newserver problems). That may be
the one you were referring to.

It gives no reasons not to use Application, apart from when a dll wants to
find its own path. But in that case, you shouldn't be calling a function
called ApplicationPath anyway, regardless of what it does inside. You should
be calling AssemblyPath.

Can you remember who said that Application shouldnt be used and why?

I remember that someone told us about his experiences that it may return
a wrong path if the executable file gets launched by a shelllink.

 

[Herfried K. Wagner [MVP]]

I found 26 posts in Topic App.path, dated 27th Aug in Google
(unfortunately missing from my OE due to the newserver problems). That may be
the one you were referring to.

It gives no reasons not to use Application, apart from when a dll wants to
find its own path. But in that case, you shouldn't be calling a function
called ApplicationPath anyway, regardless of what it does inside. You should
be calling AssemblyPath.

Can you remember who said that Application shouldnt be used and why?

I remember that someone told us about his experiences that it may return
a wrong path if the executable file gets launched by a shelllink.

 

[Fergus Cooney]

Hi Herfried,

Someone did say that and then some other guy** proved that
Application.StartupPath was fine even with a changed Shortcut.

This makes sense because while a Shortcut can specify a different starting
working directory, this is different from the directory that the application
<executable> starts from.

In my view, Application.StartupPath is ambiguous, for it implies the
initial <working directory> but actually means the source directory of the
application <executable>.

Which poses the question - how to determine the initial working directory?
And I guess this would be CurDir or some such.

Regards,
Fergus

** Some other guy proved otherwise.
I didn't get his name but his initials were HKW ;-)

 

[Fergus Cooney]

Hi John, Herfried,

To know where your appliction is you don't need that complicated looking
function that Herfried gave - you can simply use Application.StartupPath.

Herfried himself proved (in a long thread about just that) that
Application.StartupPath is effective to find which directory the application
executable resides in. But this is hardly surprising - because that's its
definition!!.


You don't need to escape Assembly if you preceed it with its class.

Imports System.Reflection
[Assembly].GetExecutingAssembly
or
Imports System
Reflection.Assembly.GetExecutingAssembly
or
System.Reflection.Assembly.GetExecutingAssembly

Regards,
Fergus

 

[Herfried K. Wagner [MVP]]

To know where your appliction is you don't need that complicated looking
function that Herfried gave - you can simply use Application.StartupPath.

Herfried himself proved (in a long thread about just that) that
Application.StartupPath is effective to find which directory the application
executable resides in. But this is hardly surprising - because that's its
definition!!.

Did you test it on all Windows versions when starting the application
from a shortcut that specifies a different working directory?

You don't need to escape Assembly if you preceed it with its class.

You mean to preceed it with its namespace.