Recently I created a sample Xamarin cross platform application using Visual Studio 2017. The Android project under this solution runs and it is debugged without any error, but the Windows UWP project solution, previously needs to be build and deployed in order to debug it. There is an MSB3541 error when trying to deploy UWP project.
This is the detailed error:
Microsoft.Common.CurrentVersion.targets(4686,5): error MSB3541: Files has invalid value "obj\x86\Debug\DebtAppXamarin.UWP.c_.users.dafpc.documents.visual_studio_2017.Projects.DebtAppXamarin.DebtAppXamarin.DebtAppXamarin.Views.ItemDetailPage.xaml.g.cs". The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
The specified file ...ItemDetailPage.xaml.g.cs actually does not exist in the directory ...DebtAppXamarin.UWP\obj\x86\Debug\.
I have tried to clean and rebuild solution but the same problem is again.
Also I have created the same new project but the same error is present.
Is there any problem when naming project files in obj directory , or the error might be somewhere else?
I could not find a solution for my current project even by reinstalling Xamarin Forms or updating VS 2017. What I did is that I created a new cross platform project using Xamarin Forms , but this time I choose a different code sharing strategy like Portable Class Library (not a shared project), after setting up project template details the application was running smoothly, without any build errors or warnings.
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.
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've created a working iOS app with Visual Studio 2017 using Xamarin.Forms and a PCL. Now I'm trying to create the UWP app. I've followed the steps here, and when I build, I'm getting the error:
Cannot resolve Assembly or Metadata file 'Xamarin.iOS.dll'
It says it's happening in the MyProject.UWP project, in the MyProject.UWP.csproj file. But there's no reference to that file in MyProject.UWP.csproj (no reference to anything iOS), and there's no reference to that file in the entire UWP project either. So where is it trying to be referenced?
I did notice there's a file in MyProject.UWP\bin\ called project.assets.json. And while there are no references to 'Xamarin.iOS.dll', there are references to 'Xamarin.iOS10' - for example in the file list for the MR.Gestures package, I see listed a "lib/Xamarin.iOS10/MR.Gestures.dll" - not sure why there would be any iOS reference at all there, so that's a little suspicious...although it seems to reference all platforms, including windows phone and android, too, so maybe that's ok.
So I'm trying to automate the process for building a packaged app from a Unity project and I've hit a roadblock when trying to use MSBuild to build the final app packages.
In Unity, when you build for UWP, a folder /UWP/ is generated for the project. These contain csharp projects for two .dlls that are required to build the uwp app.
For me, these dlls got generated in a folder for each platform (x86,x64, and ARM), but this is where I hit the roadblock. To build the app packages I use MSBuild(I've also tried with the Developer Command Prompt - same result) with the command.
MSBuild "{Project}.csproj" /p:Configuration=Debug;AppxBundle=Always;AppxBundlePlatforms="x64";OutputPath="AppxPackages"
This throws the error
"C:\Users\{User}\Desktop\Output\{Project}\{Project}.csproj" (default target) (1) ->
(BeforeResolveReferences target) ->
C:\Users\{User}\Desktop\Output\{Project}\{Project}.csproj(319,5): error MSB3030: Could not copy the file "{path-to-unity-project}\UWP\Assembly-CSharp\bin\AnyCPU\Debug\Unprocessed\Assembly-CSharp.dll" because it was not found.
What is happening here is that MSBuild is attempting to find a dll in a folder "AnyCPU" that simply does not exist.
Is there any way I could tell MSBuild to individually build each platform rather than look for a combined dll, or am I using MSBuild incorrectly?
Even though I was unable to figure out why the Debug configuration looks for an assembly in the wrong directory, thanks to #Leo-MSFT I was able to fix the error that was occurring.
Firstly, I was calling MSBuild on the game project, this needed to be the generated solution instead.
Secondly, instead of using the Debug configuration, I used the Release configuration.
And finally, I was confused by the contents generated by the build compared to a build from Visual Studio (Right Click->Store->Create App Packages...). While VS generates an .appxbundle, using MSBuild will generate individually for each of the platforms selected such as game_x64.appx, game_ARM.appx, and a few more.
You can create the bundle yourself by using the makeappx tool.
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.