Hello I am trying to develop an application using c# and I am using the System.Drawing DLL. However, I get an exception for when I run it pretty much saying the System.Drawing.GDIPlus DLL was not found when I am including the System.Drawing DLLin my build. Are there any ways to do this or am I hopeless and need to figure out a workaround.
Related
for a different project I am trying to get a native C++ library (libsvm.dll) running on a Microsoft Hololens in a Unity Project.
To try and understand how using native dll's should work, I followed this tutorial exactly:
https://learn.unity.com/tutorial/working-with-native-plugins-2019-3#
When I run the project it works completely fine on my Windows PC, and it also builds correctly for the HL.
But when I try to start the project on the Hololens I get the following error:
Exception thrown at 0x776E9FC7 (ntdll.dll) in DLL Test.exe: 0xC0000139: Entry Point Not Found.
Does anyone know how I can fix this? The dll is imported in Unity targeting x86 and the UWP SDK, so I think the Unity side is fine. Help would be greatly appreciated.
After going through this unity tutorial, I find that the project template Dynamic-Link Library (.dll) you selected as the scaffolding when getting started to create a C++ DLL in the Visual Studio. If you created your C++ DLL as a Win32 binary, it would throw exceptions when running on the HoloLens2 because Unity will not include standard Win32 binaries when it builds a WSA project. Therefore, it’s recommended to recreate or port a native win32 DLL to the UWP DLL, see the guidance here: To port a native DLL to the UWP without creating a new project
I have followed this example on how to mix C# and C++ code in single assembly and all compiles fine. But all this is from the developer command prompt. I want to put all this in one Visual Studio solution and can't succeed. Does anybody know how to do that? (I am still very inexperienced with Visual Studio)
I have found several articles about this, but all give examples from the command prompt. This SO answer even recommends not doing this at all, not sure why?
Also, many of those articles talk about creating a managed DLL (using dllexport/dllimport, but I need to link the obj/lib files directly in the same C# assembly.
Note: The reason I need to do this, is to add a licensing static library to my C# desktop application project. The library is written in C/C++ and is already used in my back-end, I would like to use the same logic for the front-end. Loading the library as a DLL would defeat the purpose since anybody could just change it for a fake one. Therefore linking it in the same assembly is essential.
I am writing an example UWP program, that uses EmguCV (an OpenCV wrapper for programs written in VB, C#, .NET, etc.), to see if I can use it in a UWP app for a project I'm working on. I'm using Visual Studio 2017 Community and EmguCV 3.3.0.2824, which I downloaded the Windows installer and ran it on this Lenovo Thinkpad laptop with Windows 10 Enterprise x64.
For some reason, when I try to build the solution, I get these two compiler errors in this photo.
In plain text:
XamlCompiler error WMC1006: Cannot resolve Assembly or Windows Metadata file 'System.Windows.Forms.dll'
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\WindowsXaml\v15.0\8.2\Microsoft.Windows.UI.Xaml.Common.targets(354,5): Xaml Internal Error error WMC9999: Type universe cannot resolve assembly: System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
Why do I have an Assembly conflict between Emgu.CV.UI and the UI namespace in the UWP API? What can I do to enable using both in my app?
This photo is what the Solution Explorer looks like.
In plain text:
I have all the default files Visual Studio 2017 generates when I create a blank UWP application. In addition, I have a file called RTG_Demo_App.dll containing some code written in C++ that uses OpenCV. In the References group, I am referencing Emgu.CV.UI, and Emgu.CV.World.
I am using the default code App.xaml.cs has, as well as MainPage.xaml.cs, with the exception that I have the following lines:
using Emgu.CV;
using Emgu.CV.Structure;
using Emgu.CV.UI;
After doing some research and experimentation, the root cause I found is a conflict between the reference to Emgu.CV.UI (Emgu.CV.UI.dll), and the UI namespace in the library for the UWP. I can't remove the reference to the "Universal Windows" library because it's part of the UWP framework I need for the project.
I did do some research around, except I couldn't come across a resource to where the project involves EmguCV with scripts written in C# directly and to be built for the UWP, rather than Visual C# or .NET.
What I am trying to accomplish here is a project where OpenCV is used, the target is UWP, and the scripts are in C#. OpenCV is not supported by C#, so I'm using EmguCV instead.
Please help me out here.
System.Windows.Forms is not available for UWP projects since it is a wrapper around User & GDI, which are both unavailable for UWP.
You can use a Desktop Bridge project if you only want to ship on Desktop.
I have an proprietary Android app (created with Android Studio) and I need to add some functionality which requires to use a C# DLL.
The app is connecting wirelessly to a development board that does some sensor measurements. Normally on windows apps the dll is used to do some complex calculations of calibration coefficients for the measuring.
My problem is:
I don't have the the source code of the DLL and most likely I won't be approved to access it.
I've read that you can use xamarin to make android apps and use C# dlls but I can't rewrite the whole app for xamarin just to use the dll (also I've never used xamarin)
So far I had the idea to build a simple http server with C# that gets parameters with a GET request, runs them through the dll and returns the results. However it's not an ideal solution because it requires a separate pc to run the server and the adndroid device to have a network connection to it.
My second idea is to build a separate app with xamarin that uses the dll and make my main app start it just to calculate the coefficients and get the results. Perhaps make the second app not visible in the launcher and somehow distribute the two apps together.
Since I am not experienced with android development and especially xamarin and I don't have a lot of time to waste on this project I want to know if my idea is feasible or if there is a better alternative.
Can you suggest some useful tutorials for xamarin and using dlls with it?
===============================================
Edit
I have managed to get the source code of the dll project which is in C++ (and full of windows only stuff) and now I'm trying to use NDK to compile it and JNI with Android studio to use the native functions. Unfortunately almost every step has it's own quirks and problems and it's far from smooth :/ I wouldn't recommend it to beginners like me!
I know this answer is late, but I'm in a similar situation right now.
This project here helped me setup a native Android Studio build with an embedded C# lib:
https://github.com/royd/KotlinAppWithXamarinDependency
The only issue I'm facing right now, that I can't get the R8 obfuscation/optimization to work without breaking the app.
I was looking for a way to implement a WebSocket server and came across SuperWebSocket which seems to have the most features. I downloaded the source code, looked at the samples (and the Echo server tutorial), but still have no clue how to do it.
I found this guide and it seemed to point me in the right direction, but I get errors with the references. I add the references to all the dlls, and I manage to import them 'using Superwebsocket.Common', but when I try to build I get an error telling me that they cannot be found.
The issues you describe sound similar to my problems trying to get the SuperWebSocketWeb demo up and running. I had a similar problems with the project references, which at design time in visual studio seemed fine but failed during a build.
To solve this I made sure that the demo project and SuperSocket assemblies were all built targeting the same .net framework version (4.5 in my case).