By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,203 Members | 1,633 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,203 IT Pros & Developers. It's quick & easy.

HELP File path confusion in WinForms app

P: n/a
Every example I see regarding opening a file uses paths like this:
FileStream inputStream = new FileStream ("C:\\file.txt",
FileMode.Open, FileAccess.Read);

Great if the file is always on the root of the C: drive but what if
thatís not the case?!

If I add a file to a project in my solution I canít hard code the path
to the file which lives in something like C:\Documents and Settings
\Administrator\My Documents\Visual Studio 2005\ProjectsÖ.

So how do I access a file using relative paths from the solution? And
if I have a program in one project trys to open a file in another
project how is this accomplished?

For example, I have two projects in my solution A & B. I have a
project reference in A to B. In B I have added an xml file to the
project. Itís in the root of the project. B has a class, BClass that
has a static function that needs to open that file. I call this
function in B from A, eg: BClass.OpenFile(). The file is physically
located in something like C:\Documents and Settings\Administrator\My
Documents\Visual Studio 2005\Projects (which will not exist on the
server this solution gets deployed to) and when A runs itís the
currently executing program so any Application path will refer to A
not B but the file is in B. How to access that file?

TIA
G
Nov 1 '08 #1
Share this Question
Share on Google+
4 Replies


P: n/a
>On Nov 1, 5:29*pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.comwrote:
Finally, for relatively small files one of the most reliable approaches is *
to just include the file as a binary resource in the output assembly (.exe *
or .dll). *Then it's not possible to deploy the assembly without the file, *
since it's actually part of the same file. *You would then retrieve the*
file as a byte stream or array from the resource itself.
Thanks for your reply. It's a small xml file so I'll look into using
binary resources. However, I'll be trying to access a binary resource
in one project exe from another executing project exe so not sure if
that will be a problem...

G

Nov 2 '08 #2

P: n/a
On Sun, 02 Nov 2008 08:43:44 -0700, GiJeet <gi****@yahoo.comwrote:
Thanks for your reply. It's a small xml file so I'll look into using
binary resources. However, I'll be trying to access a binary resource
in one project exe from another executing project exe so not sure if
that will be a problem...
I don't think there should be any difficulty at all. But, note that each
project only has convenient access to its own resources. You can load
resources from other assemblies, but it requires more explicit code. So,
if you need access to the data from a different assembly than where it's
stored, you might want to add a convenience method in the assembly where
it's stored to make accessing the data easier.

Note also that if the two projects are loaded in two different processes,
then obviously you'll have to go the explicit route of loading the
assembly and extracting the resource directly. It's not really clear from
your question what the scenario is, as you're distinguishing between "one
project exe from another executing project", which _might_ imply two
different processes. Or it might not. I can't tell.

Pete
Nov 2 '08 #3

P: n/a
>On Nov 2, 12:26*pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.comwrote:
>*It's not really clear from *
your question what the scenario is, as you're distinguishing between "one*
project exe from another executing project", which _might_ imply two *
different processes. *Or it might not. *I can't tell.
I have two projects, one's an exe the other a dll. The dll is the one
that needs the xml file. The exe calls the dll so then the dll needs
to access the xml file. should be very common. Also, the exe project
has a reference set to the dll project so it can access it's methods
at design time.

My concern with an embedded resource file is, I believe every time you
change the xml file, since itís embedded you need to recompile the dll
project and since the exe has a reference to the dll project, that
existing reference will no longer be valid and you need to remove and
re-add the reference. Just becomes a maintenance issue. Is this
correct?

G

Nov 3 '08 #4

P: n/a
On Mon, 03 Nov 2008 03:46:53 -0800, GiJeet <gi****@yahoo.comwrote:
[...]
My concern with an embedded resource file is, I believe every time you
change the xml file, since it’s embedded you need to recompile the dll
project and since the exe has a reference to the dll project, that
existing reference will no longer be valid and you need to remove and
re-add the reference. Just becomes a maintenance issue. Is this
correct?
Sort of, yes. You'd put the resource in the DLL, so only the DLL would
need recompiling. But yes, it would need to be recompiled if the file
changes, using that strategy.

Pete
Nov 3 '08 #5

This discussion thread is closed

Replies have been disabled for this discussion.