Click here to Skip to main content
15,939,065 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
I have a problem reading an .ini file from a web location, when the visual studio is open.

I am trying to open the file using GetPrivateProfileInt, while the .ini file is on the same computer, but is loooked up via a shared directory, like: \\SHARED_DIR\requestedIniFile.ini. the request succeeds. but if I have an open version of Visual Studio (I am using VS 2005 pro, SP1) when Im making the call - the request fails.

If I change the path to be the exact path of the shared location: C:\SHARED_DIR\requestedIniFile.ini - the call succeeds.

We have encountered this problem in 4 different computers, with different .ini files, with different projects open on the VS.

it seems like the VS is blocking the shared dir port, (or maybe the VS source control). but I can't really tell.

Can you think of a reason for it? has anyone encountered this problem?


[edit]Spurious Code Block removed - OriginalGriff[/edit]
Updated 16-Mar-11 21:52pm

You say "If I change the path to be the exact path of the shared location: C:\SHARED_DIR\requestedIniFile.ini then it succeeds." That should give you a clue that it's a folder-relative problem. Why not just use the full path all the time? Wouldn't that be safer?
Share this answer
Albert Holguin 31-Mar-11 22:39pm    
I don't know about safer, there's nothing unsafe about relative paths when you do it correctly
Hans Dietrich 31-Mar-11 22:47pm    
Which is clearly not happening here. In general, to allow for moving the app, etc., it's safest to specify full paths, preferably ones that the user can modify
Albert Holguin 31-Mar-11 23:09pm    
there's one thing i can completely agree with... "is clearly not happening here"
kobishenko 22-May-11 3:03am    
Hi guys,
This is not folder relative issue or a wrong path - Like I said - if I ran my application when the Visual studio is not open in the background - it opens the file perfectly.
And the reason I'm not using a full path is that the file might be located on a remote shared computer. nothing new here I think.
So my guess is that this has something to do with the Visual studio 2005 that blocks the shared dir port (or something like that which I have no clue).
Can you suggest anything about this direction?

kobishenko 3-Aug-11 10:34am    
Does anyone has a clue on this issue?
if you mean that it works when you run the code on its own (as in executable) but not from visual studio, then the problem's probably the fact that the working directory's different. when you run from studio, the working directory is the project location (may be your target directory, can't recall exactly), not the location of the executable. you can change this setting if you'd like (can't recall off the top of my head how to do it, but it buried somewhere in the options).
Share this answer

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900