Notes
project.json
is not a thing
- The final verison of .NET Core will not support project.json (dotnet Core 1.0.3 - SDK RC4 drops project.json support)
- Instead it's going to use a simplified csproj files.
- https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/
global.json
is not a project listing thing.
global.json
is planned to be used for defining the sdk version only.- https://github.com/dotnet/docs/blob/master/docs/core/preview3/tools/global-json.md
- Projects are grouped into
.sln
files still.- Created with
dotnet new sln
- Projects addeed with
dotnet sln SOLUTION.sln add PROJECT.csproj
- Created with
Hello World
dotnet new console dotnet restore dotnet run
Tools?
Tools are .NET Core version of 'devDependancies' and are added to the .csproj file
<ItemGroup> <DotNetCliToolReference Include="Microsoft.DotNet.Watcher.Tools" Version="1.0.0-msbuild3-final" /> </ItemGroup>
Visual Studio & IIS Specifics
VS & IIS uses extra files to bne used as the external server pointing at Kestral
launchSettings.json
web.config
Setting the environment
- Visual studion helps you set the environment variable
ASPNETCORE_ENVIRONMENT
to change the Environment. - Other systems set it by handler
ASPNETCORE_ENVIRONMENT=Development dotnet run # or export ASPNETCORE_ENVIRONMENT=Development
Configuration Files like appSettings.json
Microsoft.Extensions.Configuration.<<TYPE>>
- Setup
IConfigurationRoot
viaConfigurationBuilder
in Startus.cs
global.json
vs SOLUTION.sln
global.json
- For defineing the sdk version
- SDK Version can be taken from
dotnet --version
{ "sdk": { "version": "1.0.0-rc4-004771" } }
SOULTION.sln
- For grouping project together
- Created with
dotnet new sln
- Managed with
dotnet sln add|remove|list
To use the dependancy project
- Add Project reference
<ItemGroup> <ProjectReference Include="..\helloworld-lib\helloworld-lib.csproj" /> </ItemGroup>
- Build dependancy
/path/to/sln/>dotnet build
- Restore project using the dep.
/path/to/sln/>dotnet restore
- Run the project
/path/to/sln/dotnet run --project my-project/my-project.csproj
NuGet and Class Libraries
dotnet new classlib
can be converted into NuGet packages withdotnet pack
.- These packs an be deployed to the default NuGet Repository
/ViewsImports.cshtml
- Everything listed is imported into every view.
- Tag helpers should be added there.
Notes from Pluralsight Understanding ASP.NET Core (Update)
TLDR
Exploring ASP.NET Cor in Visual Studio
ASP.NET Core is different from other versions of the framework
New Project structure uses `project.json`
Sites serve from `wwwroot` folder
Packages
- NuGet
- Server side packages
- NPM
- Client side packages
- (no term)
- Task Runner picks up config files
- Gulp, Grunt, etc..
- 'Bundler and Minifier'
Startup class is `Program.cs::Main::host.Run()`
Dependancy injection in `Startup.cs::ConfigureServices`
Pipeline :: IIS - dotnet - kestrell - App.entry - MiddleWare
Understanding ASP.NET Core MVC
Setup MVC
- Inject
- app.AddMVC()
- Configure
- app.UseMVC(routes)
- app.UseStaticPages()
- app.UseStatusCodePages()
- app.UseDevelopmentExceptionPages()
Environments
Unified MVC
- MVC & WebAPI combined into MVC
- IoC is needed for `IActionContextAccessor`
- IoC free for `IUrlHelper`
Tag Helpers
- declare/import `@appTagHelper "*, Microsoft.AspNet.Mvc.TagHelpers"` in /Views/ViewImports.cshtml
- Extra elements `<environments \>`
- Mostly attributes `<label asp-for="PROPERTY" />`
Application Settings
- Managed as `json` files, injecting in ConfigurationSetting, and Configuration builder.
- Need to include dependancy in project.json
- { 'dependancies': 'Microsoft.Extensions.Options.ConfigurationExtensions' }
View Components
- Reusable _partial views to enable complexity
Developing Applications Access Frameworks and Operating Systems
.NET CORE Framework
- Modular version of .NET Framework
- .NET has different versions for diffent platforms, .NET Core is for all platforms
- CoreCLR
- Includes runtime. (garbage collection, jit compiler, base types…)
- NuGet Package
- CoreFX
- Includes extra common classes (File Manipulation, Lists…)
- Does not include framework
- Each assembly is distributed in separate packages in NuGet
Application Type
- Portable
- expects .NET Core to be included in the app.
- Self-Contained
- .NET Core is excluded in the app.
.NET PLatform Standard
- DLL assemvlies are compiled and bounce to specific sersions of .BET and will not run on other platforms
- targets multiple versions but is still tied to the platform
- succeeds PCL, uses a version number to represent the api, shich is backward compatible
- Versions describes in `project.json` { 'framework': 'xxxx' }
- The actual framework is included in teh dependancies.
- If "type":"platform" is included the 'framework' is expected to exists. IE. A Portable
Framework Choice
.NET Framework | Mono | .NET Core |
---|---|---|
Machine-wide | Machine-wide | Choice |
Existing code | Existing Code | New Code |
Many Types | Many Types | Limited Types |
Windows Only | Cross-Platform | Cross PLatform |
.NET CoreCLI
- dotnet
- Command line
- Hosts the CLR allowing cross platform dev
- Other helpers EG. build, pack, restore, publish
- `project.json` containes dotnet core commands
- `project.json.lock` contains compiled list of package dependancies
Deploying ASP.NET Core Applications
Deployment Options
- Run, Build, Pack, Publish
Self Hosting
- Portable Core dlls can be passed to `dotnet` and run
- Standalone apps (IE. Without 'type': 'platform') require
- a runtime section in project.json
- Native Dependancies to be included/installed
Deploy IIS/Azure
- Needs AspNetCoreModule
- installed
- handler added to a web.config
- Azure already has it installed
Deploy Linux
- When installing to unsupported runtimes (EG. No listed Core Runtime Identifier, RID)
- build with Full .NET Framework, user mono to run and install required external dependancies
- For nginx, setup as a reverse proxy to the kestral application