-
Notifications
You must be signed in to change notification settings - Fork 1
Building Cross platform Applications with .NET Core
Pritesh Patel edited this page Jul 26, 2019
·
13 revisions
https://app.pluralsight.com/library/courses/dotnet-core-building-cross-platform-applications/
- Build console apps, services and web apps
- Build/run on a variety of platforms
- Switch from project.json (.NET Core RC versions) to MSBuild (.NET Core 1.0 onwards) tooling
- .NET Core is open-source
- Runtime vs SDK/Tools
- SDK refers to just the dotnet CLI
- .NET Core 1.2/2.0 - netstandard 2.0 (runtime)
- project.json -> MSBuild VS2017 (SDK)
- Note: Additions to .NET Core 2.0 e.g. .NET Standard 2.0 support, ASP.NET Core Razor pages, MSBuild support
- tools available for cross-platform .NET Core application dev
- single platform: VS Studio 2017 and later, VS Studio for Mac
- cross platform: VS Code, Jet Brains Rider, dotnet cli
- no issue in developers using different platforms to contribute to a project, MSBuild tooling is consistent cross-platform
- See Microsoft .NET Core website
- creating an app that checks links are working on a webpage
-
dotnet new -handdotnet new console
- cf. project.json (old .NET Core config file) with new MSBuild .csproj file
-
project.jsonno longer exists butglobal.jsoncan still be used to override config (e.g. specify .net core version to use) -
dotnet --versiondisplays the version of .NET Core project is using
- The cleaner .csproj file aims to match the simplicity of the previous project.json file
- This is achieved by development of MSBuild which can handle the simpler, cleaner .csproj files
-
dotnet restoreto restore package dependencies -
dotnet build(optional) to build app -
dotnet runbuilds and runs app -
treeto view current directory hierarchy -
obj\project.assets.jsonreplaces previousproject.lock.jsonfile
- use the same commands as above for Mac (predictably!)
-
docker run -it microsoft/dotnet:latestruns a docker container with image containing .NET Core toolchain -
docker run -it microsoft/dotnet:1.0.3-sdk-msbuildrun specified .NET Core version -
docker run -it -v $(pwd):/console microsoft/dotnet:1.0.3-sdk-msbuildmount host machine's volume within the docker container (e.g. to access source code) - can download and customise an existing docker file as required
-
docker build -t dotnet-sdk-preview4 -f Dockerfile.preview4 .builds a docker image from a docker file in the current dir -
docker images | grep dotnetlist available docker images -
docker run --rm -it -v $(pwd)/CheckLinksConsole:/console dotnet-sdk/preview4- runs container with the specified image, removing the container after execution completes, map the volume (as previous) - run the same commands to restore, build and run console app
- Windows containers see Nano Server and Server Core which can be used with a Windows container
- dotnet CLI was originally built to work with
project.json, but since being replaced with the new.csprojfile it mostly now just 'shells' out to MSBuild - SDKs used by VS.NET/VS Code work directly with MSBuild, dotnet CLI can be used by other editors/IDEs or can be used directly
- The SDK provides core functionality needed by .NET core projects - MSBuild tasks and project templates - used by VisualStudio and CLI
- You can open the project created above in VS.NET and save the solution file which can then be opened by e.g. VS.NET for Mac
- You can use the editor to create .NET Core projects, although there appear to be more options available when using the CLI (which has been been developed more in the open with it being open source)
- Use https://apisof.net to find APIs and their framework compatibility or use .NET Core API Reference or use https://packagesearch.azurewebsites.net
- Can check Dependencies in VS.NET to ensure required package is already included or add it if required
- VS.NET will use SDK to build and then run app
- Search for NuGet packages on https://www.nuget.org
- Best Case - package supports .NET Standard
- Can also use PackageTargetFallback to use .NET Framework packages if it is known to work with .NET Core (test!)
- Use a fork that supports .NET Standard (or .NET Core)
- Create own fork if one doesn't exist
- .NET Standard 2.0 - compatible with .NET Framework packages! (provides support for full BCL) - see https://devblogs.microsoft.com/dotnet/introducing-net-standard/. .NET Standard 2 provides a compatiblity shim for .NET Framework binaries
- use dotnet-apiport (command line tool) to scan a DLL to analyse whether it is compatible