Best practice for naming project output files

Question

We develop an application in c# with a lot of assembly files like exe, dll and other custom extensions. by default the name of each file is equal to its project name and it's too clear for user.

Is there any best practice for naming the output files of each project and keep it unclear for users that install our application?

What is so bad in being clear? And if such standard existed it would make it clear too to users. If you want obfuscation just name it something only you understand — Iznogood, Sep 14 '11 at 17:42
If you look at the files in the windows folder you hardly ever understand the meaning of those files. I want to understand those standards. — amirhosseinab, Sep 14 '11 at 18:02
@Amir Hossein then your question is spectacularely badly formed. :) rewrite it more clearly. — Iznogood, Sep 14 '11 at 18:10
@Iznogood Sorry if i can't explain my problem clearly. my natural language is not English and I think I'm not smooth enough in that :) — amirhosseinab, Sep 14 '11 at 19:39

score 3 · Accepted Answer · edited May 23 '17 at 11:57

3

It sounds like you want to prevent users from poking around the internals of the project, and possibly simplify their use of it. There are best practices on this. I would point you to obfuscation, and merge tools.

Obfuscation: .NET obfuscation tools/strategy

Merging: Best practices for merging assemblies?

When you Obfuscate your code, it will be very difficult to de-compile it. As the previous article mentions with 3.5 it is not as much of an issue as it used to be. This will help if you want to keep those that are very technically inclined out.

When you merge the assemblies, all the DLL's and EXE's you see will become one EXE. This is good because it will be clear on what they need to run, but at the same not give them too much information on the internal workings. This is something that I don't generally worry about with my end users, but I am sure you have your reasons.

edited May 23 '17 at 11:57

Community

1
1

answered Sep 14 '11 at 18:11

TMB

4,683
4
25
44

Sorry it was a little off topic from what you were wanting. – TMB Sep 14 '11 at 18:49
Please make sure to clean up you question, and I'll make sure to get that -1 off. – TMB Sep 14 '11 at 18:51
No, it was good for me @TMB and i'm happy cause you get my point unlike the other guys. – amirhosseinab Sep 14 '11 at 18:56
good enough for an up vote, or marked correct? – TMB Sep 14 '11 at 19:00
unfortunately I can't up vote answers yet, because my rep is not enough for that, but I will mark it correct and if it possible for you please vote up my question because they decrease my rep with no reason. – amirhosseinab Sep 14 '11 at 19:06
I marked it up with an edit. Once it is approved I'll up vote the question. Please see the [FAQ](http://stackoverflow.com/faq) and [META](http://meta.stackoverflow.com/) for some of the conventions of StackOverflow and the StackExchange sites. – TMB Sep 14 '11 at 19:13

score 1 · Answer 2 · answered Sep 14 '11 at 18:23

"windows folder ... those standards": Generally files in windows, system32 and related folders has to follow 8.3 file name restriction - so most endup beeing insanely cryptic. The "hide meaning of the file" is not the reason of the names being strange.

There are several types of names historically in those folders:

exe with well known/established names like ping.exe, chkdsk.exe
user callable exe - like notepad.exe and calc.exe
short names constructed of reasonable words - chkdsk.exe, chkntfs.exe
named specifically due to technical requirements - i.e. localization files include culture name in the name or path.
more or less the rest named randomly, usually name consist with several abbrviation somehow identifying components, but generally non-decryptable by general public.

Note that in most (if not all) cases simple search by file name on you favorite search site will give you reasonable details about the file.

Best practice for naming project output files

2 Answers2