C# 2010 hidden files

14y3.9kVisual Basic .NET

In a C# 2010 console application it work works fine until it gets to a certain spot. Basically this console application calls another console application.
Here is what is happening:
1. When I run the console application, it runs ok until get reeaches a certain point. At that point is it trying to run the second console application from an directory path I had a week ago. Then I get error messages from the second console application.
2. Also it looks like I am the only person who can run this application. The application starts and never continues for other people.

I am thinking my problem must be in some file in the C# 2010 solution file.

Thus can you tell me what I can do to resolve my problem?

8 Replies

Know the answer? Post it — somebody with the same question will find it here.

Vulpes14y ago
Accepted answer
1. By an arbitrary absolute location, I mean a location where it's not obvious that the file in question has anything to do with a particular application. So, if you were writing an application called (let's say) bookshop.exe then it wouldn't be obvious that the location you quoted was connected with it even though bookshops do, of course, have customers.

On the other hand, if you had an application called 'allcustomers.exe', then it would be obvious that app.exe had something to do with it.

If your current directory was (or was assumed to be) 'C:\\allcustomers\country\state\city\customernumber5\', then 'app.exe' would be a relative path to the file of that name in the directory.

2. Yes, I'd put them in the executable's directory unless they have their own support files when I'd put them in a sub-directory thereof to keep everything together.

3. Well, you might want to place the whole directory tree of your application under 'c:\program files' but otherwise I'd only use it for support files if there's some reason why you don't want to put them in the executable's directory (perhaps because they're shared by several applications and you don't want to create more than one copy).

4. The .NET file classes generally have no problem accessing files with the hidden or system attributes even if such files don't show up in (normal) directory listings. So I don't think this is a likely reason for the problem you're experiencing.
dc14y ago
Thanks!
dc14y ago
Thank you very much for your explainations! your answers have been very Helpful!!!!!

I do have the additional questions to ask which are:

1. You mentioned 'storing files at arbitrary absolute locations.' So if I specify a location like the following:
'C:\\allcustomers\country\state\city\customernumber5\app.exe',
this is an arbitrary absolute location corrrect? If not, can you show me what you mean by that statement?
The arbritrary path is a result of not knowing what my current directory path is?
2. I should basically use a directory path like "D:\\allcustomers".
I should put all the executables right under the allcustomers directory level.
3. I should not place the executables in a c:\program files path unless I have a 'systems' reason for using this location?
4. Would a clean and full build solve the problem? If so, can you tell me why?
4. This problem is most likely not caused by a hidden file?
Vulpes14y ago
Assuming that files have been installed in the correct locations in the first place, then there are two possible reasons why your program cannot find them:

1. The files have either been moved or deleted altogether.

2. Your program is using 'relative' (rather than absolute) paths but the current directory isn't where you assumed it would be.

The second of these problems can be avoided by always using absolute paths; so we just need to concentrate on the first problem where the most likely culprits are the user, a system administrator or a 'disk tidying' utility.

My experience is that there is far less chance of this problem occurring if you install associated files in the main application directory (or directory tree).

System administators, utilities and knowledgeable users all realize that if a file is stored in the same directory tree as an application then it's almost certainly something which the application needs or may need. Consequently, if they are moving files about, they'll move the whole tree rather than individual files.

The windows special folders will usually be left undisturbed by administrators and utilities and tend to be buried where it's difficult for a user to discover their full path.
Consequently, they represent another good option for installing support files if you don't want to store them in the application's directory tree for some reason.

If you do decide to store the files in one of the above locations, you're then left with the difficulty of finding the absolute path. Fortunately, as we've already seen, .NET has several methods which do this for you regardless of which version of Windows is installed on the user's machine.

So, whilst I can't guarantee that you'll never have a problem if you follow this advice, I do think that there will be far less likelihood of a problem arising compared to storing files at arbitrary absolute locations.
dc14y ago
Thank you very much for your answers so far! Until I saw your answer a few minutes ago, I did not know what to do to solve the problem!

I have the following additional questions to ask you which are the following:

1. Are you saying that if I install the application in the same directory path, this sort of problem will go away? Can you tell me why this would solve my problem?

2. You mentioned that I should use the following code to find the second console application:
string mainPath = System.IOPath.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
string secondPath = mainPaath + "\\" + "second.exe";

Can you tell me why this code this better than using a static value to where the second console application is actually located at?

3. You mentioned the following,
"If, for some reason, you don't want to do that, then I'd install it in one of Windows 'special folders' such as Programs or ProgramFiles. See here for a list of these:
http://msdn.microsoft.com/en-us/library/system.environment.specialfolder.aspx
In the latter case you could then get the path to the second application using this code:
string secondPath = System.Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles) + "\\" + "second.exe";
Can you tell me which method is better and why?

4. Until I saw your answer, I was thinking of copying the code of the first console application to a new solution ide and see if the problem would go away. However according to what I see you are saying this problem would show up again correct?
Vulpes14y ago
If I were you, I'd install the second console application in the same directory as the first application or (if its needs its own support files) within a sub-directory of that directory, which should avoid this sort of problem.

In the former case, you will be able to get the path to the second application using this code:

string mainPath = System.IOPath.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
string secondPath = mainPaath + "\\" + "second.exe";

If, for some reason, you don't want to do that, then I'd install it in one of Windows 'special folders' such as Programs or ProgramFiles. See here for a list of these:

http://msdn.microsoft.com/en-us/library/system.environment.specialfolder.aspx

In the latter case you could then get the path to the second application using this code:

string secondPath = System.Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles) + "\\" + "second.exe";
dc14y ago
The error messages says it can not find the specified directory location. However the name of the seond progam that is called is from an old location where the second program used to be at. However that is not the location where I am speficying that the second program should be executed from.
I have no idea how the first program calls the second wrong with the wrong directory path. Do I need to keep the path of the second console application static?
Shivanand Arur14y ago
Can you tell us what error does it shows? May be I'll be able to help u.