[.NET Core 2.0] Identify more languages

[omajid]

We can add more/better detection here:

fabric8-generator/src/main/java/io/fabric8/forge/generator/pipeline/AbstractProjectOverviewCommand.java

Line 162 in d9e0541

if (java.util.Objects.equals(extension, "cs")) {

.NET Core 2.0 supports the following languages/projects:

• A general project type called a solution with a file type of *.sln. This file references other projects. It is optional; some projects do not have this but have one of the types below instead.
• C# project type: *.csproj. Individual C# files use the extension cs
• F# project type: *.fsproj. Individual F# files use the extension fs
• VB.NET Project type: *.vbproj. Individual VB files use the extension vb

[jstrachan]

in terms of pipelines; are all the 3 languages built with the same underlying tool? i.e. do we only need to maintain one set of pipelines for .Net Core 2.0 or should we have separate pipelines for C# / VB / F#?

Can we use the same pipelines for .Net Core 2.0 and 1.0? If not should we deprecate .Net 1.x and just support 2.0? If not how should we spot the difference between a 2.0 and 1.0 project?

[omajid]

in terms of pipelines; are all the 3 languages built with the same underlying tool? i.e. do we only need to maintain one set of pipelines for .Net Core 2.0 or should we have separate pipelines for C# / VB / F#?

Yes, a single dotnet build will build any/all of those. No separate build pipeline for C# vs VB vs F#.

Can we use the same pipelines for .Net Core 2.0 and 1.0?

.NET Core 1.0 projects are not runtime compatible with 1.1. I know our .NET Core 2.0 projects will not build or run with 1.0 or 1.1 compiler/runtime. I think it is best to treat each version of .NET Core as a separate thing.

If not should we deprecate .Net 1.x and just support 2.0?

I think that is a sensible approach. We never really supported .NET Core 1.x on OSIO as far as I am aware. Even Microsoft called it the bleeding edge and their 1.x releases are generally more unstable than most open source 1.x projects. .NET Core 2.0 is easier for end-user to start learning/using. It also has a better compatibility story with traditional .NET Framework libraries and tools.

If not how should we spot the difference between a 2.0 and 1.0 project?

I need to look into this.

[omajid]

An overview of versioning of different .NET Core components is described here: https://github.com/dotnet/designs/issues/3. It turns out the SDK is more "compatible" across versions than the runtime.

The latest .NET Core SDK (2.0 right now) should theoretically support building projects for all previous .NET Core versions as well. So we could just keep 2.0 (for now) and use it to build all .NET Core projects. When 2.1 comes out we could switch to that. I am sceptical this will work that smoothly.

For running applications, an exact match is required. An application targetting 1.0 needs a 1.0 runtime. An application targetting 1.1 will need a 1.1 runtime. Versions do not roll forward and there is no support for taking a .NET Core 1.1 application and running it against 2.0.