I want to build my Unity-AR Apps to run on HoloLens 2. We use gRPC for interprocess communication of the HoloLens device and a desktop PC to pass information.
HoloLens 2 has an ARM processor architecture, for which gRPC does not provide a grpc_csharp_ext.dll.
Does anyone already had the same problem and how did you solve it?
*Edit: I use Unity for app development, so I'm limited to .NET Framework & .NET Standard solutions
This is a merged copy/paste from my comments in the grpc issue tracker here and here
Edit: I published a Unity project with precompiled libraries for x86, x64 and arm64 on Github.
My workaround for this problem involves compiling a Grpc.Core.dll without the Mono and DllImportsFromStaticLib which is used for WSA builds AND an ARM64 version of the grpc_charp_ext.dll which isn't part of the official Unity package but necessary for HoloLens 2.
Download a daily build unity package (e.g. this one) and unzip it. This is version 1.25-dev. I have tried more recent 1.26-dev daily builds but unfortunately grpc_charp_ext.dll is not correctly loaded in the HoloLens emulator for these builds. I also tried the most recent version (1.29.1) vcpkg has to offer but unfortunately there is a Protobuf/System.Memory version conflict (#22251) which hasnt been resolved yet, afaik.
clone grpc and checkout the daily build commit:
git checkout 8853754e8caa0b2ffb3ab0e25514f3f7612ebf7a if you use the build above
init submodules: git submodule update --init
If you are like me and don't want to install outdated build tools you can change the used Visual Studio version in tools\run_tests\helper_scripts\pre_build_csharp.bat. I used "Visual Studio 15 2017" instead of "Visual Studio 14 2015".
build grpc_charp_ext:
python tools/run_tests/run_tests.py -l csharp -c opt --build_only
If everything works well, you will end up with some Microsoft.Build.Tasks.Git.targets exceptions when the Python script attempts to build the C# project. It's probably related to some outdated SourceLink dependency or something. Nevertheless, the project will build just fine with Visual Studio 2019.
Apply grpc-no-static.patch.txt
Open Grpc.sln and compile a Release build
Copy the resulting Grpc.Core.dll into Plugins/Grcp.Core/lib/net45_wsa of the downloaded package
If you followed these steps, you should have something that works with Unity and HoloLens 1, now the part that makes it work with HoloLens2.
Clone vcpkg and checkout the tag 2020.01. I don't know whether checking out 2020.01 is actually necessary but it contains the grpc version closest to 1.25
git clone https://github.com/microsoft/vcpkg.git
git checkout 2020.01
You have to edit the grpc port to build the correct version. Download 00001-fix-uwp.patch.txt, 00002-static-linking-in-linux.patch.txt and portfile.cmake.txt, remove the .txt ending and override the files located at ports\grpc.
Copy the Plugins folder into your Unity project
Make sure that Grpc.Core.dll in the folder net45_wsa is only used for WSA builds and the original build EXCLUDES Grpc.Core.dll in net45_wsa:
Make sure that grpc_charp_ext in Grpc.Core/runtimes/win/x86 and x64 is exported correctly (correct arch) for WSA:
Next you have to backport a triplet configuration: Download arm64-windows-static.cmake.txt, rename it and put it into triplets\community
Now bootstrap vcpkg and build protobuf:x86-windows and grpc with the arm64-windows-static triplet
.\vcpkg.exe install protobuf:x86-windows
.\vcpkg.exe install grpc --triplet arm64-windows-static
Copy the generated file buildtrees\grpc\arm64-windows-static-rel\grpc_csharp_ext.dll into your Plugin folder (Grpc.Core\runtimes\win\arm64) and set the target for this DLL:
Export and build your project
Related
I have C# application (.NET Framework 4.6.2) with WebApi projects which references System.Runtime.InteropServices.RuntimeInformation (v4.3.0) library through nuget package. See
Nuget package reference screen Package was auto-installed as a dependency of 'Microsoft.CodeAnalysis.Razor.2.2.0, Microsoft.DotNet.PlatformAbstractions.2.1.0'
This application was working fine (Builds from my localhost are ok) until I tried to do automatic builds from my teamcity server (different machine). For some reason builds of my app which are provided by teamcity will not start. I get error Could not load file or assembly 'System.Runtime.InteropServices.RuntimeInformation, Version=4.0.2.0...'
So I started to investigate and I found out this:
Builds from my localhost (bin/debug) contains lib System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.26011.1, Date modified=10.8.2021) --this build works fine
Teamcity build contains lib System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.24705.1, Date modified=11.5.2016) --this build is not working
Nuget package which was downloaded (..\packages\System.Runtime.InteropServices.RuntimeInformation.4.3.0) on both machines (localhost and teamcity server) contains System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.24705.1, Date modified=11.5.2016)
And now I am stuck and literally dont know how to investigate it further. Questions I am asking myself:
How is it possible that my localhost builds contains this reference lib with file version 4.6.26011.1 when in my \packages\ folder this .dll contains file version 4.6.24705.1? Does msbuild maybe take this reference from different location? But from where? I swear I searched my computer and I did not found this library in version 4.6.26011.1 (which is apparently copied to bin/debug by msbuild).
Is there a way to monitor msbuild process and see from where it copies this .dll reference to my bin/debug/ folder on my localhost machine?
How to fix my references so the app runs fine?
21.6.2022 Edit:
Thanks to #mu88 comment I have managed to find out that this library is copied from this location: "C:\Program Files\JetBrains\JetBrains Rider 2021.2.2\tools\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net462\lib\System.Runtime.InteropServices.RuntimeInformation.dll" to my bin\debug. I have zero ideas why msbuild is using this path for this lib. (This is only library which is copied from this path)
--Additional info: I am using some AspNetCore references (e.g Kestrel, ..) so I am targeting .Net Standard 2.0. Could this relate? I am asking because my investigation lead to this issue: ms-build-extensions-file-corrupt-my-bin-web-api-folder. In this issue I have found other links to people having similiar problems like this. I just dont understand the solution there :(
So I managed to solve my problem. I had to install .NET SDK to Visual Studio Build Tools 2019 via Visual Studio Installer. Which done "some" magic and it created *MSBuild\Microsoft\Microsoft.NET.Build.Extensions* folder to my msbuild and now during the build process some System libraries are "overidden" and copied from this new location.
So even if I use nuget to download System lib then this package is not used during the build.
I did not manage to find any more info about the build process :( It would be nice if someone could explain this to me. I created a separate question for this here: What is Microsoft.NET.Build.Extensions and how does it work?.
I'm trying to install MonoGame for mac and VS code. I followed the instructions at https://docs.monogame.net/articles/getting_started/1_setting_up_your_development_environment_macos.html, but I am stuck at one place. I have the monogame editor .mpack file, but can't upload it to VS code for some reason. I did extensive research but can't find any answers. What should I do?
The "normal" Mac install instructions and files are only for use with Visual Studio.
Install using CLI
Please note these instructions are designed for Intel Macs(x64), but should work on Apple Silicon devices(ARM) with .Net6.
You can roughly follow the Linux install instructions.
Install Dot Net Core 3.1 for the Mac. or .Net6
Install VS Code.
You may need to reference this question on Terminal paths for code. Something similar may need to be done below for the dotnet command.
a. Install the C# extensions: code --install-extension ms-dotnettools.csharp
(Optional) Install Mono. Required for some consoles and Android targets(Frameworks 4.5 and 4.7). See here for compatability.
Open a terminal window. Run the following line, either the OS or from VS Code:
dotnet new --install MonoGame.Templates.CSharp
The next two lines may be Linux specific so ignore any uncorrectable errors.
dotnet tool install --global dotnet-mgcb-editor
mgcb-editor --register
At this point, you should be able to create a new CLI project folder from the templates:
cd /path/togame/parent
dotnet new mgdesktopgl -o MyGame
Open the folder in VS Code.
Review the projectname.csproj file:
Note the TargetFramework line:
<TargetFramework>netcoreapp3.1</TargetFramework> or
<TargetFramework>net6.0</TargetFramework>
Some targets require a different TargetFramework, like net47 or net45 as provided by Mono.
See Microsoft's .Net versioning page for more information.
A couple of additional helpful CLI commands to run from the folder with the .proj file; Taken from this list:
dotnet restore Update all NuGet Packages
dotnet clean Remove all output files
dotnet build compile
dotnet run execute the program
I'm a fullstack developer and I had the setup where my main development machine was an Intel MacBook for frontend iOS/Android app development, with Windows 10 running in a Parallels VM, with Visual Studio installed for my .NET (Standard) backend. Everything was running fine with this setup.
I've just moved to an M1 MacBook and since I couldn't use Windows 10 x64 anymore, I've setup Windows 11 ARM version, and installed Visual Studio 2022 in it. Visual Studio works perfectly under x64 emulation, but some code in my C# projects have Entity Framework dependencies for custom SQL Server types (spatial types), which have x86/x64 DLLs available (the package was last updated on 2018 and I couldn't find any ARM64 versions). Even though x64 emulation works great when running apps like Visual Studio itself, for some reason I'm getting the following error when I'm building a project which depend on SQL Server Types:
Error Could not copy the file "C:\Users\can\source\repos\MyProjectNameRedacted\SqlServerTypes\x86\SqlServerSpatial140.dll" because it was not found.
Error Could not copy the file "C:\Users\can\source\repos\MyProjectNameRedacted\SqlServerTypes\x64\SqlServerSpatial140.dll" because it was not found.
Error Could not copy the file "C:\Users\can\source\repos\MyProjectNameRedacted\SqlServerTypes\x86\msvcr120.dll" because it was not found.
Error Could not copy the file "C:\Users\can\source\repos\MyProjectNameRedacted\SqlServerTypes\x64\msvcr120.dll" because it was not found.
How can I solve this?
The problem was simpler and more obvious than anything to do with ARM64 or emulation.
I've cloned my repo from Git, and my .gitignore simply was ignoring DLL files as all the DLLs except these particular files were just build outputs. When I cloned the repo, DLLs were simply not there, and build was expecting those DLLs, resulting in error. I've reinstalled the package using NuGet using the following command and the problem was solved:
Install-Package Microsoft.SqlServer.Types -Version 14.0.1016.290 -project Models
is there any way to install MSBuild 15 on my machine locally without admin rights?
Microsoft's instsaller on https://www.visualstudio.com/downloads/ seems to inevitably ask for admin rights. I've tried looking into the .exe directly with 7zip, but don't think there's much I could manually extract either (looks like the exe is just a web downloader).
Would there by any other way anyone can think of?
--
Why do I need this? I'm developing on a non-admin machine. I could install the NetCore SDK and VSCode withou admin rights, which is great.
For one of my C# projects I'll need MSBuild to compile though (as I'm trying to use WPF/XAML), specifically MSBuild 15 due to the format of my .csproj files.
In case anyone else is trying the same, I managed to do it;
started with Nuget package Microsoft.Build.Runtime, extracted its contents + downloaded all dependent packages into the same folder, plus a few more (several Nuget Build related ones, also available on Nuget).
Had to fiddle a bit with dependencies, environment variables (so my non-admin install of the Net Core SDK would be found) + including build tasks manually etc., but works now. In the end, I was able to use VSCode to compile a WPF application targeting .Net 4.6.1 that references a few other NetStandard 2.0 projects.
My end goal is to create a cross-platform (non-web) console application, so I'm exploring .NET Core right now.
In my previous .NET projects, I did all the development inside Visual Studio, but I also created a batch/MSBuild file so I could build the whole project (including setups, NuGet packages, zip files with binaries etc.) with one single click. Here's an example from a previous project.
In the end, I want to do something similar with my .NET Core test project.
But right now I'm failing at the first step: I'm unable to build it outside Visual Studio, so that the result works on another Windows machine without .NET Core installed.
(in the first step, I'm ignoring the cross-platform part - I'll be happy to get it to work on Windows)
What I have
I managed to get it to work inside Visual Studio 2015 Community Edition as follows:
create new project in Visual Studio: "New Project" ⇒ "Web" ⇒ "Console Application (Package)"
create new publish profile inside Visual Studio ("Build" ⇒ "Publish" in the menu).
This will create a PowerShell script (and an XML file with settings)
Here's my test project on GitHub.
When I do "Build" ⇒ "Publish" in the menu again, Visual Studio apparently executes the previously created PowerShell script again.
The result is slightly over 90 MB, consists of 825 files in 598 folders, and looks like this:
When I copy it on another machine (Win 7 / .NET 4 installed / .NET Core not installed), it works.
What I tried to get the same result outside Visual Studio
1. dotnet publish
This answer and this answer sound like I can use dnu publish to achieve the same result via the command line.
I understand that parts of .NET Core are still moving targets right now, so apparently dnu is now dotnet instead.
So I tried to execute dotnet publish (and created a batch file) for it:
dotnet publish "%~dp0\src\CoreTestVisualStudio" -c Release -r win7-x64 -o "%~dp0\release\cli"
The result consists of an .exe file and a bunch of DLLs, only 25 files and 1.5 MB, all in one single folder:
Obviously the .NET Core runtime is missing here, and as expected, this app crashes when I try to execute it on a machine without .NET Core installed (the same one as mentioned above).
2. The PowerShell script from the publish profile
I tried to execute the PowerShell script (which was created when I created the publish profile) outside Visual Studio, but it failed because the script expects some parameters and I don't know what to pass:
param($publishProperties, $packOutput, $nugetUrl)
There's also this line in the script:
# to learn more about this file visit http://go.microsoft.com/fwlink/?LinkId=524327
...but the link just points to the landing page of the .NET Web Development and Tools Blog.
TL;DR
What am I doing wrong?
I know that the first release of .NET Core mainly focuses on ASP.NET, but as I understood it, ASP.NET Core apps are just console apps as well, so I thought a basic console app would work now.
On the other hand, most of the console app "getting started" docs are still missing, so maybe it's just too early and dotnet publish for console apps is not finished yet?
Edit after a few days: I'm suspecting that I'm doing nothing wrong and that it's an issue in the.NET Core command line tools, so I posted it to the command line tools' issue tracker.
Problem solved!
I posted it on the issue tracker of the .NET Core command line tools, and it turned out that it was a bug in dotnet publish - it didn't bundle the C++ runtime, which is needed to execute the compiled app on a machine without .NET Core installed.
The temporary solution was to install the C++ runtime.
The "real" solution was made in a pull request three days ago, which is included in the latest installer now.
With this version, dotnet publish does bundle the C++ runtime, so the result will work on a machine without .NET Core.
For dnu:
There's an option for dnu publish called --runtime that specifies the runtime to include when publishing. You would use the full runtime name with the command, e.g.:
dnu publish --runtime dnx-clr-win-x86.1.0.0-rc1
For dotnet:
You don't need to specify the runtime or framework versions -- by default, dotnet publish will use the framework from project.json and the current runtime flavor. However, the documentation states that:
dotnet-publish command also requires certain dependencies in the project.json to work. Namely the Microsoft.NETCore.Runtime package must be referenced as a dependency in order for the command to copy the runtime files as well as the application's files to the published location.