Using Xamarin Forms with.NET Standard – VS 2017 Edition I have about using.NET Standard with Xamarin Forms. Since then, the tooling has changed significantly with Visual Studio 2017 and Visual Studio for Mac. This post will show you what you need to use Xamarin.Forms with a.NET Standard class library. Why use a.NET Standard class library instead of a PCL? There are many good reasons, but the two biggest ones are:. Much bigger surface area. PCL’s were the least common denominator intersection of supported platforms.
Visual Studio 2017 for Mac version 7.7.2.21. Released December 17, 2018. This releases addresses the following issues: We updated the version of NuGet to 4.8. We fixed an issue where launching Visual Studio for Mac without any Java installed shows 2 system prompts to install Java.
The end result is that while the binary worked on many platforms, there were a much more limited set of APIs available.NET Standard 1.4 is the version that supports UWP, Xamarin Android, Xamarin iOS, and Xamarin.Mac. “SDK Style” project file goodness.
Legacy PCL’s use the old csproj format which have tons of gunk in them. While it is possible to use the new project style to generate legacy PCLs (if you use my package), it’s time to move past those. If you target.NET Standard 1.0-1.2, some PCL profiles can install your library. See the for the list. Prerequisites Using.NET Standard requires you to use PackageReference to eliminate the pain of “lots of packages” as well as properly handle transitive dependencies. While you may be able to use.NET Standard without PackageReference, I wouldn’t recommend it. You’ll need to use one of the following tools:.
Getting Started As of now, the project templates for creating a new Xamarin Forms project start with an older-style packages.config template, so whether you create a new project or have an existing project, the steps will be pretty much the same. Step 1: Convert your projects to use PackageReference. The NuGet blog has on using PackageReference with all project types. Unfortunately there’s no current migration tool, so it’s probably easiest to uninstall your existing packages, make sure the packages.config file is gone and then install the package after setting the VS Options to PackageReference. You can also do it by hand (which is what I did for my projects). Step 2: As part of this, you can remove dependencies from your “head” projects that are referenced by your other projects you reference.
This should simplify things dramatically for most projects. In the future, when you want to update to the next Xamarin Forms version, you can update it in one place, not 3-4 places. It also means, you only need the main Xamarin.Forms package, not each of the packages it pulls in., you’ll need to add the PackageReference property near the top of your iOS and Android csproj files.
That tells NuGet restore to use the PackageReference mode even if you don’t have any direct packages (this is important for transitive restore). If you have any PackageReference elements in your iOS or Android csproj, then you don’t need this. For UWP, you already should have a PackageReference to the UWP meta-package ( Microsoft.NETCore.UniversalWindowsPlatform version 5.3.2). If you hit any issues with binaries not showing up in your bin directories (for your Android and iOS “head” projects), make sure that you have set CopyNuGetImplementations to true in your csproj. At this point, your project should be compiling and working, but not yet using netstandard1.x anywhere. Step 3: Move your PCL library to.NET Standard.
This is the hard part today as there’s no tooling to automatically do this correctly. Be warned and DO NOT use this option in the PCL properties. It is broken and will create a project.json based library targeting dotnet.
I hope this option is removed in a future VS Update! Instead, go to File - New Project -.NET Standard - Class Library and create a new class library. If this is a new project, I’d simply delete the existing PCL and just use a new one. If it’s an existing project, you’ll want to migrate. The new format is far simpler and moving the PCL by hand is usually pretty easy. What I’ve usually done is this:. Close the solution in VS.
Take the existing csproj and make a copy of it somewhere else. I’ll keep this other copy open in Notepad. Copy/paste the contents of the new project you created and replace the contents of your existing project. Most of what you had in the old project isn’t really needed anymore. What you’ll likely need are settings like any signing or assembly names that don’t match the folder name/conventions.
If you have ResX files with design-time generated code, you’ll need to add the. Likewise, for Xamarin Forms pages, you’ll need. Decide which.NET Standard version to target, probably 1.4, based on the. Here’s a cheat sheet:. If you only want to support iOS and Android, you can use.NET Standard 1.6. In practicality though, most features are currently available at.NET Standard 1.3 and up. If you want to support iOS, Android and UWP, then NET Standard 1.4 is the highest you can use.
If you want to support Windows Phone App 8.1 and Windows 8.1, then NET Standard 1.2 is your target. If you’re still supporting Windows 8,.NET Standard 1.1 is for you. Finally, if you need to support Windows Phone 8 Silverlight, then.NET Standard 1.0 is your only option. Once you determine the netstandard version you want, in your csproj, set the TargetFramework to it — netstandard1.4, etc. Netstandard1.4 portable-net45+win8+wpa81+wp8 full Note the addition of the PackageTargetFallback property. This is required to tell NuGet that specified TFM is compatible here because the Xamarin.Forms package has not yet been updated to use netstandard directly.
Also note that DebugType set to full is required for the Xamarin tool-chain currently as they don’t yet support the new portable PDBs that are created by default. At this point, when you reload the project, it should restore the packages and build correctly. You may need to do a full clean/rebuild. Seeing it in action I created a showing this all working over on GitHub. It’s a good idea to clone, build and run it to ensure your environment and tooling is up-to-date. If you get stuck converting your own projects, I’d recommend referring back to that repo to find the difference.
![Visual Studio For Mac Does Not Recognize Solution Type Visual Studio For Mac Does Not Recognize Solution Type](/uploads/1/2/5/4/125428576/983685448.gif)
![Visual studio for mac does not recognize solution types Visual studio for mac does not recognize solution types](/uploads/1/2/5/4/125428576/891268290.gif)
Building on command line You will need to use MSBuild.exe to build this, either on Windows with a VS 2017 command prompt or a Mac with Visual Studio for Mac. You cannot use dotnet build for these projects types. Dotnet build only supports.NET Standard,.NET Core and.NET Framework project types. It is not able to build the Xamarin projects and the custom tasks in Xamarin Forms have not yet been updated to support.NET Core. To build, you’ll need two steps:. msbuild /t:restore MySolution.sln. msbuild /t:build /p:Configuration=Release MySolution.sln You can also restore/build the.csproj files individually if you’d prefer.
As always, feel free to tweet me as well. Hi Oren, Thanks for the article. I completed the first part (using PackageReference) and the code is compiling fine.
When I try to run the app I get a deploy error “Ensure that this project has Microsoft.Bcl.Build installed and packages.config is located next to the project file” on the PCL of my mobile app. I added a reference to Microsoft.Bcl and Microsoft.Bcl.Build in Nuget but am still getting the error. Strangely it worked the first time after adding these 2 references but is now failing every time I wanted to test it before moving to.NET standard to make sure that the code is still working Will changing to.NET standard get rid of this problem?
I’m doing all again to keep notes and screenshots about those nuances. Here is my list: 1. For the UWP project I had to manually remove the project.json but only after unloading the project, otherwise the NuGet manager is unable to add packages again (An error occurred while reading file project.json) and then also the project.lock.json. After that I was able to reload the project and add the Microsoft.NETCore.UniversalWindowsPlatform package. In your UWP csproj I can’t found the CopyNuGetImplementations and RestoreProjectStyle lines.
These are no needed for UWP projects? I wasn’t be able to simply add a new.NET Standard library and add the Xamarin.Forms package, but I’ve succeded on modifying the PCL lib to.NET Standard manually changing the csproj file with your posted code.
Do you guys have a version of CMake that works with Visual Studio 15 Preview 5. I tried the 3.7.0-rc1 from the CMake site but I get the error — The C compiler identification is unknown — The CXX compiler identification is unknown When I run cmake -G “Visual Studio 15 Win64” I suspect this is because they have “experimental” support for Preview 4 and I think you have moved stuff around in the install tree for Preview 5.
I know you have a CMake branch on GitHub and was wondering if I should try that? CMake 3.7 already has support for VS’15’ generator but there are things that are still changing in VS setup and that makes it a moving target. For now, VS has a separate fork of CMake 3.6 that has both a generator for VS’15’ projects as well as the CMake-server changes needed for the IDE integration. If you want to try it from the command line, you’ll need to make sure you run it directly from the folder it is installed in though (because it uses relative paths to find where VS and compilers are installed). The folder in Preview 5 is C: Program Files (x86) Microsoft Visual Studio VS15Preview Common7 IDE CommonExtensions Microsoft CMake CMake bin cmake.exe. But keep in mind that this version is experimental i.e.
It’s not supported by Kitware or us. Hello, I have a question, does IntelliSense automatically use ‘include directiories’ from CMakeLists.txt or have to do it manually in CppProperties.json? And does it ‘parse’ all CMakeLists.txt from specified directory’s structure? I mean, i have a project like this: Main project —CMakeLists.txt —Subproject1 ——CMakeLists.txt ——.hpp,.cpp files —Subproject2 ——CMakeLists.txt.
If the cpp and hpp files are specified as part of a CMake target in the Subproject2 CMakeLists.txt and this project is included via includesubdirectory(Subproject2), then you shouldn’t need to do anything else to get IntelliSense for these files. If you’re using the RC build, there is a bug in RC that I am aware of that you will need to workaround by closing all editors and restarting VS to get IntelliSense back on track (already fixed for our upcoming release). Let me know if you don’t get it to work as I’d like our team to investigate this further.
1) Anyone who has developed using CMake knows that at times you need to debug CMake. What is integrated method for debugging CMake itself in VS? In CMake GUI there was message window and message, which is certainly super awesome (read painful). Maybe there could be a bit of parsing of the message output to take developer right to offending CMakeLists.txt file and line. 2) When using CMake generated solution files VS on large projects VS tends to “run off into the forest” where builds cannot be canceled. There is of course my go to solution to this to terminate VS in task manager. Any thoughts on creating a “cancel build” button that well cancels a build?
Yes derived from experience absolutely) 3) CMake allowed the generating of both VS projects and CMake generated projects to coexist in the same project. Does integrated solution provide for this. 4) Will new CMake / VS integration allow for CMake to modify VS environment. Currently I have to get CMake to configure a runvs.bat file to set VS environment before calling/launching VS.
5) It’s really about time that VS has the concept of “a directory full of project files” Maybe there will come a day when I will not have to use Eclipse along side VS simultaneously though I am not holding my breath. 1) message works in VS as well, and it will be displayed in the Output Window CMake pane. 2) canceling the build is supported. If VS hangs for you during cancellation, please collect a crash-dump for devenv.exe and open a issue on so that we can investigate what’s going on. 3) build and debug should work. You won’t get accurate IntelliSense for the files in the vcxproj files yet but that’s something that is in the pipeline for us.
I am curious to learn more about your scenario. Do you mind reaching out to me at mluparu at microsoftdotcom or point me to your project (in case it’s OSS)? 4) That’s another scenario I’d like to understand better. Why isn’t configuring CMake variables sufficient and you need to set the environment as well? 5) keep giving us feedback and we’ll improve the “open folder” experience. Thanks for taking the time to provide it so far, keep it coming.
Hello, I’ve downloaded Cmake from its website, moved it to the Program Files folder, added a directory to the Path variable in Environment Variables section. Also, I downloaded Visual Studio 2015, ran it, added command prompt from External Tools Windows.
In Command Prompt, I’ve moved to the Cmake directory, ran cmake-gui.exe file. And as a result, if I type cmake-gui or cmake –version in command prompt in any directory, I see the correct corresponding output. However, I downloaded a software folder, when I select relative source and bin folders in the empty fields of Cmake GUI interface, I get an error: CMake Error at CMakeLists.txt:35 (project): No CMAKECXXCOMPILER could be found. You can also see the details here. That feature would be nice in some scenarios for sure (editing headers for eg.
And knowing that testing the changes could be done in a single source file and one does not need to blow up the console with building an entire target) it is moderately tricky to implement. Because the Solution Explorer is not a 1-1 representation of the MSBuild files but the actual folder structure, it is not immediately evident which build command is needed to be invoked. The IDE would have to scan ALL the generated MSBuild files and check, where the given file contributes to a target (may be multiple targets) and invoke all compile commands with flags corresponding to each of the dependant targets. With a few hundred targets, this scan might take as long as loading all the projects in a CMake-less scenario, which can be very long. We are a small game studio and we have currently crammed all supported platforms in a single VS2015 project. Now I am looking to a way to add even more platforms and if possible an easy way to generate the VS solution.
How do I add support for UWP, Xbox One (XDK), Linux and Android as a starter (building, deploying and debugging)? All of these are supported by Microsoft VS IDE now. Here are my first impressions. At default settings I see in the toolbar: An empty, unused combo-box “Debug Type”, a combo-box “Project Settings”, then “Select project type”, then “Project Configuration”. I think that’s a waste of space. Build configurations grouped together in Platform configurations just like in a classic Visual Studio solution would be best and most convenient IMHO.
If we have 5-7 platforms and at least 3 different build configurations the Project Settings list will be very long. I also hit the same problem described above. While attempting to debug breakpoints would be ignored.
I started trying all configurations and running the debug via the different options and debugging worked suddenly. Colorization, icons for the CMake files, a Project wizard and help in the form a Wiki or in the Standard help format would be better to locate. @ ddbug, Some of the customers have complained that they don’t want the build output under.vs folder. Infact they don’t want.vs under opened folder since it pollutes their source tree. We are in the process of removing.vs folder under source folder altogether. However build output is configurable through CMakeSettings.json file, just change the ‘buildRoot’ variable.
You can create a CMakeSettings file through menu CMake-Change Settiings. @Patrick,we would like to understand the perf issue you were observing. Could you provide us with more details. Could you send a mail to iyyappam @ microsoft dot com.
We have try VS2017 with CMake support but VS2017 only show the CMakeLists.txt inside the solution explorer. Our CMake files are inside a separate folder than source. Here is our Projects structure: project1/src/.cpp,.h project2/src/.cpp,.h platform/cmake/project1/CMakeLists.txt platform/cmake/project2/CMakeLists.txt We use also “getfilenamecomponent” to set our variable source directory and “file(GLOBRECURSE files.)” to set our source files. Are these commands compatible? Do I have to add information in the json file of VS or change my CMake? Otherwise, the project compiles and VS2017 finds the compiler.
Why isn’t the.exe in the bin/ folder? It creates it in a random CMAKE build directory on a completely different drive.
How do I change it? In what scenario would anyone want the.exe to be in a random location by default? I’m not very impressed with VS so far. It installed in a location I didn’t want it to, its very large, it took ages, and the initial installation wasn’t correct and it had to be reinstalled. It took me a whole work day to find where the compiler had been placed, and where the headers and libraries were placed.
It turned out they had been placed on different drives, in a directory structure that was 20 folders deep. It would have been fine if windows file explorer had a decent search function, but well, that’s a different issue. You can customize the default settings by selecting “Change CMake Settings” from the CMake menu.
This will create a CMakeSettings.json file near your CMakeLists.txt and will open it in the editor. In it, tweak the “buildRoot” property to set where your build files will be generated. Alternatively, if your CMake scripts support installing, you can right-click on your root CMakeLists.txt and choose “Install” command to copy all your public binaries out of the buildRoot folder and into the install folder (which you can also customize by setting CMAKEINSTALLPREFIX variable to a folder of your choosing inside the “variables” property in CMakeSettings.json). I am curious to learn more about your VS installation issues. Can you send me an email at mluparu at Microsoft dotcom?
Thanks, Marian.