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
Related
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
I have created REST API framework in visual studio 2017 C#.
I have created Just created one single test method using MSTest Framework and which is listed in Test Explorer But when I run it, it is giving me output details as below-
Visual Studio 2017 Enterprise: No test is available. Make sure that test discoverer & executors are registered and platform & framework version settings are appropriate and try again.
Test Class-
I tried to Change Platform from 64 to x86 i.e. 32 bit for Project and vice versa
Tried to change default processor architecture form Test setting to X86
From Application Pool setting in ISS , tried with setting 32 bit
Tried to install ASP.Net.Core. 2.0.0 , 2.1.0, 2.2.0, no luck
Sometime giving compatibility issue for this DLL
Microsoft.VisualStudio.QualityTools.UnitTestFramework
Try to update after removing above DLL and install
Microsoft.VisualStudio.QualityTools.UnitTestFramework.Updated , but not able to install it
Got error as below while installing Nuget -
Error NU1202 Package VS.QualityTools.UnitTestFramework 15.0.27323.2 is not compatible with netcoreapp2.0 (.NETCoreApp,Version=v2.0). Package VS.QualityTools.UnitTestFramework 15.0.27323.2 supports: microsoftvisualstudioqualitytoolsunittestframeworkdll (Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll,Version=v0.0) REST.API.Automation.Framework
Tried in debug mode
Tried with adding NunitTest, NunitTestAdapter3 even if i am using MSTest Framework
Looks like there might be SDK ASP.Net.Core2 compatibility issue or
TestSetting file is not supported
References folder is not displayed after adding references, everything is going under Assembly folder
Try build the project in release mode and then again build the project in Debug mode.
Run the Test suite....Hope it will work
I am working on a project on TFS. This project was created on someone else's PC on VS 2017 and the newest .NET framework and published to Azure.
I got the project on my PC, I have VS 2015 and I had to change the .NET framework of the project to 4.6. Everything was fine, I could make changes to the project and commit.
But when I tried to publish to Azure from my PC, I got a very unclear error:
Publish Failed
Connecting to ...
Looking for solutions online, I had to downgrade the version of the package Microsoft.Net.Compilers from 2.6.1 to 2.4.0 . And that worked !
I turned off my PC. Next day when I opened the project and ran it, I got this error locally :
Could not load file or assembly 'Microsoft.ApplicationInsights, Version=2.6.1, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
I tried to uninstall Microsoft.ApplicationInsights and reinstall it with version 2.6.1 , but it says i need a newer version of nuget.
I am not sure how to proceed from here. I already installed all the updates in my Tools -> Extensions -> Updates but nothing changed.
Why are all these things happening to my project and how can i fix it?
PS: upgrading my VS to 2017 is currently not an option due to many exterior reasons.
Thank you.
I've gotten that error locally as well and was actually able to resolve by manually adding the file to my project folder, may be worth a shot.
Downgrading .NET Framework causing packages issues
Just like Hans said nuget packages change quite rapidly, which often require the latest version NuGet. Some new features in the package only supported by the newer NuGet (like PackageReference) or some issues fixed on the newer version. For example, install package Microsoft.EntityFrameworkCore.SqlServer 2.1.1 on Visual Studio 2015, which requires NuGet client version '3.6.0' or above.
So, the workaround for this issue is create a new project with Visual Studio 2015, copy the code from previous projects, then add those nuget package one by one to find out the reason why it needs the newer version nuget.
However, I want to talk more over about this question is that the best way to resolve this issue is to install Visual Studio 2017 alongside Visual Studio 2015. As we known, using a lower version of the Visual Studio and .net framework to open a higher version of the Visual Studio and .net framework is not recommended, it will always bring a lot of incompatibility errors and some other weird issues. Since upgrade your Visual Studio to 2017 is currently not an option due to many exterior reasons, so I suggest that you can install Visual Studio 2017 alongside Visual Studio 2015. Besides, developing the same project with different versions of Visual Studio and submitting it to the TFS server may bring many unpredictable risks.
Hope this helps.
I have a solution with projects pointing to .Net Framework 4.5 which I have opened in Visual Studio 2017 and tried to Unit Test Project pointing to .Net Framework 4.5. I am getting the following error
Package Installation error .
Could not add all required packages to the project. The following packages failed to install from 'C:\Program Files(x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\502SXCIF.E5I\Packages':
MSTest.TestFramework.1.1.11: Failed to add reference to 'Microsoft.VisualStudio.TestPlatform.TestFramework'
I have tried changing the Platform to x86 as suggested on some online resources.
I am using a Windows 7 Enterprise 64 bit. Has anyone been able to resolve this.
MsUnit test related template got missed in your local system.if you have another version please try to copy respective folder it will resolve the issue.
I have installed TeamCity Professional 8.1.3 (build 30101) onto a clean box and I am trying to run a new build. I have copied over the msbuild tools from my local dev machine to the new server and placed them in the x86 folder. I have also installed the IIS web role, .net feature, registered IIS from the cmd line, and installed MSBUILD tools 2013. For some reason, I still am unable to compile anything. I get the following error
SGEN An attempt was made to load an assembly with an incorrect format:
C:\Windows\Microsoft.Net\assembly\GAC_64\System.Data\v4.0_4.0.0.0__b77a5c561934e089\System.Data.dll.
Is anyone familiar with this error? I am trying to build an app in .NET v4 using msbuild tools v4.
I was getting this error building a project that targeted .NET Framework 4.5.1. I resolved the issue by installing Microsoft .NET Framework 4.5.1 Developer Pack
You can get the SDK (aka Targeting Pack, aks Developer Pack) for other versions you may want to target at .NET SDKs and Downloads
The solution was installing VS2012 on my build machine. This may not be the most efficient, but it beats installing small packages and chasing around things that need to be registers in the GAC.