I use VS 2008 (it suits me, later versions offer me no benefits) and I am cleaning up my various libraries but running into some problems. I have always linked directly to source files rather than the dll produced by class libraries and thought I would switch to doing things "properly" by linking to the dll but it is causing me some problems.
I have several libraries but the current issue is caused by:
JGLibrary - just requires the Net Framework (I standardise on 3.5).
JGContacts - basis of my address book app, uses JGLibrary.
I am reworking my address book which uses both JGLibrary and JGContacts and am getting the following error message:
The type 'JGLibrary.JLibrary' exists in both 'd:\Data\Visual Studio 2008\Projects_Common\JGContacts\JGContacts\bin\Debug\JGContacts.dll' and 'd:\Data\Visual Studio 2008\Projects_Common\JGLibrary\JGLibrary\bin\Debug\JGLibrary.dll'
It is, presumably, because JGLibrary is used by both JGContacts and my address book - that's what a library is for.
Using the address book example should I just use the JContacts dll and rely on the fact that I can access my JGLibrary functions through it (which makes me slightly uncomfortable) or is there another way to manage this? I don't have this problem linking directly to the library files which makes me wonder if I should just go back to that but it does mean linking to a dozen or so individual files rather than just one dll.
I would appreciate guidance/thoughts.
Related
I'm currently working on a contract job where I've been asked to help integrate a 3rd party SDK with an existing React Native app. The SDK only comes in Android and iOS specific flavors, meaning that it has to be added on the platform-specific side of things (in my case, the iOS side with Xcode).
For the app, the client has created a react native module which gets built into a Library in Xcode, represented by a separate nested Xcode project in Libraries/MyLibrary.xcodeproj from the root of the base Xcode workspace project. This library has several method stubs defined in React Native which will need to be implemented in Swift (and likewise in Android), as this is in these methods that the 3rd party platform-specific SDK is utilized.
The issue I'm having has to do with accessing the 3rd party SDK framework in the library's existing bridging header file. I have followed every tutorial under the sun for how to integrate external frameworks with an existing Xcode project. This includes steps about adding the framework to the project, adding it under the Embedded Binaries and Linked Frameworks and Libraries sections of the project target, adding it under the Build Phases/Link Binary With Libraries section of both the project target and the library target, and adding the framework path under Project Settings/Framework Search Paths. From here, I add the appropriate import statement to my library's Library-Bridging-Header.h file with #import <MyFramework/MyFramework.h> so I can then access the framework in Swift. (This import statement is copied directly from the bridging header file of the sample project included with the SDK, so I know it is correct and should not be given in a different format such as quotes instead of angle brackets).
Regardless of following all of these steps multiple times over and in various combinations, I still get this error at build time: MyFramework/MyFramework.h file not found.
To clarify, MyFramework is just an alias for the actual 3rd party framework I'm attempting to integrate, and MyLibrary is an alias for the existing library with nothing but method stubs given to me by the client to implement in Swift.
Again, I have read every tutorial and forum under the sun, but none seem to address this very specific issue of integrating a 3rd party framework in a xcodeproj Library within the iOS version of a react native app. I would appreciate any new insights or suggestions anyone might have to offer! And please, please don't just post a link to or copy the steps from existing forum posts about a similar-sounding issue, as I've probably already read it 😉. Understand that I think that there is something subtly unique about my specific circumstances which are causing these same steps from the 10+ articles that come up on the first page of Google and StackOverflow NOT to work.
Figured it out! I'll post my solution here in case anybody out there ever runs into the same issue as me.
TLDR - You must add the 3rd party framework in the root of the xcodeproj Library (NOT the top level project) AND ensure that the files were actually copied into that directory, not just referenced from the directory you copied the framework from (be sure to double-check in Finder, since checking the 'Copy if needed' box doesn't always work for some reason). Then, you must add $(PROJECT_DIR) to your xcodeproj Library's Build Settings/Framework Search Paths, and also drag and drop the framework from the root of your xcodeproj Library into the Library's Build Phases/Link Binary With Libraries panel.
I'll address some of the issues with other tutorials/forums that I found, with hopes that it might help someone else that finds themselves as frustrated as I was in this position.
Most only address adding the framework to the base level project, not the obscure case of a project within a project. Therefore, when you start following the steps, it can be confusing to know whether you should be changing the settings of the top-level project or the sub-project. Again, as I discovered, all changes should ONLY be made to the sub-project.
There are a few tutorials that do seem to address this situation regarding a project within a project, but the steps describe adding the framework to the top-level project under Embedded Binaries and Linked Frameworks and Libraries, but I believe the situation described in these tutorials are somehow subtly different than this situation here. Again, only mess with the sub-project.
There's a lot of discussion out there about "umbrella frameworks", but that doesn't really apply to this situation, and again, the terminology similarities can make it seem like it's a similar issue. As I understand it, "umbrella frameworks" are discouraged by Apple, but again, this situation is not the same.
Sorry for the long-winded explanation, but I'm hoping to provide the kind of detail I would have liked to have found when I was searching for solutions for this weirdly obscure problem.
Cheers!
I add the UnityEngine.UI.dll and UnityEditor.UI.dll to my assets folder with their mdb files . also i add the both project to my current project. i am sure all the unity engine ugui code build success, because i debug log in the event system, and it print message. when i want to step into the event system class, i always failed . I find unity will load the code from a build path ,rather than i original code. Why does it do this ? if i want to debug unity engine ugui code, what should i do ?
To debug code, you need two things:
Symbols, the list of all functions, classes, variables used throughout the module. When using C++ symbols are stored in special .pdb files on Windows (and you obviously are using Windows since you are talking about dlls). Symbols in C# (.NET in general) are stored in the .dll itself. Having symbols will let you see the name of functions on the call stack and possibly some variables but nothing more.
Source code of the module.
U3D's source code is proprietary - you need to spend a good amount of money to receive it. And if I am guess to - UnityEngine.UI.dll is a C++ module with stripped (removed) symbols removed.
Thus you have neither, so you can't debug U3D's code at all.
Why would you need to that anyway? If you want to see how the internals of a big game engine work, there are plenty of other options (for example UE4 and Lumberyard). If you are struggling with a problem and you'd like to be able to solve it through debugging...well though luck. Your best bet would be to ask in unity community.
Often, especially when dealing with malware files, you'll end up in a situation where all the APIs are dynamically resolved at runtime inside a given buffer, this approach considerably slow down the reversing process (and makes the decompiler useless: (DWORD *)dword_123456(INT, UINT)()) because the analyst has to run the malware, resolve the api and by hand put a comment next to each api call. I've found the indirectcalls plugin, but it seems to work only with "standard" C++ methods. Is there any script, or funcionality I don't know about, that's able to patch the executable, even during the debugging, in order to call the APIs with their real names?
There is a script called renimp.idc that is shipped with IDA in the idc folder of IDA's installation directory. Just attach IDA at runtime (in cases of malware analysis you will probably better want to use a remote debugger), navigate to the API address table created by the unpacker and select all entries. Then run the said script. It will rename all pointers to the correct API it points to, so IDA's type-library is able to resolve the correct typedefs for it from it's internal database again.
I have gone through this post and the links, and still can't solve my issue.
I have changed my config to name the assembly, but it makes no odds.
We recently moved the projects and think that might be an issue - but how to solve it if so. I don't quite understand how EF when running finds the cdsl etc. files I thought they were embedded in the dll [it is set to do so]?
The service having the issue doesn't directly use EF itself, it uses another DLL which DOES. I also added a direct ref to the DLL but no joy.
Also, the same code (the dll that contains the functionality, not the wrapper service) using the same connections strings works fine in my system test project via the IDE.
Turned out to be down to incorrect initialisation of StructureMap and not really to do with EF itself.
I see a lot of questions, both here on SO and elsewhere, about "maintaining
common libraries in a VCS". That is, projects foo and bar both depend on
libbaz, and the questioner is wondering how they should import the source
for libbaz into the VCS for each project.
My question is: WTF? If libbaz is a library, then foo doesn't need its
source code at all. There are some libraries that are reasonably designed
to be used in this manner (eg gnulib), but for the most part foo and bar
ought to just link against the library.
I guess my thinking is: if you cut-and-paste source for a library into
your own source tree, then you obviously don't care about future updates
to the library. If you care about updates, then just link against the
library and trust the library maintainers to maintain a stable API.
If you don't trust the API to remain stable, then you can't blindly
update your own copy of the source anyway, so what is gained?
To summarize the question: why would anyone want to maintain a copy of a
library in the source code for a project rather than just linking against
that library and requiring it as a dependency?
If the only answer is "don't want the dependency", then why not just
distribute a copy of the library along with your app, but keep them
totally separate?
The use of vendor branches to control 3rd party dependencies is discussed in some depth in the Subversion book. As I understand it, the basic advantages are guaranteeing a stable API and uniformity of libraries for all developers, and the ability to control custom modifications in house in the same versioning system.
On the project I'm working on right now, we've got the main code (which is in one Subversion project) and a host of assorted libraries from various places that are in their own Subversion modules. The Visual Studio solution maintains separate projects for each of them and links them together at the end. If we were working on Unix or similar OSs, we'd do the same thing.
The only downside I see is that I sometimes forget to update one of the libraries that changes more frequently, and my code doesn't compile until I notice that. If we had the libraries in the same module, then we wouldn't have that problem. (Not that I'd ever do it that way. The gains in flexibility and the ability to use different libraries with different main projects are just too great.)
The API is a red herring here: either it stays the same or it changes, and if it changed we'd have to update the main code either way. So is the question of source vs. binary libraries (either we compile them with the main project, or we don't).