I am developing a Windows Store Application. I am trying to reference a library that has this dependency structure:
unmanaged.dll
managedWrapper.dll (depends on unmanaged.dll)
From my Windows Store App project, I can only reference the managed assembly managedWrapper.dll. I get an error if I try to reference unmanaged.dll, something akin to "unable to add reference".
My project compiles fine, however at runtime I get a file not found exception because managedWrapper.dll cannot find unmanaged.dll. I kind of expected this behavior but don't know how to fix it. The problem is I am trying to debug my application, but I have no idea how Visual Studio 2012 deploys it. I can only explicitly reference managedWrapper.dll in my project, so there is no way to tell Visual Studio that unmanaged.dll is also a dependency for my application. Since I have no idea how Visual Studio deploys my Windows Store Application when debugging, I don't know where to manually copy unmanaged.dll to get around the problem.
Also there doesn't seem to be a way to get the actual working directory of my App while debugging, so again I don't know where to copy unmanaged.dll to so managedWrapper.dll won't fail at runtime.
Has anyone encountered this problem before?
Add unmanaged.dll as a file to your Windows Store Application. Make sure you set the build properties for unmanaged.dll to Content, and set it to Copy to Output.
This should copy the dll to the output directory.
The above should work, but may not be ideal in the case where you have multiple projects that reference managed.dll. For example, if you also have a unit test project that references managed.dll, you will have to do the above and add unmanaged.dll to it as well.
Related
I'm a bit of a noob on that topic so I'm searching for help. I need to install this library (https://github.com/twcclegg/libphonenumber-csharp) for a unity project where I need to check phone numbers.
But as I always made simple games in unity I really don't know how to do that and I don't really know either what to search to find an answer.
If anyone of you knows how to do it, it will really make my day.
Thank you
Once do a build on a project you want to use in Unity, then find the DLL output from the build. I recommend you do Release Builds, but for now if you are not familiar with Visual Studio just use what you were able to build. If there are multiple directories then you only need one - the best one to use would be any labelled ".NET Standard" which it seems you have a .net standard 2.0 directory.
Go to your Unity project in the Assets folder, and if there isn't already a Plugins folder create one. Then in Assets/Plugins create a folder named whatever you want for the library - in this case PhoneNumber would be fine. So you would have Assets/Plugins/PhoneNumber and you would copy/paste the contents of your NetStandard2 folder there.
In the end you should have Assets/Plugins/PhoneNumber/PhoneNumber.dll
As soon as you have that dll, you can switch back to Unity and see if it worked by checking the Unity Console for any Errors. You might receive errors saying it could not load the DLL. Almost always if it can not load the DLL it is because of missing dependent DLLs - which is why I said to copy the entire folder contents inside the "NetStandard2" folder since it may contain more than just PhoneNumber.dll - it may have it's necessary dependent dlls also.
If not, you can read the error output and hopefully get a clue as to what dependent dlls are missing. You can also expand the Dependencies in Visual Studio.
Typically the DLL failing to be loaded in Unity is because of missing dependent DLLs. Expanding the Dependencies, which is found under the project name in the Solution Explorer window on the right side of Visual Studio, will show you what libraries it requires. Most of what you see under dependencies (if not all) will require a similarly named dll. Under the netstandard2.0 dependency I see System.Collections.Immutable - so you may need a System.Collections.Immutable.dll which should (usually) be in the output folder when you build the project. You would also need that dll in Unity in your PhoneNumber folder along with PhoneNumber.dll
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.
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.
I am using Visual Studio Professional 2010 and the Team Foundation Server Express (beta). My VS Project (C#.Net / WPF) has been migrated from VS 2008 (without TFS) to VS 2010 (with TFS).
Whenever I apply changes to my code and try to debug my application, I get messages like This breakpoint will not be hit. (in german: Der Haltepunkt wird momentan nicht erreicht. Der Quellcode weist Unterschiede zur Originalversion auf.) and the project is started using the old executable version (the one with the last successful build). No errors occure, the code is OK, but the changes are not applied either.
When I manually cleanup and rebuild my project, everything works quite fine - but there has to be a fix for this issue?
Edit: I just added a new project to my VS solution and checked it in on the TFS Server. Using this new project the problem does not occure. Even when I add the same dependencies I used in the project mentioned above, the debugging and building of the new project works fine without the errors mentioned above.
Maybe this information helps you to lead me to a solution.
It's not clear whether existing answers are not sufficient. I can't know exactly what's causing your problem; but, I can detail some places this potentially comes up.
The first area that I commonly see this is when a project references an assembly directly. You can create a project that creates an assembly. Another project might use that assembly and you can reference by assembly directly (and not add a reference to the "project"). This disconnects VS from really knowing it needs to "build" that referenced assembly first and it will sometimes get out of sync with the debugging symbols (PDB). You can tell if a project has been referenced or an assembly has been referenced in the properties of the reference (expand References in Solution Explorer, right-click a reference, and select Properties). A referenced project will not have a Specific Version property, while an assembly reference will. You can sometimes also tell from Project\Project Dependencies. If you have a reference to an assembly generated by another project but that project isn't a dependency in Project Dependencies, it might be an assembly reference. To fix this, you can usually just delete the reference and add a reference to the project.
I've also find that sometimes breakpoints confuses the debugger. If I have many breakpoints or they've been kicking around a long time, the debugger sometimes does some weird things. If I delete all the existing break points (Debug/Delete all breakpoints) and re-apply them the debugger is usually much happier.
You can find the answer here. The assemblies might be in GAC or a project or some projects need to be rebuild to generate the pdb files again, which are used for debugging. If you don't choose to rebuild it might use the old pdb files.
My guess is that you are putting breaking points somewhere your program can't access them.
Ex:
const int x = 5;
if(this.x == 1)
//do sth <--- breakpoint here
If you are running a mixed mode application (unmanaged native C++ & managed C#), make sure to set Enable unmanaged code debugging in your C# application's Properties window.
You have to rebuild, there isn't an easier way around it.
The program database files (PDB) need to be recreated. You should also have your configuration setting set to debug.
Also the first answer to this question must be of help as well.
This happened to me when I started VS as an admin, and it also happened to me when the project is set to a different architecture than a DLL that I used in this project.
This question to which I already found the answer is posted here in case of someone else encounters it. I decided to post the Q&A here so that SO has something about this error, since I don't know if it's been here before.
This occured after an update of the .NET Framework. Before the update, everything compiled just fine! After the update, I could compile nothing!
The error message is:
Error 1 - Could not find file 'Microsoft.Windows.CommonLanguageRuntime, Version=2.0.50727.0'.
This is a problem within Visual Studio 2005. This occurs after an update of the .NET Framework 2.0 and is due to project reference within a single solution.
For example, when you're writing a test library which will test your assembly within the same solution, you will most likely reference the project. Then, this error may occur.
To solve this error, simply reference the file binary of your project, either the DLL or the EXE within which resides the code you want to test. This is called a file reference.
Let's suppose we have two projects called:
Company.Project.ApplicationName;
Company.Project.ApplicationName.Tests.
When adding the reference to our Company.Project.ApplicationName project within our Company.Project.Application.Tests project, we can either use the Browse or the Project tab. When using the Project tab, you create a project reference. We don't want to use this if this error occurs. What we want to use is Browse, so that we can make a file reference.
Here's a link to the Microsoft Support Website that explains this issue.
You may receive a "Could not find file 'Microsoft.Windows.CommonLanguageRuntime" error message when you build a solution of a Visual Basic 2005 Windows Application project in Visual Studio 2005