After writing the previous post about getting some of the infrastructure working for non Windows, I’ve seen better ways of getting it to work. In particular we have seen the use of netfx.props as seen in FSharp.TypeProviders.SDK. Then you add the following to your csproj or fsproj file: <Project Sdk="Microsoft.NET.Sdk"> <Import Project="..\netfx.props" /> as can be seen in FSharp.TypeProviders.SDK.fsproj.

After writing the previous post about getting some of the infrastructure working for non Windows, I’ve seen better ways of getting it to work. In particular we have seen the use of netfx.props as seen in FSharp.TypeProviders.SDK. Then you add the following to your csproj or fsproj file: <Project Sdk="Microsoft.NET.Sdk"> <Import Project="..\netfx.props" /> as can be seen in FSharp.TypeProviders.SDK.fsproj.

One of the questions I’ve started asking myself is what makes for happy C#? After a few years getting a bit more understanding of ML like languages like F# I’ve started to realise that C# is not built to write the kind of code that you write in an ML. Instead, you are happier when you embrace the Ruby-like patterns in C#. If you look at C# sort of like a typed Ruby like language: Object orientation, mutability first and meta programming using reflection. When you see that this is shared between the two lan[...]

One of the questions I’ve started asking myself is what makes for happy C#? After a few years getting a bit more understanding of ML like languages like F# I’ve started to realise that C# is not built to write the kind of code that you write in an ML. Instead, you are happier when you embrace the Ruby-like patterns in C#. If you look at C# sort of like a typed Ruby like language: Object orientation, mutability first and meta programming using reflection. When you see that this is shared between the two lan[...]

One thing I neglegted to mention was that there isn’t really out of the box editor support for targeting both net45 and netstandard1.6 (or higher versions). My standard workaround for this have been to only target netstandard1.6 or lower for most of the relevant assemblies that I work on a day to day basis on. This works for most of the internal libraries since we deploy either netcoreapp1.1 or netcoreapp2.0 to Azure. For libraries that are supposed to be consumed by a wider set that has been a bit of a [...]