Deployment folder question

[Cuperman]

Hi all,

I have an XML file that I reference in my windows application

I access it using - Application.Sta rtupPath & "/ini.xml"
During development this resides in the Bin folder, it appears this is
where the application is being run from when debug.

But when I build the project, install it (using a deployment project)
and then run it, I get a FileNotFound exception, because the XML file
is installed in the bin folder, but the application is now running from
the application folder (one level up from the Bin folder).

Whats the best way to set this up?

Thanks,
Mark

[Jorge L Matos [MCSD.NET]]

RE: Deployment folder question

In my opinion, I would put the ini.xml file in a fixed location on your
harddrive and add a configuration setting in your App.config file that points
to that fixed location - this way you avoid hard-coding the ini file location
in your code.

"Cuperman" wrote:
[color=blue]
> Hi all,
>
> I have an XML file that I reference in my windows application
>
> I access it using - Application.Sta rtupPath & "/ini.xml"
> During development this resides in the Bin folder, it appears this is
> where the application is being run from when debug.
>
> But when I build the project, install it (using a deployment project)
> and then run it, I get a FileNotFound exception, because the XML file
> is installed in the bin folder, but the application is now running from
> the application folder (one level up from the Bin folder).
>
> Whats the best way to set this up?
>
> Thanks,
> Mark
>
>[/color]

[Cuperman]

Re: Deployment folder question

Many thanks for you reply Jorge.

This seems like a bit of a 'work around'. I am new to 'win forms'
development and am sure there is a simple way to control the location
of files during deployment. For control however I do want the user to
be able to select a location when they install and then keep all the
installed files together. This way I wouldnt be hard coding the
location of the file, it would be in a sub folder of the application.

The specific problem is that during development the application seems
to reside in teh bin folder, but the exe is deployed one folder higher.

An alternative, would be to force my development environment to build
the exe and debug from that in the correct location perhaps?

Also, all of the DLL's that are bing distributed with my app (Crystal
etc) are being deployed in the root folder of the application and not
the bin folder. Is this part of the same issue?

Thanks again, Mark

[Jorge L Matos [MCSD.NET]]

Re: Deployment folder question

When you build a windows forms project the EXE is always placed in either the
bin\debug or bin\release folder of your project directory. If your windows
project is on drive c: and is called "MyApp" then the path to your EXE for a
debug configuration would be:

c:\myapp\bin\de bug\myapp.exe

if you XML file is in c:\myapp then your code will have to account for the
fact that during development your EXE is in the bin\debug folder. You can try
using:

AppDomain.Curre ntDomain.SetupI nformation.Appl icationBase
or
Application.Sta rtupPath

to determine the path to your XML file.

"Cuperman" wrote:
[color=blue]
> Many thanks for you reply Jorge.
>
> This seems like a bit of a 'work around'. I am new to 'win forms'
> development and am sure there is a simple way to control the location
> of files during deployment. For control however I do want the user to
> be able to select a location when they install and then keep all the
> installed files together. This way I wouldnt be hard coding the
> location of the file, it would be in a sub folder of the application.
>
> The specific problem is that during development the application seems
> to reside in teh bin folder, but the exe is deployed one folder higher.
>
> An alternative, would be to force my development environment to build
> the exe and debug from that in the correct location perhaps?
>
> Also, all of the DLL's that are bing distributed with my app (Crystal
> etc) are being deployed in the root folder of the application and not
> the bin folder. Is this part of the same issue?
>
> Thanks again, Mark
>
>[/color]