I'm using a service called JNBridge which is used to create proxies for Java files to be used in C#. The service works fine and I can easily create a C# solution in Visual Studio 2017 and call Java files from created proxies. I would like to use this in a Unity project however but I'm not sure how I would accomplish this.
In order to get this to work in Visual Studio 2017 I first create the proxies I want to use and build it into a dll. After that I create a console application and add the .dll as a reference (+ another .dll needed by the service). The service also needs to use an Application Configuration File and a non .NET .dll. These two files have to get copied to the build folder in order to run the application.
When I try recreating this in Unity I add the two .NET .dll files to the Assets folder and it seems to work since scripts autocomplete code from the .dlls. However in the Unity console I get a FileNotFoundException. I also have no idea how I would go about including the non .NET dll and the config file.
System.IO.FileNotFoundException: Could not load file or assembly 'DotNetToJavaProxies, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
File name: 'DotNetToJavaProxies, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
UnityEditor.EditorAssemblies:ProcessInitializeOnLoadAttributes()
I'm not that familiar with Unity so I'm asking, can I accomplish this? Using the config file and the .dll, and fixing the error.
JNBridgePro does not support Unity, so it is unlikely that this would work, although I have to say that we have never tried it. Starting with the new version 10, JNBridgePro does support .NET Framework and also .NET Core 3.0 (on Windows and Linux). Perhaps one of those scenarios would work for you. If you have additional questions, please contact JNBridge support.
Related
I try to be as detailed as possible in explaining our situation, premising that we made several attempts in relation to other similar situations found on stackoverflow. Specifically, we have a project consisting of many libraries in c# that has been updated from net 4.7 to asp.netcore 6.0. Within the project there is also a library of classes in c++. This library generates a dll that is used within one of the projects c#. The project in c++ has not been updated, but we simply went to vary the target framework from net 4.7 to netcore 6.0 (and also we changed clr to clr:netcore) as explained in the Microsost guide for porting hybrid projects in C# and C++. All the project builds correctly but when the debugging of the webapp in C# referencing the dll in C++ I get the following error:
System.BadImageFormatException: 'Could not load file or assembly 'Tradante.MT4.Wrapper, Version=1.0.8369.22669, Culture=neutral, PublicKeyToken=null'. Format of the executable (.exe) or library (.dll) is invalid.'
Navigating through various issues similar to our case, we seemed to understand that the incompatibility problem could be related to having a project at x64 and another at x86. We tried to vary all possible combinations but the error remains the same. But we noticed something strange: we forced the build to x64 of the webapp in C# but in the compilation output (which we see as enabled debugging of the native code) we find the name of the webapp followed by (Win32) as if the machine continues to build at x86. I don’t know if this information can help you.
I have a classic asp site that needs to consume a .NET assembly. I have written a dll library that is COM-visible and the project is using a reference to a Paypal-SDK library. I have been successfully able to create the dll and consume it in a classic asp web page on my Windows 10 development machine. When I copy the web application to a Windows 2012 running IIS 7.x I get the following error
nDataConsulting.PaypalStub error '80070002'
Could not load file or assembly 'PayPal, Version=1.8.0.0, Culture=neutral, ?>PublicKeyToken=5b4afc1ccaef40fb' or one of its dependencies. The system cannot >find the file specified.
The COM visible assembly is using the Paypal.dll SDK which I believe it cannot find on the Windows 2012 server. I have tried placing the dll in the application BIN folder, tried regsvr32 etc but I have not been able to make my dll find the dependent dll. Kindly help me resolve this issue as this is a major show stopper right now
There is a program called Dependency Walker which shows basic information about a DLL, such as its methods, and also lists the dependents DLLs.
It was answered here:
https://stackoverflow.com/a/7378982/8419161
If you find any related DLLs, you must include them along with the Paypal one.
I've ran into a weird problem.
I basically have my own web-stack for .NET-core which I've built into a few .dlls, and I want to reference these from another ASP CORE-solution.
VS seems to find the assemblies, where I can navigate types etc.
I can also build the project without any issues, but when IIS then runs the server I get an internal server error stating:
FileNotFoundException: Could not load file or assembly 'myDLL, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.
The referenced DLLs are in the debug-folder, and the really weird thing is that if I create a new ASP Core project in the same solution as the web-stack, I can reference and use it without any problems.
Why is this happening only when running on a project outside the web-stack's solution, and what can I do to make it runnable everywhere?
The .NET Core Tooling in VS 2017 (< 15.3 preview) / .NET CLI < 2.0 doesn't fully support referencing assemblies on disk. You need to package the library up as a NuGet package or use a project reference ("same solution"). The technical reason is that all the required assemblies and versions are resolved during compilation and written to the .deps.json file. When loading arbitrary assemblies, this might fail because either the assembly or its dependencies cannot be found (or a conflict with each other).
for load the external dll in core project, needed to:
vs 2017 with version 15.3 or upper.
Microsoft.Extensions.DependencyModel NuGet package installed in your project.
I'm trying to use ServiceStack REST DTO and OrmLite with monoDroid.
But I can't fugure out how to build ServiceStack to use it.
By default I have error while deploing to mobile device:
C:\Program Files (x86)\MSBuild\Novell\Novell.MonoDroid.Common.targets(464,2): error : Exception while loading assemblies: System.IO.FileNotFoundException: Could not load assembly 'System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Perhaps it doesn't exist in the Mono for Android profile?
The problem here was that you were trying to use a ServiceStack DLL compiled against the full .NET profile from your Mono for Android application, which is destined to fail. In this particular case, it was failing because that DLL had a dependency on System.Configuration, which is not included in the Mono for Android profile. In order to use a library with your application, you should compile its source against the Mono for Android profile, which will verify that the profile supports it, and allow you to safely reference it from your application.
When trying to compile a Mono for Android version of an existing library, the easiest place to start is with the Silverlight build for it (if there is one). Since the Base Class Library exposed by Silverlight is very similar to that of Mono for Android, the set of files/compilation symbols generally lines up between them as well. I have an old post up here that talks about how to link files in from other projects in order to properly compile a class library.
This is a weird one.
I created a new Windows Service in C#, and want to re-use some of the code we created before that's in a Class Library.
The project is loaded in the solution along with the service. Both target .NET Framework 4.0 (not client profile).
I tried adding a project reference, and it worked for a short while. After working on some old code that I was rewriting, when the project compiled again, it complained that it no longer recognised the namespace for the using statement.
I've made sure to clean the solution & rebuild, but no dice. Sometimes VS can have a bad day, so I restarted VS, but this also didn't work.
I then build the DLL, and add a reference to it via 'browse', also no dice. Then I tested it on another project, but after adding it, it works instantly, so it's not the DLL.
I then checked with other libraries in the solution, but I was able to add a reference to them in the service and access their namespace without a problem.
I'm out of ideas here, anyone got an idea of what to do here?
Thanks,
Nick.
Almoast forgot: the weird thing is, that if I open up the Class view, and expand the 'References' section, the namespace/dll doesn't show up there either... it's a real conundrom...
I should pay more attention to warnings:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9): warning MSB3253: The referenced assembly "" could not be resolved because it has a dependency on "System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which is not in the currently targeted framework ".NETFramework,Version=v4.0,Profile=Client". Please remove references to assemblies not in the targeted framework or consider retargeting your project.
So, I'm a ready idiot for checking the DLL's target framework but not the Windows Service :)
The problem is my DLL uses System.Web, which is not part of the .NET 4 Client Profile framework target. Changing the Service's Target Framework to 4.0 fixed it.
If the class view doesnt show the types that should be there, the actual dll you're compliling against is not the correct version.
There could be several reasons for this
A previous compilation of the dll might still be around
The project might reference another, older, binary version of the library rather than having a project reference
Another project mgiht be referencing an old version of the dll, and have copy local set to true. When that project is compiled it overwrites the new version of the library
Make sure all projects in the solution use project references, and remove all binaries you can find.