|
When file paths aren't absolute (i.e. they don't start at some root point such as C:\), then they are relative to the "current directory" which is some folder, initially most often defaulting to where your EXE is located. If so, @"SomeFolder\fileName" would suffice. However:
1. the initial "current directory" can be different from your EXE's location, e.g. by using an Explorer shortcut with an explicit "current directory" specification.
2. the "current directory" can change at run-time, e.g. if you use a OpenFileDialog, switch folders there, and the code allows this change to persist;
3. it is in general unwise to locate files relative to your EXE's location, as the EXE often gets installed in a location that is (a) shared by multiple users, and (b) not always writable by regular users.
The recommended approach is to give files a specific location, independent of your EXE's location. Microsoft has some guidelines for such folders, and offers some means to get those paths, see Environment.GetFolderPath(). Part of the guidelines is you should create subfolders based on your (or your company's) name, and your product name.
Example:
string folder=Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
folder=Path.Combine(folder, "companyName");
folder=Path.Combine(folder, "productName");
Directory.CreateDirectory(folder);
string file=Path.Combine(folder, "document.txt");
File.WriteAllText(file, "this is a file creation demo");
Console.WriteLine("Successfully created file "+file);
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
i'll get deeper into ur answer tomorrow (to late in my place)
meanwhile i solved it this way: Path.Combine(Directory.GetCurrentDirectory(), "Resources/XML/newTest_NewDesign.xml");
Thanks
|
|
|
|
|
igalep132 wrote: Directory.GetCurrentDirectory(),
This is about the worst way you can do this. The thing everyone doesn't realize about GetCurrentDirectory is that the currect directory can unexpectedly change or start in a folder you didn't expect to begin with. Don't make the mistake of believing that just because your app was just launched and the first thing you did was GetCurrentDirectory that you're going to get the path to the folder your .EXE was launched from. What if someone created a shortcut to your app and set the "working directory" to C:\Windows? Guess which folder GetCurrentDirectory is going to return...
Use Luc's example and build the path correctly. Don't use string concatentation to build the folder path either. Use Path.Combine instead.
|
|
|
|
|
do you really use it ?
why i need to learn new syntax to get lower performance ?
when i have no time and the high performance is not a must i go for the Dataset.
its ok with the collections and arrays but with the database !!
what do you think ? regardless that i am late to ask this 
|
|
|
|
|
Tamimi - Code wrote: why i need to learn new syntax to get lower performance ?
Who says the performance is lower? A well designed entity query can be as performant as a hand designed SQL query.
You don't need to use the new syntax - it's entirely up to you. Linq2Entities does not replace ADO.NET; it's just another tool in your arsenal. Use it, or not; that's entirely up to you.
|
|
|
|
|
while its not replacing anything and have no performance benefits, why its exist ?
i am asking this because the lambda expression is hard 
thank you
|
|
|
|
|
It's for lazy people who don't want to type much and want to exhibit their cutting-edge skillz. 
|
|
|
|
|
It exists to bring database functionality into the realm of coders who may have limited SQL skills, by integrating query capabilities into a language they are comfortable with.
Tamimi - Code wrote: i am asking this because the lambda expression is hard
That's just being lazy. Lambda expressions are not just for L2E, so you really should learn them.
|
|
|
|
|
I like LINQ, it can save a lot of time. Especially if you are using LINQ to SQL. But I really like the simple things such as counting specific values in a list...
int count = list.Count(c => c.Value > 10);
much nicer and quicker than...
int count = 0;
foreach(CustomClass c in list)
{
if(c.Value > 10)
count++;
}
Illogical thoughts make me ill
|
|
|
|
|
And what do you think it's doing in the background?
musefan wrote: it can save a lot of time
Coding time, yes. Maybe not execution time (have you benchmarked it?). Maybe not maintenance time if the next person to touch the code doesn't understand it.
I'll stick with simpler code.
|
|
|
|
|
Yes, I did mean quicker to code and I understand that it will be doing a similar if not identical thing in the background.
I did just do a test and the foreach loop is around 3 times quicker than the LINQ query (in this case), but for general use I think the faster development time is worth it, and it is better maintenance - if the next person didn't understand then it would become time for them to learn 
Anyway, if performance became important then there would be a lot more general style coding stripped away I am sure.
Illogical thoughts make me ill
|
|
|
|
|
Good point. LINQ is usually slower when I've dabbled with it. And although more verbose I always prefer simple explicit code, less error prone, easier for others to understand and easier to debug.
Regards,
Rob Philpott.
|
|
|
|
|
|
Tamimi - Code wrote: when i have no time and the high performance is not a must i go for the Dataset
That's no reason to use a DataSet... in fact there pretty much is no reason to use a DataSet.
"If you don't have time to do it right, when will you have time to do it over?"
|
|
|
|
|
PIEBALDconsult wrote: If you don't have time to do it right, when will you have time to do it over?"
yes, hopefully; maybe just enough to do it differently and wrong again.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Until you've fully explored enough of the wrong ways, you'll never truly appreciate the right way.
|
|
|
|
|
You missed the word "grasshopper" from the end of that sentence.
|
|
|
|
|
I'm only just starting to learn LINQ: I have pretty reasonable SQL abilities already.
The main reason I am learning it is that I feel that the stronger typing and compile time syntax checking available in LINQ to SQL has got to produce better, cleaner, more reliable solutions than hand crafted SQL.
Once I've got a good feeling for it, I'll make the decision to either go with it or back - but until I have that level of confidence in my abilities with it, I can't make that call. If I don't learn LINQ, I made that call without sufficient information.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Digital man: "You are, in short, an idiot with the IQ of an ant and the intellectual capacity of a hose pipe."
|
|
|
|
|
OriginalGriff wrote: If I don't learn LINQ, I made that call without sufficient information.
Hear hear!
I finally dabbled in a little bit of Linq (to SQL?) a few weeks ago. It gave me no benefit and I don't see how it can deliver any. Especially considering I use several different database systems, not just Sql Server.
OriginalGriff wrote: LINQ to SQL has got to produce better, cleaner, more reliable solutions than hand crafted SQL.
Not if you've been hand crafting clean reliable SQL for twenty years.
If Linq produces better SQL than you do, then go with it.
|
|
|
|
|
PIEBALDconsult wrote: Not if you've been hand crafting clean reliable SQL for twenty years.
Not quite what I meant: I was thinking more that finger trouble with LINQ is more likely to cause a compilation error, where in SQL it is run time and so harder to test and detect.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Digital man: "You are, in short, an idiot with the IQ of an ant and the intellectual capacity of a hose pipe."
|
|
|
|
|
Oh, sure, but you can develop and test your more-complex SQL statements with another tool and then copy-and-paste them into your application.
An additional benefit of that is that it drives parameter use rather than concatenation.
|
|
|
|
|
I would assume that Linq generates parametrized queries anyway: I always use them with SQL.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Digital man: "You are, in short, an idiot with the IQ of an ant and the intellectual capacity of a hose pipe."
|
|
|
|
|
OriginalGriff wrote: I always use them with SQL
Yes, but others don't, because concatenation is easier unless your framework (e.g. Linq) makes parameters easier.
|
|
|
|
|
PIEBALDconsult wrote: Yes, but others don't, because concatenation is easier they are lazy idiots who like leaving their DB wide open to an SQL injection attack
FTFY! 
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Digital man: "You are, in short, an idiot with the IQ of an ant and the intellectual capacity of a hose pipe."
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
