0

I wish to separate a big project into one "library" with code that can be used for other projects, and the "actual" project. The "actual" project has a "Imports libraryProject", and all works fine.

However this has a drawback: There is the .exe of the "actual" project + the DLL of the "library" , which is not as simple for the user, and also can slow down a bit the code (compiler optimisation isn't as good)

Is there a way to include all of the "library" code in the "actual" project in the compilator, without physically merging the projects, in a code arrangement point of view?

Edited : the code with exe+dll is ~25% slower, too. Not due to load time (program is extremely low weighted), but due to intense calculation

Pierre
  • 1,046
  • 7
  • 21
  • You can use [ILMerge](https://www.microsoft.com/en-us/download/details.aspx?id=17630) to merge the DLL library into your main executable file after both are compiled separately. Check [this answer](https://stackoverflow.com/a/10138100/4934172) for more info on how to do that. – 41686d6564 stands w. Palestine Jul 18 '17 at 10:54

1 Answers1

0

which is not as simple for the user, LOL? In most cases user does not even know where files are stored on disk, he/she just click on the icon.

You can be sure that nothing like this can slow down code execution. If you want to merge code from library and code from application, then there is no need to have separate library.

Ondřej
  • 1,645
  • 1
  • 18
  • 29
  • In my case, the user just takes the program and puts it whereever he likes. I tried using several files, and I get to make support about "yes it doesn't work, it needs the other file" The idea is that in a programming point of view, separating the projects is really simpler. About code slowed down : I could measure it, so it's a reality. I think the compiler optimizes the code when it's one project. – Pierre Jul 18 '17 at 10:48
  • That is problem of users, not yours. If your application gets more complex, you will need for example configuration file and third party libraries, which are even more files. My current project output have 41 files in 11 folders and nobody never had any problems with it. You can also create installer (1 file), which will take care of copying all required files, creating shortcuts and adding things to registry. – Ondřej Jul 18 '17 at 10:53
  • @Ondřej, when you work on a big/complex project, you SHOULD actually create an installer. But sometimes -for tiny/simple applications- you *(as well as the users)* might prefer a portable version. In that case, I believe most of us would agree that one executable file is better than multiple files for a *small* portable application. – 41686d6564 stands w. Palestine Jul 18 '17 at 11:04
  • @AhmedAbdelhameed That is not true. You can still distribute that whole application in zipped archive, or in enterprise environment, place it in shared folder read-only accessible for everyone who will need it. If you still want to have everything in one file, you can use ILMerge tool from Microsoft. – Ondřej Jul 18 '17 at 11:09
  • @Pierre : The compiler optimizes the code if you've turned on the [**`Enable optimizations` option**](https://msdn.microsoft.com/en-us/library/07bysfz2.aspx). It doesn't matter if the code is in a separate library or not, optimizations of the individual code is the same. As for needing to tell the user to have both files: why don't you just distribute all files together in a ZIP archive?? – Visual Vincent Jul 18 '17 at 11:29
  • @Pierre : As for it going slower when using a library: The only thing that would slow the code down is when it has to load the library into memory (which is done the first time you reference it), but that usually goes rather fast and I sincerely doubt that your application is _**that**_ time critical that it cannot handle loading a DLL. And once the DLL has been loaded there's no difference in speed compared to putting all code in the same project since everything is compiled into memory. – Visual Vincent Jul 18 '17 at 11:32
  • @VisualVincent : load time is absolutely negligible in my case : like 300ko of compiled code. However it does huge calculations, which take up to a minute. I do not know exactly why, but I measured 50s for exe+dll and 40s for packaged exe (manually copying the dll code). In all cases optimization is enabled – Pierre Jul 18 '17 at 11:51
  • @Pierre That will not be problem of separate binaries. – Ondřej Jul 18 '17 at 13:07
  • @Pierre Just dont try to merge library and application. Leave it as it is or move all code to application. – Ondřej Jul 18 '17 at 13:59
  • @Ondřej : with no answer, I'll do that. But it feels bad to be forced to move code, remove reference, compile, remove code, add back references for each release – Pierre Jul 18 '17 at 14:03
  • @Pierre : The extra time that causes it to take 50 seconds could be the JIT (Just-In-Time) compiler compiling your code (only done the first time you run a particular method), did you try it multiple times _**without**_ restarting the application? Because it _**really**_ shouldn't make _**ANY**_ difference. – Visual Vincent Jul 18 '17 at 16:55
  • @Pierre : Also, why do you have to _**remove**_ and _**re-add**_ the references? If you reference a DLL and it is always compiled under the same name the references should be updated automatically (even if they are not in the same solution). – Visual Vincent Jul 18 '17 at 16:57