I've got a lot of small DLLs which I would like to make into one big(er) DLL (as suggested here). I can do so by merging my projects but I would like a less intrusive way.
Can several DLLs be merged into one unit?
A quick search found this thread that claims this is not possible. Does anyone know otherwise?
Note that I'm talking about native C++ code not .NET so ILMerge is out.
I don't know about merging dlls, but I'm sure you can link the intermediate object files into one dll. This would only require changes in your build script.
As far as I know you cannot merge DLL files directly. But it should be possible with static libraries or object files. If it is possible for you to build static libraries of your projects you can merge them using the Library Manager by extracting object files from all libraries and packaging them into a new library.
Also, there was a product that made a .LIB out of .DLLs. You could then link your exe against that .LIB and get rid of the .DLLs altogether. Perhaps you could link a .DLL out of the .LIB - I'm not sure.
The product is here:
http://www.binary-soft.com/dll2lib/dll2lib.htm
I'm not sure, if it works anymore, if it's supported or even sold. It sure appears pricey, but it used to have (nag-enabled) free trial period.
Related
Is there any way, I can prevent my c++ cli project from being decompiled if someone uses a C# decompiler, because I tried to decompile the .exe i made in ILSpy and it showed my whole code, so is there any way I can prevent this?
Thanks
as ancient as this thread is, I ran across it with the same question, and a newish answer. Can't specify the minimum version for this one, but
[module:System::Runtime::CompilerServices::SuppressIldasmAttribute];
on top of each .cpp module did the trick for me:
I didn't investigate much further, yet.
Another useful thing is to add
#pragma unmanaged
to each .cpp that does not contain .net code.
You can
Use a .NET obfuscator.
Or
Only use C++CLI for the boundaries of your app which require to Interact with .NET. And implement your logic in a native C++ library.
I have a few different projects that all get mixed and matched into different types of solutions.
For projects, I currently have
EngineProj: c++, built as a .lib
GameProj: c++, built as a .exe
EditorProj: c++/clr, built as a .exe
For solutions, I currently have
Game: c++, built with EngineProj and GameProj
Editor: c++/clr, built with EngineProj and EditorProj
This has worked great for games. I have been able to make a few different game solutions that keep reusing the shared EngineProj.
The Editor solution has EditorProj build a .exe with a WindowsForm object called EditorForm. This is used to edit generic game data that is common for all game solutions.
Now, though, I want to be able to do the same thing for my Editor that I do with my games. I want to be able to make game specific versions of the Editor that reuse as much project setup and code as possible. Here is what I am working towards.
For projects, I am planning
EngineProj: c++, built as a .lib
GameCoreProj: c++, built as a .lib
GameExeProj: c++, built as a .exe (a very thin and small project)
EditorCoreProj: c++/clr, built as a .lib
EditorGameExeProj: c++/clr, built as a .exe
For solutions, I am planning
Game: c++, built with EngineProj, GameCoreProj, and GameExeProj
GameEditor: c++/clr, built with EngineProj, GameCoreProj, EditorCoreProj, and EditorGameExeProj
I am having troubles getting my GameEditor solution to come together.
The idea is for EditorCoreProj to provide the same EditorForm that EditorProj did; only in a .lib instead. EditorGameExeProj would then build with GameCoreProj.lib and EditorCorProj.lib. EditorGameExeProj would support a new WindowsForm object that derives from EditorForm, but implements new features unique to the needs of GameCorProj.
Various forms of unresolved externals have been plaguing me for a couple days now.
It seems that my issues stem from the fact that EditorCoreProj is a c++/clr project.
I read many articles and tried many different approaches, but eventually I found some reading that suggested that making a .lib would never work. It sounds like c++/clr .libs are not supported.
So, then, I tried making EditorCoreProj build as a .dll. For hours, I tried to get EditorGameExeProj to import the .dll. I read that maybe I need to tag everything for export and import. That sounded like a lot of work, and so I started just making some test solutions. However, that continually resulted in unresolved externals, too.
I am pretty new to making a .dll; I have always preferred .libs. Maybe I am just encountering newb issues with .dlls. At this point though, I have spent a couple days trying to get this setup.
And so, finally, my question.
Am I headed in the right direction? Maybe there is something much easier I should be doing?
Thank you for your time
I ended up sticking to the plan, and got everything working. I don't know if there was a better route to take, but this does full-fill all of my needs.
I have created a number of re-usable classes that I use across xcode projects, for example:
Utility
EmailController
MarketingController
FlashLightController
etc
I had been simply copying these class files from and back into a central repository, but now I have a number of apps it is all getting a little confusing from a config management point of view. So I was looking for an alternative.
I started investigating Static Libraries but they seem to be quite a lot of more effort for simply re-using code (e.g. different libs for device vs simulator, still having to have copies of .h files, etc).
Does anyone know of a decent alternative for quick and easy code reuse?
Thanks, Charlie
You can put the code files into a project without actually copying them into the project. In other words, just keep the class files in a completely separate location. Import them into many projects, but uncheck the option to copy them in. The projects will still refer to them successfully. Now a change made in the class files will propagate to every project that uses them.
Also, consider whether workspaces will help you.
In my view, almost anything is better than making a library or framework!
Static libraries would probably be your best bet, as I have used them and have found them to be pretty easy to use. (I haven't had to use different libraries for device or simulator, mine works on them all). Having the header isn't that annoying, and static libraries are really the only way (outside of dynamic libraries, which are banned by apple) other than copying the files to reuse code.
I have a library that I created which I would like to use the included classes across a few different projects while maintaining the library code independently. I would also like to be able to easily share it with other developers and have them easily implement it. At this point it doesn't need to be a static library.
What is the best method to do this? I have seen other devs put their classes in a brand new XCode project then import that, but what is best practice?
I think the best practice is to create a project with a static library target. Other developers can include it as a subproject in their projects.
Second best would be to simply make a directory of source files that can be included in a project on an as-needed basis. This is useful for general purpose utility code where a particular project may not want all of it.
In both cases, the library code should belong to its own git repository and included in a project as a git submodule.
If it will ever become a static library, it's best to make it one now, rather than waiting until it is "ready"; by the time you decide to switch it over, a few projects will already be using it, and converting each of them to use it will be a pain. Just do it the right way from the beginning.
If you want to distribute the library without source, you will want to use lipo to build a universal library that contains both ARM and x86 code. Unfortunately, Xcode doesn't make this as easy as it could be, but it's not too difficult with some light shell scripting.
As far as I know you should create a new project and that project to any other project you want use library in. Then link the projects and you can access it. The other way which I have done also, copy the library classes directly to the new project and access the library through importing the needed classes. In my case i found creating a project and linking it with the new project is the easiest. although copying the classes isnwhat we all do when using external libraries such as cocos2d. As far as sharing it with others, just upload it to github another place of your choice so it can be used by other dev's. I hope this helps you.t
I don't know how mature the code is, but since you specifically mention wanting to share it with other developers, you may want to investigate CocoaPods.
I've been working non-stop for the last three days on a completely managed interface to Erlang. At this point, I've decided that there simply must be an easier way. I've got a little over 3000 lines and it's not even in a compilable state yet. To be honest, I'm getting lost in my own code.
So, I then remembered that Erlang has a C library called erl_interface. Unfortunately, it only comes as a .LIB file, which isn't usable via P/Invoke. I'm now investigating ways to expose the static library through a DLL.
I'd like to stay away from Visual C++, mostly because I'm not a C/C++ programmer by nature and I find it really difficult to configure. TinyC is my compiler of choice when working with anything in C.
How can I go about this?
I know I can link erl_interface to a DLL, but how can I expose the functions? Do I have to essentially wrap each and every one of them in my own exports? That probably won't be a problem, since I could write a script to generate the code from the header file. But is there an easier way that I just don't know about?
Also, please don't recommend OTP.NET. It's a nice library, but I'm looking to use this is a large project, so I'd like to keep it in-house.
So, your problem is one of turning a static lib into a dynamic one.
The least-effort solution would be to write a thin shim file in 'C', that just delegates to the files in the .lib e.g.
ReturnType my_method1(args...) {
return real_method1(args...);
}
...
and build a DLL from that and the static lib.
Afterthought -- There is another approach you could take -- which is build the .lib into a C++/CLI assembly and do the transition/wrapping in that. It's what C++/CLi is there for, after all.
If you want some help with interfacing to Erlang with C, have a look at "EPAPI" (Erlang Port API) link text. You can of course browse the source code since it is hosted on Google Code. A DEBIAN repository is also available.