I've installed several packages in a Unity (2020) app I'm building. Namely: World Locking Tools, MRTK, PUN2. World Locking Tools provides some examples that are built with assemblies defining scripting symbols that any derived files I want to build would need access to. I'd like to create my own version of certain files from one of these examples. To do this and have access to the scripting symbols in one of those examples, I created an assembly reference to reference the assembly for that example code within World Locking Tools package installed in my project space. In so doing, I kept running into the common "...not found, are you missing an assembly reference" issue, which ultimately led me to creating assembly references for many of the assemblies provided by the various packages I needed to use (not just the particular example code I initially wanted to modify). Once my project finally built successfully in unity, I then tried to upload to a Hololens 2 headset in Visual Studio. This provided the error in the title of this post. Coincidentally, the app also appears to fail to start on the headset. Before I tried to alter my codebase with modified versions of files from that World Locking Tools example and with assembly references, the code would successfully build in Unity and successfully deploy to the Hololens 2 headset.
Does the behavior and missing .pdb error I describe mean that I'm missing assembly references for yet other packages even though Unity successfully builds the project?
This is my first foray into using assemblies so be please be gentle :)
For the .pdb message, that one is ignorable since will not have that symbol available. However, the app not starting is definitely likely due to a missing component or loading issue. When ran in debugger, may get a better idea on what is missing or from a debugger log in Unity.
Related
I am working on a project that uses Adobe's DNG SDK 1.6 library, and it is supposed to work on Windows and MacOS.
The library has instructions on how to build it for both platforms, but I had to figure out an error that came up on Windows with Visual Studio. I am not very experienced with big C++ projects so it was not trivial but I got it working. Most of my own code will be done in C# .Net Core, calling the native libraries using a wrapper class with P/Invoke.
Now for Mac that's a different story, I have a MacOS 11 VM, installed Xcode 12.5.1 and followed the steps provided, as expected, it does not work. Bare in mind this is my first time touching Xcode and MacOS.
The project I am trying to build is dng_validate, and it depends on two libraries built by these projects: XMPFiles64 and XMPCore64.
The library projects build without any hiccups, each one of them creating a ".a" file in the folder: dng_sdk_1_6/xmp/toolkit/public/libraries/macintosh/intel_64_libcpp/Debug, they are named libXMPFilesStaticDebug.a and libXMPCoreStaticDebug.a respectively.
When I try to build the dng_validate project, I get the following error:
Library not found for -lXMPFilesStaticDebug
Because of the the error starting with an "l" instead of "lib", under both libraries project settings, I changed the "Executable Prefix" setting to "l" instead of "lib". Rebuilt both of them and made sure the file names changed as expected. But the error persists when trying to build the main project.
Under dng_validate's project settings, there is a setting called "Library Search Paths" and it does point to the proper aforementioned folder using a relative path. I even changed it to an absolute path to see if that would make it work.
I am really lost here, does anyone have an idea of what might be causing it?
Well... After asking on other forums and almost hiring a freelancer to fix this for me, I tried another shot in the dark of renaming the library files and it worked.
I changed the extensions of libXMPFilesStaticDebug.a and libXMPCoreStaticDebug.a from ".a" to ".dylib" and it just compiled and blew my mind with it.
I built a VB Windows Forms application a while back using VS05 (or VS08? Not exactly sure) that I've recently converted to use VS10. I reference a .dll called ExcelPackage (another article, usage) so that I can create/manipulate Excel docs serverside. This app has worked fine on my old computer (PC/Vista) for a number of years. However, I have tried to move it to my new computer (PC/Win7 64-bit), and I can't get it to recognize the ExcelPackage .dll.
I have tried recompiling the .dll in VS10 and dropping the new .dll in my bin folder and re-referencing it. When I do this, before I try building, all my errors go away and I am actually able to navigate the class using VS10's built in ability (mouse over Imports OfficeOpenXml and you get a dropdown arrow that allows you to go through the classes). After I build, I get a green squiggly under my Imports OfficeOpenXml statement (can't find the reference).
I did some research and discovered that the .dll containing System.IO.Packaging has been moved around in .NET 3.0 and even re-referenced the new .dll, rebuilt, re-added, re-referenced, still no dice.
Am I missing something, or how do I get my application to recognize this assembly so that I can compile and continue working?
Thanks.
I don't see anything special about that project. Do note that the solution and project need to be converted. When that happens, you'll end up targeting the .NET 2.0 framework. That won't work out well, it has an assembly reference to WindowsBase, a 3.0 assembly. Make sure you update the target.
I have an application with a plug-in architecture that is using Boost.Threads as a DLL (specifically, a Mac OS X framework). I am trying to write a plug-in that uses Boost.Threads as well, and would like to link in the library statically. Everything builds fine but the application quickly crashes in my plug-in, deep within the Boost.Threads code. Linking to the DLL version of Boost.Threads seems to resolve the problem, but I'd like my plug-in to be self-contained.
Is it possible to have two instances of Boost.Threads with such a setup (one as a DLL, one statically linked in another DLL)? If so, what might I be missing to make the two instances get along?
Once my team faced a similar problem. For reasons I will not mention at this time, we had to develop a system that used 2 different versions of Boost (threads, system, filesystem).
The idea we came up with and executed was to grab the source code of both versions of Boost we needed, and then tweak one of them to change the symbols and function names to avoid name clashing.
In other words, we replaced all references to the name boost for bubbles inside the sources (or some other name) and also made changes to the compilation so it would build libbubbles instead of libboost.
This procedure gave us 2 sets of libraries, each with having their own binaries and header files.
If you looked at the source code of our application you would see something like:
#include <bubbles/thread.hpp>
#include <boost/thread.hpp>
bubbles::thread* thread_1;
boost::thread* thread_2;
I imagine some of the guys here already faced a similar situation. There are probably better alternatives to the one I suggested above.
I have to maintain an old VB 6 ActiveX DLL called by another third-party program for which I have no sources. This DLL works and compiles fine against the API of said program for about 6 years and 3 major versions.
But now when I try to compile the DLL against a new major version the mentioned error occurs. It seems the error occurs before "my" code is called so there´s no use debugging or logging. The only remedy was to compile w/o binary compatibility which is no real option. My Google search turned up quite some people with the same problem but no solution.
Does anybody here know how to fix this issue ?
I finally figure out how to diagnose VB6 error 32801 in a systemic way.
My theory is When the VB6 compiler is creating a project or binary compatible library, the compiler decompiles the type information from the referenced library. Error 32801 occurs the source code's type information is not the same as the referenced library.
There is a tool called OLEView. This tool can decompile the COM type information into an IDL text. What I do is decompile the referenced library in to IDL and take the last good build of the failing library. Most times it is a build server version but the build does not work on a developer workstation. Decompile the last good build. Use a text comparison tool, like WINMerge, and find the differences between the type libraries. The differences make it easy to track down the problem.
Depending on the difference will determine how to correct. Mitigation can be done by either correcting the reference DLL, or by source code correction, or source code references.
It sounds like one of the types in the interfaces defined in your new DLL is different from one in the previous DLL. I'm deducing you use types defined in the third party program in your public interfaces of your DLL. It sounds to me like the third party has changed the definition of one of the types but kept the name and GUIDs the same. You could use something like OLE/COM Object viewer to check whether that's true. If it is true then you can complain to the publisher of the 3rd party program. Do you have enough political power to succeed?
Bruce McKinney, the guru who wrote Hardcore Visual Basic 6, ran into the same issue with a structure in a type library, where he changed some of the member types. The only fix he could find was (essentially) to break binary compatibility - and that's after some correspondence with the VB6 compiler team, who he knew fairly well. I don't think anyone else could do better.
There is a discussion about this error on devx.com that seems to indicate that the problem stemmed from Microsoft's Scripting Runtime (scrrun.dll).
FileSystemObject compatibility Unexpected error (32810)
Does your DLL reference that library? If so, can you remove the reference (e.g., replace FileSystemObject functionality with intrinsic VB file handling functions and/or API calls).
Are any of the files associated with the core project being compiled marked as Read-Only (i.e. not checked out of SourceSafe or similar repository)?
*.exp
*.vbw
*.lib
---------------------------
Microsoft Visual Basic
---------------------------
Unexpected error (32810)
---------------------------
OK Помощ
---------------------------
This the message I was getting trying to reference in VBIDE an old OCX that has been recompiled recently.
After somewhat long research the offending lines of code causing this error appeared to be
Property Get MouseActivate() As BookmarkEnum
Just changed this to
Property Get MouseActivate() As Boolean
. . . and the error was gone.
BookmarkEnum is an enum from ADO. Our build server is Server 2003 and my dev machine is Win10. The project references ADO 2.8 but apparently this typelib has some differences on Server 2003 vs Win10
This I think is related to my use of the nlog C++ API (and my question on the nlog forum is here); the purpose of my asking this question here is to get a wider audience to my problem and perhaps to also get some more general ideas behind the VB6 IDE's failure to build in my particular scenario.
Briefly, the problem that I am having is that I am having trouble building VB6 components which reference unmanaged C++ components which have calls to nlog's C\C++ API (which is defined in NLogC.DLL). The build problems are not occurring during compile time, they are occurring when the binary is being built which suggests to me that it's some kind of linker type problem? Don't know enough about how VB6 binaries are produced to tell. The VB6 binary is produced, but it is corrupted and crashes shortly after it is invoked.
Has anyone had any similar experiences with VB6 (doesn't have to be related to nlog or C++)?
edit: Thanks for all the responses to this rather obscure problem. Still no headway unfortunately; my findings since I posted this:
'Tweaking' the compile options doesn't appear to help in this problem.
Adding a reference to the nlog-enabled C++ component from a 'blank' VB6 project doesn't crash it or cause weird build problems. So it isn't a 'native' VB6 issue, possibly an issue with the interaction between nlog and the various components and 3rd party libraries used by other referenced components?
As for C++ calling conventions: the nlog-enabled C++ component is - as far as I can see - compliant to these conventions and indeed works fine when referenced by VB6 as long as it is not making any nlog API calls. Not sure if the nlogc.DLL itself is VB6 compliant but I would have thought that that is immaterial since the API calls are being made from the C++ component; VB6 shouldn't know or care about what the C++ component is referencing (that's as far as my understanding on this goes...)
edit2: I should also note that the error message obtained during build is: "Errors during load. Please refer to "xxx" for details". When I bring up the log file, all that there is in there is: "Cannot load control xxx". Interestingly, all references to that particular control disappears from that particular project resulting in compile errors if I were to try to build again.
Got around the problem by using NLog's COM interface (NLog.ComInterop.DLL) from my unmanaged C++ code. Not as easy to do as the C\C++ API but at least it doesn't crash my VB6 components.
I would try tweaking some of the Compile options found in the Project, Properties menu, Compile panel to see if they yield any additional hints as to what is going wrong.
For example if you compile the executable to p-code rather than native code does it still crash on startup.
What error message do you get when you run your compiled binary?
I doubt the compiler/linker is the problem: project references in a VB6 project are not linked into the final executable. A project reference in VB6 is actually a reference to a COM type library (which may or may not be embedded in a .dll or other binary file type). Project references primarily serve two purposes:
The IDE extracts type information from the referenced type libraries which it then displays in the Object Browser (and in the Intellisense drop-down)
At compile-time, the compiler extracts the type information stored in the referenced libraries, including the CLSID of each class that you instantiate, and embeds this data into the executable. This allows your executable to create instances of classes contained in the libraries that you referenced.
Note that the compiled binary doesn't link to any code in the referenced libraries, and it doesn't even contain the filenames of the referenced libraries. The final executable only contains the CLSID's and other type information that it needs to instantiate COM objects at run-time.
It is much more likely that the issue is with NLog, or with how you are calling it from your code, rather than something gone awry in the VB6 compile process.
If you think it might be a linker problem, this should crash it the same way:
create a new standard project (of any kind)
add a new module and copy the "declare"-statements into it
compile
If it doesn't crash it is something else.
It would help an exact description of the error or a screenshot of what going on.
One thing to check is wherever NLogC.DLL or the C++ DLL you built have the correct calling convention defined. Basically you can't have the DLL function names mangled or use anything but the STDCALL calling convention. If the C++ DLL has not been created with those two things in mind then it will fail to work with VB6.
MSDN Article on Calling convention.
"Cannot load control xxx" errors can be caused by .oca files which were created from a different version of an .ocx than currently used. If that is the case, deleting the .oca files helps.