• Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

We're also offering banner ads on our site from just \$5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.

#ActualBacterius

Posted 25 March 2013 - 06:35 AM

Well it depends on your programming language, what I usually have, for C or C++, is as follows:

project
|- bin/           (for binaries and required DLLs.. you can also have a lib folder)
|   |- debug/
|   |- release/
|- data/          (for assets, such as databases, images, sounds, and so on)
|   |- images/
|   |- sounds/
|- doc/           (for your documentation, either generated or written)
|   |- html/
|   |- pdf/
|- src/           (for the source code files, organize in subfolders)
|   |- folder1/
|   |- folder2/
|- include/       (for the header code files, if applicable)
|   |- folder1/
|   |- folder2/
|- misc/          (anything left that you want to include)


When it comes to DLL's, though, you might not want to drag around a bunch of common DLL's when distributing your program, so you might want to ask the user to install the required frameworks instead of providing the DLL's yourself, this makes it easier on you and ultimately on the user, since there will be no duplication.

As for how to get your program to find those DLL's, well, unless you are loading them dynamically, they need to be in the program's PATH variable for the system to find them, this PATH includes your system PATH (operating system library folder, and other programs tend to write themselves in this variable too) in addition to the directory where the program was launched, which generally means you need your custom DLL's to be right next to your program, at least under Windows.

This also applies to resources to some extent, so for release you probably don't want a bin/ folder.

If you use an installer you can make things more consistent, but this is more advanced.

#4Bacterius

Posted 25 March 2013 - 01:34 AM

Well it depends on your programming language, what I usually have, for C or C++, is as follows:

project
|- bin/           (for binaries and required DLLs.. you can also have a lib folder)
|- debug/
|- release/
|- data/          (for assets, such as databases, images, sounds, and so on)
|- images/
|- sounds/
|- doc/           (for your documentation, either generated or written)
|- html/
|- pdf/
|- src/           (for the source code files, organize in subfolders)
|- folder1/
|- folder2/
|- include/       (for the header code files, if applicable)
|- folder1/
|- folder2/
|- misc/          (anything left that you want to include)


When it comes to DLL's, though, you might not want to drag around a bunch of common DLL's when distributing your program, so you might want to ask the user to install the required frameworks instead of providing the DLL's yourself, this makes it easier on you and ultimately on the user, since there will be no duplication.

As for how to get your program to find those DLL's, well, unless you are loading them dynamically, they need to be in the program's PATH variable for the system to find them, this PATH includes your system PATH (operating system library folder, and other programs tend to write themselves in this variable too) in addition to the directory where the program was launched, which generally means you need your custom DLL's to be right next to your program, at least under Windows.

This also applies to resources to some extent, so for release you probably don't want a bin/ folder.

If you use an installer you can make things more consistent, but this is more advanced.

#3Bacterius

Posted 25 March 2013 - 01:32 AM

Well it depends on your programming language, what I usually have, for C or C++, is as follows:

project
|- bin/           (for binaries and required DLLs.. you can also have a lib folder)
|- debug/
|- release/
|- data/          (for assets, such as databases, images, sounds, and so on)
|- images/
|- sounds/
|- doc/           (for your documentation, either generated or written)
|- html/
|- pdf/
|- src/           (for the source code files, organize in subfolders)
|- folder1/
|- folder2/
|- include/       (for the header code files, if applicable)
|- folder1/
|- folder2/
|- misc/          (anything left that you want to include)


When it comes to DLL's, though, you might not want to drag around a bunch of common DLL's when distributing your program, so you might want to ask the user to install the required frameworks instead of providing the DLL's yourself, this makes it easier on you and ultimately on the user, since there will be no duplication.

As for how to get your program to find those DLL's, well, unless you are loading them dynamically, they need to be in the program's PATH variable for the system to find them, this PATH includes your system PATH (operating system library folder, and other programs tend to write themselves in this variable too) in addition to the directory where the program was launched, which generally means you need your custom DLL's to be right next to your program, at least under Windows.

If you use an installer you can make things more consistent, but this is more advanced.

#2Bacterius

Posted 25 March 2013 - 01:32 AM

Well it depends on your programming language, what I usually have, for C or C++, is as follows:

project
|- bin/           (for binaries and required DLLs.. you can also have a lib folder)
|- debug/
|- release/
|- data/          (for assets, such as databases, images, sounds, and so on)
|- images/
|- sounds/
|- doc/           (for your documentation, either generated or written)
|- html/
|- pdf/
|- src/           (for the source code files, organize in subfolders)
|- module1/
|- module2/
|- include/       (for the header code files, if applicable)
|- module1/
|- module2/
|- misc/          (anything left that you want to include)


When it comes to DLL's, though, you might not want to drag around a bunch of common DLL's when distributing your program, so you might want to ask the user to install the required frameworks instead of providing the DLL's yourself, this makes it easier on you and ultimately on the user, since there will be no duplication.

As for how to get your program to find those DLL's, well, unless you are loading them dynamically, they need to be in the program's PATH variable for the system to find them, this PATH includes your system PATH (operating system library folder, and other programs tend to write themselves in this variable too) in addition to the directory where the program was launched, which generally means you need your custom DLL's to be right next to your program, at least under Windows.

If you use an installer you can make things more consistent, but this is more advanced.

#1Bacterius

Posted 25 March 2013 - 01:32 AM

Well it depends on your programming language, what I usually have, for C or C++, is as follows:

project
|- bin/           (for binaries and required DLL's.. you can also have a lib folder)
|- debug/
|- release/
|- data/          (for assets, such as databases, images, sounds, and so on)
|- images/
|- sounds/
|- doc/           (for your documentation, either generated or written)
|- html/
|- pdf/
|- src/           (for the source code files, organize in subfolders)
|- module1/
|- module2/
|- include/       (for the header code files, if applicable)
|- module1/
|- module2/
|- misc/          (anything left that you want to include)


When it comes to DLL's, though, you might not want to drag around a bunch of common DLL's when distributing your program, so you might want to ask the user to install the required frameworks instead of providing the DLL's yourself, this makes it easier on you and ultimately on the user, since there will be no duplication.

As for how to get your program to find those DLL's, well, unless you are loading them dynamically, they need to be in the program's PATH variable for the system to find them, this PATH includes your system PATH (operating system library folder, and other programs tend to write themselves in this variable too) in addition to the directory where the program was launched, which generally means you need your custom DLL's to be right next to your program, at least under Windows.

If you use an installer you can make things more consistent, but this is more advanced.

PARTNERS