is it possible to build the OpenCV-DNN module for 32-Bit UWP? I cloned the official OpenCV repository and generated the VS-Projectfiles with the Generator "Visual Studio 14 2015" and set the flags -DCMAKE_SYSTEM_NAME=WindowsStore -DCMAKE_SYSTEM_VERSION=10.0. However building for UWP will cause the dnn-module to not be included, so I changed the cmake files to include the module and I was able to build the binaries with Visual Studio.
Now here is the problem:
When I create a C++ UWP-Application, link the opencv_dnn.lib file, consume it and launch my app, I get the error:
"Unable to activate Windows Store app MYAPP. The MYAPP.exe
process started, but the activation request failed with error 'The app
didn't start'."
This happens for the debug and release configuration. If I link it, but don't use it at all in my code, I do not get the error. I looked the error up, but was not able to fix it.
Since the unmodified cmakefiles provided in the repo exclude the dnn-module when targeting UWP, I tought, that it is not possible to build this specific module.
Does anyone why this error would occur or if it is possible to build it with UWP as target? I did find this , which suggests that it is possible, although there bugs (not related to linking).
Thanks in advance.
Ok, so i figured it out. I did get the same error for every other opncv module. The problem was that Visual Studio didn't find the opencv dlls despite them being listed under the PATH env variable. I added the dlls to my project folder and was able to launch my program and use opencv.
Related
I'm going to create my first managed plugin for Unity (2018.2) using Visual Studio Community for Mac (7.6.11 build 9).
I've read the documentation but I think that the step-by-step instructions are not meant to be followed on Visual Studio Community for Mac.
As you can see in the screenshot below, I've created several projects using each and every library template available.
All of them compiled successfully to a DLL targeting versions of .NET framework that are incompatible with Unity.
The only project I could change the .NET framework version to match Unity's 3.5 is the one based on the Other > .NET > Library.
Everything works fine but I'd like to know if the assumptions, the process and the final result are correct. Can you tell me, please?
I don't know the difference between the "Class" and the "Class Library" option but you're supposed to use the "Class Library" option. This is not the main point of this answer.
Two future issues you haven't solved yet:
1. Referencing Unity's API.
If you ever have to use any Unity library or API in youir plugin such as Vector3, you need to add Unity's UnityEngine.dll to your library settings. If you don't, you will run-time exceptions.
Go to Project --> Add Reference ---> Browse ---> Browse Button
then select <UnityInstallationDirecory>\Editor\Data\Managed\UnityEngine.dll. You can now build your managed plugin. Since you're using Mac, this path is different on your OS. On Mac, this could be /Applications/Unity/Unity.app/Contents/Frameworks/Managed/UnityEngine.dll. You just have to find where UnityEngine.dll is located.
2. Invisible stack trace
With your current setup, if you run into error with your managed plugin, the stack trace won't be there. You won't have the file names and line numbers and this makes is very hard to debug your plugin code.
When you build the project, Visual Studio generates a PDB file instead of an MDB file. Unity can't use this directly. You have to convert the PDB files into MDB files.
From command line, run this:
<UnityInstallationDirecory>\Data\MonoBleedingEdge\lib\mono\4.5\pdb2mdb.exe UnmanagedPlugin.dll
Again, the path might be different on Mac, you just need to find "pdb2mdb.exe" that converts the PDB files into MDB files.
After that, copy the MDB and dll file into the "Assets" folder in your Unity project.
I am using visual studio 2010 under Win7-64bit to build an application with openCV. I finished development and build the release version without error. I also successfully run the program in debug mode. I then move the .exe file to other directory in the same computer. I run it in cmd.exe and I got error warning: Error opening file <../../modules/highgui/src/cap_ffmpeg_implhpp:537>
I guess there are some dependence with some libraries of openCV but I don't how to solve it. My final task is that I can use that .exe in another computer under Win7 directly. How to do it?
I found a similar question here. But I don't have .dll file built, so what should I do to solve this problem?
Building an OpenCV app with shared libs (DLLs) require the DLLs to be available (same folder or in lookup path) to the exe when it is run.
If you are using static linking then you don't need any of the OpenCV DLLs to be reachable. However, due to licensing issues, ffmpeg is linked dynamically even when the rest of the libs are linked statically, and thus, you need to have the ffmpeg DLL available for the exe. It is called something like opencv_ffmpeg*.dll.
Note that this is only needed if you are using highgui related functionality.
I am trying to build an iOS app on windows visual studio using Xamarin For Visual Studio Trial. When compiling I am getting this error:
Error 136 MT5201:Native linking failed. Please review user flags provided to gcc: "-L/Users/brandon/Library/Caches/Xamarin/mtbs/builds/iCropTrak_vsios/9bc8504a-65b2-484f-b71c-1d0cb02d21f6" "-lgdal_x86" "-lc3dsqlite3" "-lstdc++" "-all_load" [K:\Development\AZSim\Products\CropTrak\iCropTrak_vsios.csproj]
0 0
It compiles fine on the mac - but having trouble getting it going with the windows version. Any ideas as to why?
Do you use {ProjectDir} in your project options ? If so you might be running into a current limitation where the directories won't match between platforms.
You should be able to workaround it, either by replacing {ProjectDir} or much better by using the [LinkWith] attribute.
You can bundle the Native reference inside a dll.
Take a look on this: http://forums.xamarin.com/discussion/comment/5371/#Comment_5371
and this:
https://github.com/viniciusjarina/NativeBindingVS
Thank you.
we discover this issue like two weeks ago, this only happens in simulator AFAIK. Seems that the dependency LevelDB left their Main symbol. I'll file a bug on Firebase. The workaround for this is to change the behavior of the Registrar on Simulator:
Open your project settings
Go to Build tab
Select iOS Build option
Type --registrar:static in Additional mtouch arguments textbox
Click on Ok
Don't forget to add this in Release and Debug configuration of iPhoneSimulator platform.
when i checked the source of the packages i found that they relies on
Xamarin.Build.Download
when i install the package problem resolved .
I'm not a a very experienced Windows developer, so I hope this all makes sense.
I created a Managed Assembly DLL using Visual Studio 2010. The DLL (Plip.dll) contains a C++ class that is using System.IO.SerialPort class to do some simple communication over a serial port.
In a second Visual Studio project I created a simple GUI that uses the class found in Plip.dll. In my GUI project I have the line : #using "Plip.dll" . In the Project Properties I set the 'Resolve #using References' value to the correct location of Plip.dll. The GUI builds just fine. If I copy the GUI.exe and Plip.dll to the same folder, the GUI runs just fine on my computer.
The problem I am having is that when I copy both files to a second computer, I cannot get the GUI executable to run. I get the following error : "System.IO.FileNotFoundException. Could not load file or assembly "Plip.dll" Vesion=.... ". I get this error even though both the exe and dll are located in the same folder.
Any suggestions on how to resolve this issue? Is there some option I need to set in my GUI project to load the DLL correctly at run time?
I suppose the problem is not the Plip.dll, but it's dependencies.
Use Dependency Walker on the second computer to see if it needs any other dll's (they might be installed in System folder or in %PATH% on your development computer, but not on the other).
If this second computer doesn't have Visual Studio installed, you are probably missing Microsoft Visual C++ 2010 Redistributable Package (you need to install it on the other computer)
Also make sure that you compile in Release because debug builds need debug dependencies.
I found the answer to this problem to be much simpler than Dependency Walker (but admittedly, that was fun to look at).
In my case, the issue was a mis-match between the .DotNet versions in the DLL and with the application's .net version. This was caused by building the "class library" using .DotNet 6.0 (dot net core?).
Instead, the entire class needed to be re-built using "Class Library (.NET Framework)"
enter image description here
I wrote an article on this problem.
https://keyliner.blogspot.com/2022/09/visual-studio-c-linked-dll-exception.html
I'm attempting to find the minimum installation requirements for getting WP7 projects compiling on a Windows 2008 R2 build server. I'll be looking into automated testing using the emulator at a later point, but right now I'm stuck on the build side.
I realise this approach won't be supported and I'm willing to trash the VM at a later date if an update proves to be incompatible (assuming I get it to work at all)
I'm also aware of the workaround for installing the entire SDK on Windows 2008 R2, but I'm trying to avoid installation of Visual Studio (it's now become a curiosity more than anything else)
As it stands, I've installed the following from the SDK ISO:
WCU\Silverlight4\silverlight_sdk.msi
WCU\WindowsPhone\WindowsPhoneExtensions.msi
WCU\WindowsPhone\VS_SDEProLightup-enu.msi
At this point, it is able to locate all the required MSBuild target files and even compiles the project. The problem appears at the end of the process during the XapPackager target, when it errors with:
Xap packaging failed. Unable to load DLL 'zlib114.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
Using Process Monitor, I can see that MSBuild finds the dll in the WP7 MSBuild targets directory that installs with the SDK with the only error being "FILE LOCKED WITH ONLY READERS" error to a CreateFileMapping+SyncTypeCreateSection, which it then falls back to a SyncTypeOther, which succeeds. Despite this, MSBuild still continue to look for the dll is all the other standard locations (Framework directory, SysWOW64, etc).
Any thoughts to why it might be failing?
If you're using TFS, Justin Angel has a great post on TFS2010 WP7 Continuous Integration. Given that TFS is just wrapping around MSBuild, you may find this a particularly useful resource. When it comes to doing the unit test integration, Deyan Ginev from Telerik has a series of posts that covers this.
FYI, I ended up fixing the zlib problem by using the dll from the Silverlight SDK, rather than the WP SDK.