Merging of Slight.Alexa

[Silvenga]

How would you feel about moving the rest of Slight.Alexa to this project?

From the Slight.Alexa project:

• Project base
• Basic tests from sample responses
• Combined .Net 4.5 + .NetStandard 1.2 support (upgrade to 1.6?)
• Project icon
• Re-adding of XML docs

[timheuer]

Yeah, let's do this! A few comments:

• .NET Standard vs. .NET Core -- I'm curious why you think .NET Standard is better here?
• Project Icon -- I'd like to see something more generic (or none at all really, but the feather doesn't make sense to me :-))
• XML Docs -- I was going to start newer comments that hopefully would drive support for readthedocs.org

[Silvenga]

.NET Standard vs. .NET Core -- I'm curious why you think .NET Standard is better here?

As .NetStandard is the most portable profile for interoperability between .Net runtimes. .NetCore is very far from a replacement of .NetFull and it still does not work fully under Mono. With the project being under .NetStandard (compatible as a PCL library) we can use existing tooling and environments.

Project Icon -- I'd like to see something more generic (or none at all really, but the feather doesn't make sense to me :-))

It's a quill. I added that as the name "Alexa" comes from the Great Library of Alexandria. The icon doesn't need to represent anything, we can create meaning - Alexa is already an abstract ideal anyway. e.g. https://github.com/Fody/Fody

XML Docs -- I was going to start newer comments that hopefully would drive support for readthedocs.org

What system did you have in mind?

[jaddie]

.NetStandard

No version of .Net works fully under Mono as it is incomplete, hence why its proving hard work making Umbraco work on it, however making the Umbraco.Core run cross platform has been achieved rather easily and it works as expected on .NetCore on Linux. I would lean on the side of building on top of .NetCore as the framework but support .NetStandard as the standard & any issues with it running on Linux etc be raised at the appropriate locations since the target of Microsoft is now to make it work entirely as expected cross-platform, it is essentially the next level replacement & therefore if building something new which could be rather underpinning as a library then it should be as future-proof as possible by considering the big picture :)

Project Icon

Ah I see, thats new to me haha, I was in the same group as Tim & though it was a feather or something didn't really pay it much attention, why not make it something similar to what Amazon might already have for their services? They must have a media pack as well anyway

Documentation

I agree, readthedocs is nicely readable and usable :)

[Silvenga]

@jaddie

I would lean on the side of building on top of .NetCore

That would disregard 99% of the .Net ecosystem. .NetStandard is the replacement of the PCL's which run under the .NetCore and .NetFull runtimes.

From https://github.com/dotnet/standard/blob/master/docs/faq.md:

.NET Standard is a set of APIs that all .NET platforms have to implement. This unifies the .NET platforms and prevents future fragmentation.
.NET Standard 2.0 will be implemented by .NET Framework, .NET Core, and Xamarin. For .NET Core, this will add many of the existing APIs that have been requested.
.NET Standard 2.0 includes a compatibility shim for .NET Framework binaries, significantly increasing the set of libraries that you can reference from your .NET Standard libraries.
.NET Standard will replace Portable Class Libraries (PCLs) as the tooling story for building multi-platform .NET libraries.

[timheuer]

I talked with my counterparts on the .NET team and now agree with @Silvenga :-) -- let's move to .NET Standard (I think my project here is already on that based on the project.json) but some of the naming in the tooling is still a bit confusing for me. Let's do it!

[Silvenga]

@timheuer see #4 for tests and project normalization.

[jaddie]

Woops, I'm sorry I had my wires crossed haha, I agree actually, was thinking about them the wrong way round!

[bjorg]

Could you publish also a .NET Core 1.0.x compatible version? Otherwise, it cannot be used in C# for AWS Lambda, which only supports .NET Core LTS.

[Silvenga]

I'm kind of waiting for tooling support at this point. Even with VS2017 out tooling support is a little sporadic, I don't even know if VSCode works with the new .csproj format (with the deprecation of project.json and xproj).

[bjorg]

It works great in vscode and from the new `dotnet` CLI. However, because it was compiled for .Net Standard 1.2, I had to import it as a folder instead of a package for my .Net Core project. Really great library, by the way, works like a charm and saved me hours from manually mapping the Alexa skills myself! If there’s interest, I can look into how to make the solution compatible with multiple frameworks.

[timheuer]

It targets .NET Standard 1.6 which is compatible with .NET Core 1.0 -- https://github.com/dotnet/standard/blob/master/docs/versions.md

[bjorg]

Hmm. Well nuget doesn’t resolve it. Here’s what I get: dotnet add package Alexa.NET Microsoft (R) Build Engine version 15.1.548.43366 Copyright (C) Microsoft Corporation. All rights reserved. Writing /var/folders/4b/7t6zwfj88xl5rq008k8xjhqr0000gq/T/tmp7gM7gX.tmp info : Adding PackageReference for package 'Alexa.NET' into project '/HandleAlexaPrompts.csproj'. log : Restoring packages for /HandleAlexaPrompts.csproj... info : GET https://api.nuget.org/v3-flatcontainer/alexa.net/index.json info : OK https://api.nuget.org/v3-flatcontainer/alexa.net/index.json 369ms error: Unable to resolve 'Alexa.NET' for '.NETCoreApp,Version=v1.0'. error: Package 'Alexa.NET' is incompatible with 'all' frameworks in project '/HandleAlexaPrompts.csproj’.

[timheuer]

@bjorg can you tell me what type of project is HandleAlexaPrompts.csproj and what version of dotnet CLI you are using?

[bjorg]

For dotnet: ~> dotnet Microsoft .NET Core Shared Framework Host Version : 1.1.0 Build : 928f77c4bc3f49d892459992fb6e1d5542cb5e86 For dotnet CLI: ~> dotnet --version 1.0.1 For the .csproj file: ~> cat HandleAlexaPrompts.csproj <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>netcoreapp1.0</TargetFramework> </PropertyGroup> <ItemGroup> <PackageReference Include="Amazon.Lambda.Core" Version="1.0.0" /> <PackageReference Include="Amazon.Lambda.Serialization.Json" Version="1.0.1" /> <PackageReference Include="Newtonsoft.Json" Version="10.0.1" /> </ItemGroup> <ItemGroup> <DotNetCliToolReference Include="Amazon.Lambda.Tools" Version="1.4.0" /> </ItemGroup> </Project>

[timheuer]

Hmm this should be working but I am getting the error now too -- talking with my colleagues on .NET team to see what's up. Stay tuned.

[timheuer]

Adding the direct version works @bjorg:

dotnet add package Alexa.NET -v 1.0.0-beta-5 

[timheuer]

FYI @bjorg we logged a bug on the dotnet CLI: https://github.com/dotnet/cli/issues/6176

[bjorg]

Woohoo! That’s awesome! Thanks for helping me out and not squishing me like a puny bug for my false conclusions! :)

[timheuer]

No problem @bjorg -- this looks like a bug in how NuGet resolves things so it was a good find. I was banging my head on the false error message :-)

[terrajobst]

The permanent home of the bug is: NuGet/Home#4699

[jaddie]

This one is done as well? Although it was a good discussion about the reasoning around things, I've also edited my response in the conversation to resolve the reason for confusion, .NetStandard all the way, perhaps we should preserve this in the docs or a readme level file & close this issue?