# How (not) to build .NET coreclr on FreeBSD



## unitrunker (Feb 28, 2018)

Trying this out on FreeBSD 11.1

The proper build instructions for coreclr are here:

https://github.com/dotnet/coreclr/blob/master/Documentation/building/freebsd-instructions.md

Results from the documented instructions:

# git clone https://github.com/dotnet/coreclr.git
# cd coreclr
# ./build.sh clang50 release

I get errors the build script can't find llvm-ar, llvm-link, and llvm-nm. My dirty fix for this error is symbolic links in /usr/local/bin eg, 'ln -s llvm50-ar llvm-ar' etc. Preferably done inside a jail. That gets me farther along but no joy.


```
-- Configuring done
-- Generating done
-- Build files have been written to: ./coreclr/bin/obj/FreeBSD.x64.Release
~/coreclr
~/coreclr/bin/obj/FreeBSD.x64.Release ~/coreclr
Executing make install -j 5
[  0%] Building CXX object src/pal/src/eventprovider/CMakeFiles/eventprovider.dir/lttng/eventprovdotnetruntime.cpp.o
[  0%] Building CXX object src/corefx/System.Globalization.Native/CMakeFiles/System.Globalization.Native.dir/casing.cpp.o
[  0%] Building CXX object src/corefx/System.Globalization.Native/CMakeFiles/System.Globalization.Native_Static.dir/casing.cpp.o
In file included from ./coreclr/bin/obj/FreeBSD.x64.Release/eventing/eventprovider/lttng/eventprovdotnetruntime.cpp:24:
./coreclr/bin/obj/FreeBSD.x64.Release/eventing/eventprovider/lttng/tpdotnetruntime.h:29:10: fatal error: 'lttng/tracepoint.h' file not found
#include <lttng/tracepoint.h>
         ^~~~~~~~~~~~~~~~~~~~
[  0%] Building CXX object src/pal/src/CMakeFiles/coreclrpal.dir/cruntime/file.cpp.o
1 error generated.
```

The above looks like the typical goof of using angle brackets instead of quotes. I set this aside (may come back later) to try another approach.

The convention for most cmake builds is (a) mkdir build (b) cd build (c) cmake .. and (d) make. That almost works. 
Missing a version.cpp and compiler looks for etmdummy.h in the wrong place. Two features "perftracing" and "even_trace" seem to be not implemented for this platform. Adding placebos allows cmake to progress. Also - these steps *do not* require the symbolic link hack above.

# git clone https://github.com/dotnet/coreclr.git
# cd coreclr
# mkdir build
# cd build
# touch version.cpp
# vi ../src/inc/etdummy.h
# (insert one line -> #include "../gc/env/etmdummy.h" )
# cmake .. -DCMAKE_BUILD_TYPE=RELEASE -DFEATURE_PERFTRACING=0 -DFEATURE_EVENT_TRACE=0

This gets me further along than running "build.sh" above. cmake creates the Makefile(s). However, actual compile fails.

# make


```
[ 14%] Built target utilcode_dac
[ 14%] Building CXX object src/vm/dac/CMakeFiles/cee_dac.dir/__/gctoclreventsink.cpp.o
./coreclr/src/vm/gctoclreventsink.cpp:23:5: error: use of undeclared identifier 'FireEtwGCDynamicEvent'
    FireEtwGCDynamicEvent(wideEventName, payloadSize, (const BYTE*)payload, GetClrInstanceId());
    ^
1 error generated.
*** Error code 1
```

I do not see this symbol anywhere within coreclr. After commenting out that one line, the build progresses ...


```
[ 27%] Built target utilcode
[ 27%] Built target gcinfo
[ 27%] Building CXX object src/vm/wks/CMakeFiles/cee_wks.dir/__/prestub.cpp.o
./coreclr/src/vm/prestub.cpp:730:17: error: too many arguments to function call, expected at most 6, have 8
                pConfig->ProfilerRejectedPrecompiledCode(),
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./coreclr/src/inc/eventtracebase.h:614:9: note: 'MethodJitted' declared here
        static VOID MethodJitted(MethodDesc *pMethodDesc, SString *namespaceOrClassName=NULL, SString *methodName=NULL, SString *methodSignature=NULL, SIZE_T pCode = 0, ReJITID rejitID = 0) {};
        ^
1 error generated.
```

Still not there.


----------



## unitrunker (Mar 1, 2018)

Okay ... wiped everything. Started over with a clean git clone of coreclr. Switched to clang 4.0. Was missing pkg lttng-ust. Fixed that. The build.sh script passes the config phase (I see "configuing done"). Chokes on linking. lttng won't link.

libs are in the lib path (/usr/local/lib) ...

The cmake generated link.txt file is missing the "-L/usr/local/lib". 

`./src/pal/src/eventprovider/tracepointprovider/CMakeFiles/coreclrtraceptprovider.dir/link.txt:
/usr/bin/clang++ -fPIC -Wall -Wno-null-conversion -std=c++11 -g -O0    -Wl,--no-gc-sections -shared -Wl,-soname,libcoreclrtraceptprovider.so -o libcoreclrtraceptprovider.so CMakeFiles/coreclrtraceptprovider.dir/__/lttng/traceptprovdotnetruntime.cpp.o CMakeFiles/coreclrtraceptprovider.dir/__/lttng/traceptprovdotnetruntimerundown.cpp.o CMakeFiles/coreclrtraceptprovider.dir/__/lttng/traceptprovdotnetruntimestress.cpp.o CMakeFiles/coreclrtraceptprovider.dir/__/lttng/traceptprovdotnetruntimeprivate.cpp.o -llttng-ust`


----------



## unitrunker (Mar 1, 2018)

`[100%] built target ilasm`


Wow. That works. Need to figure out how to tell cmake to do the right thing (eg. pass the "-L/usr/local/lib") so I don't have to hand-edit a generated link.txt file.


----------



## unitrunker (Mar 1, 2018)

Woo hoo! Seems to work ...


`./ilasm
Usage: ilasm [Options] <sourcefile> [Options]

Options:
/NOLOGO         Don't type the logo
/QUIET          Don't report assembly progress
/NOAUTOINHERIT  Disable inheriting from System.Object by default
/DLL            Compile to .dll
/EXE            Compile to .exe (default)
/PDB            Create the PDB file without enabling debug info tracking
/APPCONTAINER   Create an AppContainer exe or dll
/DEBUG          Disable JIT optimization, create PDB file, use sequence points from PDB
/DEBUG=IMPL     Disable JIT optimization, create PDB file, use implicit sequence points
/DEBUG=OPT      Enable JIT optimization, create PDB file, use implicit sequence points
/OPTIMIZE       Optimize long instructions to short
/FOLD           Fold the identical method bodies into one
/CLOCK          Measure and report compilation times
/RESOURCE=<res_file>    Link the specified resource file (*.res) 
            into resulting .exe or .dll
/OUTPUT=<targetfile>    Compile to file with specified name 
            (user must provide extension, if any)
/KEY=<keyfile>      Compile with strong signature 
            (<keyfile> contains private key)
/KEY=@<keysource>   Compile with strong signature 
            (<keysource> is the private key source name)
/INCLUDE=<path>     Set path to search for #include'd files
/SUBSYSTEM=<int>    Set Subsystem value in the NT Optional header
/SSVER=<int>.<int>  Set Subsystem version number in the NT Optional header
/FLAGS=<int>        Set CLR ImageFlags value in the CLR header
/ALIGNMENT=<int>    Set FileAlignment value in the NT Optional header
/BASE=<int>     Set ImageBase value in the NT Optional header (max 2GB for 32-bit images)
/STACK=<int>    Set SizeOfStackReserve value in the NT Optional header
/MDV=<version_string>   Set Metadata version string
/MSV=<int>.<int>   Set Metadata stream version (<major>.<minor>)
/PE64           Create a 64bit image (PE32+)
/HIGHENTROPYVA  Set High Entropy Virtual Address capable PE32+ images (default for /APPCONTAINER)
/NOCORSTUB      Suppress generation of CORExeMain stub
/STRIPRELOC     Indicate that no base relocations are needed
/ITANIUM        Target processor: Intel Itanium
/X64            Target processor: 64bit AMD processor
/ARM            Target processor: ARM processor
/32BITPREFERRED Create a 32BitPreferred image (PE32)
/ENC=<file>     Create Edit-and-Continue deltas from specified source file

Key may be '-' or '/'
Options are recognized by first 3 characters
Default source file extension is .il

Target defaults:
/PE64      => /PE64 /ITANIUM
/ITANIUM   => /PE64 /ITANIUM
/X64       => /PE64 /X64`


----------



## unitrunker (Mar 3, 2018)

This works ... CMakeLists.txt ...

Before:
`if(CMAKE_SYSTEM_NAME STREQUAL FreeBSD)
  set(CLR_CMAKE_PLATFORM_UNIX 1)
  set(CLR_CMAKE_PLATFORM_UNIX_AMD64 1)
  set(CLR_CMAKE_PLATFORM_FREEBSD 1)
endif(CMAKE_SYSTEM_NAME STREQUAL FreeBSD)`
After:
`if(CMAKE_SYSTEM_NAME STREQUAL FreeBSD)
  set(CLR_CMAKE_PLATFORM_UNIX 1)
  set(CLR_CMAKE_PLATFORM_UNIX_AMD64 1)
  set(CLR_CMAKE_PLATFORM_FREEBSD 1)
  set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L/usr/local/lib")
  set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -L/usr/local/lib")
endif(CMAKE_SYSTEM_NAME STREQUAL FreeBSD)`

This avoids hand-editing the link.txt file. Need to figure out how to use the chosen clang version (eg 4.0 vs. 5.0) instead of assuming the default.


----------



## HL1234 (Apr 15, 2018)

There is an other link to handle with building CoreCLR on FreeBSD:

https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD

How I do understand, one of the sence of building CoreCLR, is the following:
Running ASP.NET Core2 Websites with the build in web-server Kestrel in an ASP.NET core2 web project
( _Kestrel web server implementation in ASP.NET Core see_ https://docs.microsoft.com/de-de/as...kestrel?view=aspnetcore-2.1&tabs=aspnetcore2x) and using apache2x or nginx as reverse proxy:





Until now there is a completed instruction for Linux, MAC and sure Windows - but I missed some what real works with FreeBSD. Later on it would be fine to have a port for installing CoreCLR. 
ASP.NET core or .Net-Framework core are the "core" open source components of the proprietary .NET Framework of Microsoft for different famous OS platforms - but FreeBSD until now is missing for it
(Maybe this forum thread belongs better to Programming)


----------



## unitrunker (Apr 17, 2018)

I've set aside Microsoft's coreclr in favor of monodevelop. It is much better supported from pkg and ports. It would be cool to have an "official" CLR but this isn't a blocker.


----------



## fryshke (May 24, 2018)

Any new developments? Version 2.1 (still in RC stage) seems to have some improvements for FreeBSD - https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD

Any chances FreeBSD official repos will contain .NET Core? I miss FreeBSD, but have to use Arch on both of my servers.


----------



## drhowarddrfine (May 24, 2018)

fryshke said:


> Any chances FreeBSD official repos will contain .NET Core?


I'm pretty sure the hopes and dreams of FreeBSD developers lie elsewhere. 

While Windows users love to watch Microsoft slowly take over Linux, I can only hope no such thing happens to FreeBSD. 

The two times my company needed to be involved with .NET, the first cost us $50,000 as Microsoft made a change to their software long ago. The second was recently and cost a client of ours an unknown amount of time and money.


----------



## fryshke (May 24, 2018)

drhowarddrfine said:


> The two times my company needed to be involved with .NET, the first cost us $50,000 as Microsoft made a change to their software long ago. The second was recently and cost a client of ours an unknown amount of time and money.


Was it in 1.0 days? Or 2.0 and you didn't migrate to 3.0, even if it clearly was stated 3.0 was not backwards compatible with 2.0 due to generics implementation. Or was it Mono?

Because we still have .NET 3.0 services chugging along nicely.


----------



## drhowarddrfine (May 24, 2018)

fryshke The first was in the 1.0 days.


----------



## fryshke (May 24, 2018)

drhowarddrfine said:


> fryshke The first was in the 1.0 days.


Yea, dark ages, .NET was just crappy Java copy. I've only started liking .NET since 3.5, and just won't do any hobby project on anything but .NET since 4.0. Besides having official FreeBSD support, other languages (and their runtimes, if they have them) don't offer anything more than C# and aren't so feature rich or have a syntax that I like.

And what about the second time?


----------



## jokab (Oct 2, 2018)

I stopped because I needed to install win10 but I only have win7 on a VM.
https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD#building-corelib-on-windows

Has anybody done this already and if so, could they just share the binaries for freebsd so others can pick them up and continue with their thing?


----------



## kpedersen (Oct 3, 2018)

fryshke said:


> Any chances FreeBSD official repos will contain .NET Core?


I am actually surprised that ports doesn't already have .NET core. Microsoft generally likes to push this kinda crud on everyone and it wouldn't have taken one of their developers *that* long to make an official port.

Oh well. No real loss. It also saves our guys the small bit of effort from removing it from ports again once Microsoft drops .NET entirely.
I am still 99% sure that .NET Core is just the first stage in Microsoft's product discontinuation strategy for the entire .NET ecosystem.


----------



## roddierod (Oct 4, 2018)

kpedersen said:


> I am actually surprised that ports doesn't already have .NET core. Microsoft generally likes to push this kinda crud on everyone and it wouldn't have taken one of their developers *that* long to make an official port.
> 
> Oh well. No real loss. It also saves our guys the small bit of effort from removing it from ports again once Microsoft drops .NET entirely.
> I am still 99% sure that .NET Core is just the first stage in Microsoft's product discontinuation strategy for the entire .NET ecosystem.



Perhaps this should be another thread or off topic or something, but I'm really curious as to why you are so certain about .Net being dropped.  I know MS is a business and they do stuff like this to keep people buying things they don't want or need, but this almost seems like a fatal business mistake to me.  Normally something like this I'd just blow off. But I remember your prediction on MS starting to push C++ that at the time seemed like crazy talk, but then it happened.  Since my day job invovles writting .Net apps mostly I'm really curious if I can ramp up my trying to convince management to switch to GO


----------



## acheron (Oct 4, 2018)

jokab said:


> I stopped because I needed to install win10 but I only have win7 on a VM.
> https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD#building-corelib-on-windows
> 
> Has anybody done this already and if so, could they just share the binaries for freebsd so others can pick them up and continue with their thing?


Have you tried this patch ? https://reviews.freebsd.org/D16707


----------



## drhowarddrfine (Oct 4, 2018)

roddierod You should switch to golang no matter what Microsoft does. Anything involving Ken Thompson and the former Bell Labs crew is worth pursuing. Especially if it's for professional software and not Windows games.


----------



## roddierod (Oct 4, 2018)

drhowarddrfine said:


> roddierod You should switch to golang no matter what Microsoft does. Anything involving Ken Thompson and the former Bell Labs crew is worth pursuing. Especially if it's for professional software and not Windows games.


 
I totally agree, and use it for everything I can. But I working in a corporate environment that has this huge contract with MS so I have no choice in large projects.  But for smaller apps that no one cares about I use Go when I can and for any personal programming.


----------



## kpedersen (Oct 5, 2018)

(Note: This is far too long. I don't expect anyone to actually read it!)



roddierod said:


> Normally something like this I'd just blow off. But I remember your prediction on MS starting to push C++ that at the time seemed like crazy talk, but then it happened.


My "in-progress" PhD is partly touching on this topic (and I have spent far too long in completing it so far haha) so as a side effect I am either going mad or starting to be able to see trends in these kinds of development products from these kinds of companies (They cycle and repeat in such a boring way it is almost cringeworthy). Sometimes there are so many subtle hints that I actually find it hard to explain my thoughts. I will try!

I think the big one is the realisation that Limbo, Java, .NET are all the same technology and this technology is not only dated but has one crucial issue; they are themselves incredibly reliant on C / C++ because their VMs can only really be implemented in a native language. Microsoft only knows C++ so that is the obvious choice and that means they can also never really escape it.

https://github.com/dotnet/coreclr/tree/master/src/vm

You can see here that it is all C++ and more specifically it is not a very portable affair (you can see in the architecture specific subfolders). They have to manually implement arm[64] and x86[_64]. That is not a great position to be in when trying to support a platform that changes their architecture so whimsically as the mobile industry (MIPS, armv6, armv7, armhf, etc.). This is their first problem. They have to play catchup to port their fat .NET VM to a new and upcoming platform. They miss all the best cake.

Just look at Emscripten: C/C++ and any native language using LLVM can now be compiled to asm.js and WebAssembly. The big old fat JVM and .NET VM are not going to be supported any time soon because asm.js is neither arm or x86! Games engines like Unity developed an il2cpp utility to translate .NET IL to C++ code to get round this issue.

As they move over to low performance platforms (Mobiles / tablets) which was the gimmick of the day when I made my prediction, Microsoft only really had one tool left in its belt suitable for these kinds of environments that it knew it could embrace (C++), extend (C++/cx) and extinguish (i.e C++/clr: pure replaced by... C#?).

https://raw.githubusercontent.com/dotnet/coreclr/master/src/gc/gc.cpp

Then chuck in more portability and performance hoops such as this massive GC unit and you will start to see, what is the point? Does a VM platform really offer that much over modern native runtimes? Mobile platforms are so reliant on being able to call native code that most Android apps today are all JNI bindings rather than actual C++ / Java code! Same with .NET native interop when using things like Xamarin. .NET bindings are too slow to keep up with the sloppy fast moving pace of mobile.

So this isn't really anything to do with language (C# vs C++). It is entirely to do with the fact that they are finding it much harder to market the old idea of a VM platform over native in the world of sub-par mobile platforms.



roddierod said:


> Since my day job invovles writting .Net apps mostly I'm really curious if I can ramp up my trying to convince management to switch to GO



I am hoping that now Microsoft has pulled out of the Windows Phone market and have failed hard in making an AppStore prison, they will focus on their enterprise customers where .NET and Java are good enough in performance (i.e on full desktop PCs) and easy to architect. However, Microsoft are not sane (or rather their shareholders aren't) and would rather have nothing than the prospect of not being able to exert control over consumers (or their data) to stay relevant. To protect yourself and provide your professional due diligence whilst avoiding being "that guy who always wants to be different" then perhaps see if you can migrate your legacy systems to run on the open-source Mono implementation to keep them alive once Microsoft fscks up.

But yes, I basically think Java, .NET and of course Limbo are old dead designs that will fade away (perhaps slowly). Migrating to another platform (not even necessarily language) is a very good idea.

Ultimately the only language that will remain after the test of time is C because that will always be what operating systems are written in. However Go is powered by the same AT&T guys behind Limbo / Plan 9 and these guys are quite familiar with C and know this .
So where Go has something good for it is that it doesn't just bind against C unlike Java and .NET but instead it can actually consume C code directly (which is part of the main power of C++). You can actually embed C into it (albeit in a weird way). This eliminates the problem of dying bindings plaguing Java and .NET. Perhaps this will be its saving grace!
Fun fact. Early versions of Go even used to use Ken Thompsons C compiler for the underlying binary generation! Even on Windows. You could even use it standalone for C code.

Another good one is Lua. Implemented in pure ANSI-C so is 99.9% as portable as C itself (and perhaps more so because it can be implemented in other languages). It doesn't rely on virtual memory or any platform specific stuff or JIT and any architecture specific stuff. If performance is not critical, Lua is my recommendation because you are effectively just using C (just memory safe ).

I am going to stop my rant now. If anyone disagrees, I am very interested in hearing your thoughts. I am not religious about any of this, these are just my observations. If I have anything horrifically wrong, please let me know so I can amend my thesis haha!

Edit: One last prediction ... Objective-C will outlive Swift!


----------



## roddierod (Oct 5, 2018)

Thank you.  This all makes senses to me. I was looking at it from the MS likes to lock people in and .Net seems to do that so why get rid of it.  

Enterprise wise, when I 1st started everything we did was desktop apps (C++ then Delphi). But now everything is going web based because the C titles don't want to be locked into the office and just want to pull stuff up where ever they are.


----------



## kpedersen (Oct 5, 2018)

Well, the C world has a solution for that!
https://learnbchs.org/

Note: I don't think you should try to push this technology in your company. .NET is probably the better idea for now haha.


----------



## drhowarddrfine (Oct 5, 2018)

kpedersen Everything you said are things I felt in my bones over the years. Good to hear from one who's digging into it.



kpedersen said:


> One last prediction ... Objective-C will outlive Swift!



This is the same thing an Apple developer told me three years ago. Made me feel good then. Makes me feel good now.


----------



## roddierod (Oct 5, 2018)

kpedersen said:


> Well, the C world has a solution for that!
> https://learnbchs.org/
> 
> Note: I don't think you should try to push this technology in your company. .NET is probably the better idea for now haha.



Yeah, the just ignore me now anyway. I've been trying almost 20 to get them to move away from MS lockin. A FreeBSD/Apache webserver was the closest I ever got.

Also trying to get them to replace pizza parties with prime rib parties and that not going well either


----------



## shkhln (Oct 6, 2018)

kpedersen said:


> https://learnbchs.org/



That's funny, but actually please don't use plain C as a backend language. Stdlib string handling functions alone are horrifying. For example, It's not at all difficult to find strncmp misuse in FreeBSD sources.


----------



## wolfspider (Oct 6, 2018)

kpedersen said:


> (Note: This is far too long. I don't expect anyone to actually read it!)
> 
> 
> My "in-progress" PhD is partly touching on this topic (and I have spent far too long in completing it so far haha) so as a side effect I am either going mad or starting to be able to see trends in these kinds of development products from these kinds of companies (They cycle and repeat in such a boring way it is almost cringeworthy). Sometimes there are so many subtle hints that I actually find it hard to explain my thoughts. I will try!
> ...



.Net is already running in ASM.js it's a project called Blazor has a running demo and everything.

C# is component based while C++ and C are not such as to say there is no IDL or very specific interfaces there which were a pain to implement in the past. That's a big part of the design, at least according to the creator of C#.

.Net Core has AOT as well (CoreRT) and LLVM is showing some good performance starting out with this.

The performance differences between Mono and .Net Core are vast enough that developers would not want to just stick with Mono to protect themselves. Having done significant development with both I know there is a big difference. I think on the surface maybe seeing that something is powered by C# there is some belief that it's all the same- absolutely not. I'm interested in what your experience is running NuGet for Mono on FreeBSD? .Net Core is absolutely on par with Java performance-wise now without all the licensing pitfalls. Still to this day there is an "official" Oracle Java JDK and OpenJDK due to licensing? Luckily, not an issue with C#. 

Go is an amazing language and I see a lot of interest in the FreeBSD community there. I think knowing it is a priority for myself at least but what I can do in a few lines of C# compared to Go is vast. Mostly professionals using C# are not utilizing it's closeness to the metal but rather how quickly projects can get off the ground, ported to other systems, and concepts taught to other developers. I can get a "fresh out of college" developer doing significant work in about 3 months with C#. Doing this with Go I think would be much more difficult. 

There are a lot of good examples and documentation out there for C# just a ton of examples and videos. You mention Lua- the docs for Lua have become more dense but still pretty minimal. Ok, so I want to cast to a string in Lua and their docs list one "tostring" method and an example- cool! The C# docs show you how to extend, overload and override "ToString" as well as a few other tricks and that's just one example. Does Lua have anything like LINQ or Entity Framework or even a debugger remotely as powerful? Just simply talking productivity here Microsoft's CLR ecosystem has an insanely great debugger. This is all before I even start in on IDE's here so we won't go there ha!

I think you would be surprised though that I do think you are right that the design is right near the end of its life for these types of languages. I think the last two weeks or so it's been weighing on me pretty heavy realizing I need to learn Go or Rust or both. I'm surprised that there isn't more "learn Node.js" in the BSD camp since, when it works, it performs extremely well and JavaScript isn't going anywhere anytime soon it looks like. 

Unity uses C# one way or another and powers many, many mobile apps like it or not the damage is done and it's still C# so I think trying to say it technically isn't the same design pattern therefore .Net doesn't run on mobile is pre-emptive. Xamarin counts as well and enough developers use them both that they will continue on for a long time. This is exactly why C# on FreeBSD would benefit it is because you can keep a codebase in one language and there is support across many mobile devices and operating systems. If somehow the benefit of that cannot be seen I just don't know what else to say about it.


----------



## kpedersen (Oct 6, 2018)

shkhln said:


> That's funny, but actually please don't use plain C as a backend language. Stdlib string handling functions alone are horrifying. For example, It's not at all difficult to find strncmp misuse in FreeBSD sources.



shkhln  Hehe, yes. I might go back and put a bigger disclaimer 

Though the BCHS crowd do have a solution to the unsafe _strncmp_... Yep, they recommend _strlcmp_ instead! lol


----------



## kpedersen (Oct 6, 2018)

wolfspider said:


> .Net is already running in ASM.js it's a project called Blazor has a running demo and everything.


That is pretty much the point I was trying to make. Emscripten has been out for a long time already, large C++ projects such as engines such as Unreal (3 months) and Unity, (1 year) have already been ported, it has taken Blazor many years (3 years?) later to make a port and it is still experimental whereas the others are in a production worthy state. It is because of this sluggishness of porting such a massive codebase that I believe Microsoft is going to be losing interest in .NET technology.



wolfspider said:


> C# is component based while C++ and C



Component based, as in object-orientated? I am not saying that C++ or C vs Java or C# are better languages. In fact I tried hard not to mention languages at all and refer entirely to their underlying platforms, (.NET, native, JVM). This is the crucial part to their success. The actual languages themselves are barely important.



wolfspider said:


> There are a lot of good examples and documentation out there for C# just a ton of examples and videos. You mention Lua- the docs for Lua have become more dense but still pretty minimal. Ok, so I want to cast to a string in Lua and their docs list one "tostring" method and an example- cool!



Again, it isn't how fun or nice the language is to use. I am talking about lifespan. In theory it is possible to make a version of Lua that has a C#-like frontend and the exact same benefits would be seen. The fact of the matter is that the .NET VM and supporting platform is many, *many* lines of code, many of it very platform and architecture specific, whereas the entire Lua VM is about 20 source units of ANSI C. This is why I predict that Lua will outlive VB.NET, C#. C++/clr, IronPython and other .NET based languages.



wolfspider said:


> Unity uses C# one way or another and powers many, many mobile apps like it or not the damage is done and it's still C# so I think trying to say it technically isn't the same design pattern therefore .Net doesn't run on mobile is pre-emptive





wolfspider said:


> .Net Core has AOT as well (CoreRT) and LLVM is showing some good performance starting out with this.



So both of these achieve the same result in very different ways. The first one converts the .NET bytecode (IL) into C++ code which allows Unity to stay quite a bit more portable (It still requires bohems-gc but that is pretty portable these days). Whereas the AOT is basically just a JIT that stores its generated binary. This is less portable and only works on a very limited number of platforms.
So out of these two methods, the Unity one is potentially best but is certainly very tied to their engine and a generic i.e Web app will be very unlikely to work with it directly.
Will Microsoft adopt this approach? If they did, I could see C# living on (not necessarily the .NET Framework, but certainly the C# language itself).

I am not attacking C#, far from it, I would much rather use it than risk the safety issues found in old obsolete C++ or C. However, due to issues with lifespan, I find there is very much a lack of suitable alternatives (Modern C++ is actually pretty good these days and I generally stick with that).


----------



## drhowarddrfine (Oct 6, 2018)

wolfspider said:


> .Net is already running in ASM.js it's a project called Blazor has a running demo and everything.


Like most Microsoft things, the rest of the world has moved on to other things--in this case webasm.



wolfspider said:


> I'm surprised that there isn't more "learn Node.js" in the BSD camp since, when it works, it performs extremely well and JavaScript isn't going anywhere anytime soon it looks like.


Node is a web language based on JavaScript so a discussion of it on an operating system forum is less likely.


----------



## drhowarddrfine (Oct 6, 2018)

wolfspider said:


> This is exactly why C# on FreeBSD would benefit it is because you can keep a codebase in one language and there is support across many mobile devices and operating systems.


Microsoft is dead on mobile. Microsoft products are a kludge on the internet, too. C# and .NET target Windows and Microsoft products. It makes no sense to use such thing for the internet, mobile, or anything cross platform. 

I, too, wonder about learning golang or rust. I spent some time with Go and briefly tinkered with Rust. Go is more important for my web dev company. Rust would be more important for system software but I don't have time for that anymore.


----------



## drhowarddrfine (Oct 6, 2018)

shkhln said:


> please don't use plain C as a backend language.



My company runs two highly performant web sites that you have visited and probably still go to at least occasionally. We continue to do everything in C for four reasons, ignoring the fact that I was a C programmer when I got the contracts.

We can interface to virtually everything without issue.
We can do everything faster.
We can do everything on smaller, cheaper hardware with less need to expand.
We are far, far more flexible.


----------



## kpedersen (Oct 6, 2018)

drhowarddrfine said:


> We can interface to virtually everything without issue.



I agree with all of them but this one in particular is the killer feature!

I like rust (I am even taking the time to learn it because I do think it will still become very relevant in the future) and I am very much liking the fact that people are finally starting to develop native / systems level programming languages / platforms again. However, it cannot interface with C code without wrappers (dreaded bindings!) and a lot of its safety features are lost whilst doing so. This is where Go could potentially win if they were competing.

Direct access to C is crucial and is often overlooked by "normal" developers because they just assume that these nice bindings can be provided to them forever. However in the open-source world (especially *BSD) we realize that we don't get spoonfed "products" by the industry, we often need to do it all ourselves. Bindings take more time to maintain / implement than the project itself haha.

Imagine if C++ could not consume C code directly but instead you had to wrap each function into i.e a CNI_c_fopen(object o) wrapper and do this for every native function you use. Painful! I don't think it would have been nearly as successful.

My one issue with Go is not a technical thing. It is "Google"! Did they really employ the AT&T guys or have they simply kidnapped or blackmailed them?
I cannot imagine Google really gives them the support or research freedom compared to a more ethical company?


----------



## kpedersen (Oct 6, 2018)

drhowarddrfine said:


> We continue to do everything in C for four reasons, ignoring the fact that I was a C programmer when I got the contracts.


This is quite interesting. Is it entirely a i.e CGI architecture where everything is done in the C binary?

Or perhaps it is more like a restful thing where much of the logic is done on Javascript in the client side and only true requests such as database queries ask your C based web API?

I am terrible with web development (I simply cannot make things display properly in every browser unless I use tables and then it just seems to become unmaintainable ).
My main recommendation against using C as a backend is because most web developers are also terrible and not nearly diciplined enough to be able to use C fullstop, let alone a secure public service!

If you can do it and specialise in C then that is really quite cool for a web app because like you mentioned, you have a large amount of benefits!


----------



## drhowarddrfine (Oct 6, 2018)

kpedersen said:


> most web developers are also terrible and not nearly diciplined enough to be able to use C


Absolutely true. Most are only concerned with it showing up in a browser on the web with little to no concern for engineering. Then you have Google, Facebook and others making tools (React, Angular, node) or rules (schema.org, JSON headers) to get around their inadequacies to make up for it while forcing those of us who don't need such things to use them in the interest of SEO.

When almost everyone finds out we do everything in C, they always look at us like we're crazy and give the response: "You're crazy!", "It can't possibly be done!!", "You're reinventing the wheel!!!", "No one does that!!!!", "It's too hard!!!!!" and "Well, for a niche site with no visitors you can do whatever you want." 

For the longest time, we actually had a niche site for one company that slowly grew over time. We really didn't have the resources--or the desire quite frankly--to continue with them so they hired another company to take that from us. They were floored when we told them their whole site ran on a 256MB, 20GB VPS and had three different people call to ask if that was correct.

Another site decided we didn't know what we were doing and were convinced, by others, that one can't handle anything without .NET and other Microsoft things. The devs I know, there, said the staff has tripled, along with the server capacity, with no increase in functionality but a definite increase in fumbling and bumbling. 



kpedersen said:


> Is it entirely a i.e CGI architecture where everything is done in the C binary?


We are transitioning from using nginx, fastcgi and nginx modules to using nghttp2 but also the h2o server. That is a fascinating adventure with much profit!


----------



## drhowarddrfine (Oct 8, 2018)

kpedersen said:


> Oh well. No real loss. It also saves our guys the small bit of effort from removing it from ports again once Microsoft drops .NET entirely.
> I am still 99% sure that .NET Core is just the first stage in Microsoft's product discontinuation strategy for the entire .NET ecosystem.


Published today:
Microsoft to bury .Net Framework


> Notice, I have this information from a credible inside source, and no I won’t tell you who. However, apparently Microsoft has plans to bury .Net Framework as of version 4.8. This means that version 4.8 will be the last update to .Net Framework to ever be released by Microsoft.


----------



## shkhln (Oct 9, 2018)

drhowarddrfine said:


> My company runs two highly performant web sites that you have visited and probably still go to at least occasionally.



That's quite a riddle. I'm aware of only one site matching that definition and it belongs to a certain Russian social network. You can actually look at the snapshot of a part of their stack here.


----------



## wolfspider (Oct 17, 2018)

kpedersen said:


> That is pretty much the point I was trying to make. Emscripten has been out for a long time already, large C++ projects such as engines such as Unreal (3 months) and Unity, (1 year) have already been ported, it has taken Blazor many years (3 years?) later to make a port and it is still experimental whereas the others are in a production worthy state. It is because of this sluggishness of porting such a massive codebase that I believe Microsoft is going to be losing interest in .NET technology.
> 
> 
> 
> ...



Except, I think another big issue here is that it is being used as a build tool in open source software. This is the one role which I think gets ignored frequently. Because of reflection and T4 templates it's become a tool to build software written in other languages. If it gets left out then that software also will not port. Lets say for instance Perl disappeared- would a lot of OSS software build? The C++ equivalent to what it can do in that regard is G-Object introspection which if that was a preferred choice would be a lot more popular. Node.js, being a framework heavily tied to C/C++ due to its integration with POSIX, is already used to build much of the OSS world as it is. If I just wanted pure speed I would cache everything but sites have to be dynamic as well, work with DBs, etc.. I would very much rather interface with OAuth, ADFS, WebSockets, WebPack, or GRPC by connecting to it as the component that it is. "An individual *software component* is a software package, a web service, a web resource, or a module that encapsulates a set of related functions (or data)."  And yes, much of the .Net Framework is being shifted over to .Net Standard. These newer languages are exciting and still they are fumbling with some of the basics much like .Net did in the beginning. I think you hit the nail on the head when it comes to suitable alternatives- that's true it's hard to find one. So you can take the approach of being OS specific or not as I see it, sometimes in that decision compromises are made. The same C or C++ code will not run the same way on every platform if there are so many rewards nowadays for cheating the hardware- especially on mobile. 

I did something different this time and decided to build a FreeBSD system up and put C# on there and take a look at where it is. NuGet has really improved in the IDE and looks like VSCode is running too which is great! I know Electron was not easy to get running but looks like both IDEs are could be in great shape on FreeBSD with the addition of Core and some tweaking. It would be a shame to lose out on all the work that went into getting it all to run in the first place. Live remote debugging looks very possible as well but have not tried it yet. I was surprised how much more functional it is than what I was expecting.


----------



## shkhln (Oct 17, 2018)

wolfspider said:


> Lets say for instance Perl disappeared- would a lot of OSS software build? The C++ equivalent to what it can do in that regard is G-Object introspection which if that was a preferred choice would be a lot more popular.


----------



## drhowarddrfine (Oct 17, 2018)

wolfspider said:


> Except, I think another big issue here is that it is being used as a build tool in open source software.


You mean Windows software and the three things you mention are only editing software for programmers as if no such tool exists on Unix/BSD/Linux now.


----------



## wolfspider (Oct 17, 2018)

drhowarddrfine said:


> You mean Windows software and the three things you mention are only editing software for programmers as if no such tool exists on Unix/BSD/Linux now.



If I meant that I would have said Windows software. Which 3 things specifically do you mean? I don't think I understand how reflection or language services are an editing software. Honestly, I didn't reply to a lot of what was said there because it sounds like your trying to take credit for writing Varnish or something and seems like that's probably not true at all. Oh well, come to a thread about .Net expect people who know it well to point out the inaccuracies in what you are saying- most of it is uninformed FUD. I'm sure bringing back CGI is really going to start taking off 

Seriously though, its these off-the-wall concepts like what I've seen described here that put the stability of FreeBSD at risk. I came here because people were discussing real software that's really about to come out and came across this lunacy. Probably the safest thing to do for newer developers is not listen to the people whom have limited firsthand experience with whatever/however they are bashing technology "X" right now. 



shkhln said:


> That's quite a riddle. I'm aware of only one site matching that definition and it belongs to a certain Russian social network. You can actually look at the snapshot of a part of their stack here.



Says GPLv2 is assumed??  Sorry- no thanks for obvious reasons. You come on this forum trying to advocate for some copyleft software- I do not sign ANYTHING when I install C# nor do I agree to the GPL2. Just PHP in general?  not interested and haven't been for many years since PECL dumped all their bins out of the blue one day. I'd rather not be tied to FaceBook or what they want to do and probably right now is the worst possible moment. 

So- when you have some real stats, licensing agreement, and not just copying the startup world let me know and maybe I'll give it an honest look in comparison to C# so far the strategy of being so derivative you may as well just be a clone is what I see here.


----------



## yuripv (Oct 17, 2018)

shkhln said:


> That's funny, but actually please don't use plain C as a backend language. Stdlib string handling functions alone are horrifying. For example, It's not at all difficult to find strncmp misuse in FreeBSD sources.



I wonder why do you define it as misuse?


----------



## shkhln (Oct 17, 2018)

yuripv said:


> I wonder why do you define it as misuse?



_strncmp(val_str, "TRUE", strlen("TRUE")) == 0_ idiom matches _any_ string starting with TRUE, which doesn't look intentional there.


----------



## yuripv (Oct 17, 2018)

It's used in read_ibdiag_config() below on tokenized input from config file, and it's intentional, especially for same strncmp() calls on 'name' part where you obviously don't have terminating NUL and need to compare only the bytes that are meaningful for current token check.


----------



## shkhln (Oct 17, 2018)

yuripv said:


> It's used in read_ibdiag_config() below on tokenized input from config file, and it's intentional, especially for same strncmp() calls on 'name' part where you obviously don't have terminating NUL and need to compare only the bytes that are meaningful for current token check.



Are you saying it wouldn't match more things than "TRUE" or just that it doesn't matter in that context? (It really doesn't, if that were a serious bug it would be fixed already.)


----------



## drhowarddrfine (Oct 17, 2018)

wolfspider said:


> Oh well, come to a thread about .Net expect people who know it well to point out the inaccuracies in what you are saying- most of it is uninformed FUD.


I may have too quickly responded to your post, and I am still only giving a quick response, but any time someone advocates using .NET on FreeBSD--or Linux for that matter--it is often forgotten that .NET, and all its associated software, has the main goal of working with Microsoft and Windows software. People forget or ignore that and dutifully concern themselves with learning these non-native tools because Microsoft, the internet, and reddit told them to--and no other reason--thus inflicting wounds on themselves and ignoring all the built-ins available on their own machine. I suffered these wounds at the hands of Microsoft 15 years ago and will never forgive or forget.

If this is not what your post is about, then sorry, today is exhausting.



> Seriously though, its these off-the-wall concepts like what I've seen described here that put the stability of FreeBSD at risk.


FreeBSD has no issues with stability. Unlike Microsoft and their products which are a quagmire of instability.


----------



## yuripv (Oct 18, 2018)

shkhln said:


> Are you saying it wouldn't match more things than "TRUE" or just that it doesn't matter in that context? (It really doesn't, if that were a serious bug it would be fixed already.)



So I was re-reading the code, and given that strtok() replaces separators with NUL, there's really no reason to use strncmp(), it seems.


----------



## shkhln (Oct 18, 2018)

yuripv said:


> given that strtok() replaces separators with NUL, there's really no reason to use strncmp(), it seems.



If you say so... I don't really write C code, so I don't have any specific opinion here. I also don't care whether it was programmer's error or intentionally sloppy code, the point is that C isn't a particularly good fit for ad hoc string manipulation.


----------



## drhowarddrfine (Oct 18, 2018)

shkhln said:


> the point is that C isn't a particularly good fit for ad hoc string manipulation.


I don't know what you mean by that but anything any language can do with strings, C can do better, though not as easily in some cases, unless you have functions for those things. But you only write those functions once. C has no issues manipulating strings.


----------



## wolfspider (Oct 20, 2018)

drhowarddrfine said:


> I may have too quickly responded to your post, and I am still only giving a quick response, but any time someone advocates using .NET on FreeBSD--or Linux for that matter--it is often forgotten that .NET, and all its associated software, has the main goal of working with Microsoft and Windows software. People forget or ignore that and dutifully concern themselves with learning these non-native tools because Microsoft, the internet, and reddit told them to--and no other reason--thus inflicting wounds on themselves and ignoring all the built-ins available on their own machine. I suffered these wounds at the hands of Microsoft 15 years ago and will never forgive or forget.
> 
> If this is not what your post is about, then sorry, today is exhausting.
> 
> ...



Understood. Yeah it's interesting how on one end I had the same thing happen with PHP and your motivation is a similar experience and that I can totally understand! Certainly I'm not going to say Microsoft is the ideal situation itself however they are *trying* as-in I can actually go to them about FreeBSD in particular and they attempt to do something as-in patch things in CoreCLR specific for the BSD kernel. Really, there are a lot of places in the CoreCLR source where if they used less MacOS specific code and just stuck with the BSD code on Darwin it wouldn't be such a monumental effort to port it in the first place- just due to how much time has passed. I've been developing SharePoint custom solutions for quite some time now (for the government) and in no way will I say until recently they've been on the right path. To top that off I have known devs that did some time in Redmond that explain some of the situations they get in. I tend to agree with their sentiment they are too large and disorganized to be "evil" as they once were to OSS. 

I think election season this year has me feeling especially rabid I don't consider us even a worthwhile target (not associated with DoD or anything) but still the door knob rattling around the clock is insane. Just imagine DDoS attempts originating from your A/C control systems- it's crazy! Anyhow, I still love developing on FreeBSD to this day and hope that as a development platform it continues to grow in that regard whichever language anyone chooses to code with. I read through a long discussion on HN recently and seems like there is a younger generation looking to upend just OOP altogether so things are definitely starting to get interesting.


----------



## unitrunker (Oct 21, 2018)

This thread has gone off the rails - but I'm not complaining. Great comments by all. .NET Core (or "Standard") sheds much of the windows dependencies that tie .NET Framework to Windows. That ejects all the GUI bits that server apps don't need. 

Linux is a great alternative to Windows for running .NET Core apps. Maintaining .NET Core on FreeBSD ensures that Linux is not the only alternative OS to Windows for Core apps. If a few companies adopt FreeBSD because of this - even better.


----------



## kpedersen (Oct 21, 2018)

unitrunker said:


> If a few companies adopt FreeBSD because of this - even better.



Agreed. If this additional flexibility allows some innovative companies to step outside the Microsoft square and to an OS platform that better fits their needs, then I am of course glad that Mono (in particular) exists.
I am just hoping that it of course wont drag some more naive companies away from i.e Linux and into the Microsoft prison because they have tied themselves too closely to .NET by bad decisions (and Microsoft's EEE strategy).


----------



## drhowarddrfine (Oct 21, 2018)

kpedersen said:


> I am just hoping that it of course wont drag some more naive companies away from i.e Linux and into the Microsoft prison because they have tied themselves too closely to .NET by bad decisions (and Microsoft's EEE strategy).


I am positive this is a Microsoft strategy. I am positive it is happening because I see Linux people on amateur forums--specifically reddit--who laud over Microsoft as if they are the savior of Linux. 

Not that I think professionals, overall, visit reddit on a regular basis but the reddit script kiddies sometimes influence their elders.


----------



## kpedersen (Oct 21, 2018)

drhowarddrfine said:


> the reddit script kiddies sometimes influence their elders.


Yep, if these companies need cheap labor and Microsoft is all these kids know then it will be like 2010 all over again


----------



## justinnoor (Dec 30, 2018)

drhowarddrfine said:


> My company runs two highly performant web sites that you have visited and probably still go to at least occasionally. We continue to do everything in C



I realize this party is over but this is really interesting. All C or C++ web applications are fascinating. I’m currently trying to figure out Beast, which is a header only library, not a framework. It’s not going very well. I haven’t done much web development. Nginx is extremely user friendly, though.

Just curious do you guys use any JavaScript at all in your websites?


----------



## kpedersen (Dec 30, 2018)

justinnoor said:


> I realize this party is over but this is really interesting. All C or C++ web applications are fascinating. I’m currently trying to figure out Beast, which is a header only library, not a framework. It’s not going very well. I haven’t done much web development. Nginx is extremely user friendly, though.
> 
> Just curious do you guys use any JavaScript at all in your websites?


Beast looks interesting but because it is tied up and stuck inside the murky swamp known as Boost, I will never touch it 

A C++ web development architecture that a colleague of mine is showing great results with is using mongoose (https://github.com/cesanta/mongoose) as a combined http and websocket server (single .c and .h file; much less tightly bound than boost::Beast).

His C++ server does very little more than host the html / Javascript files, and then provides a simple RESTful API using both AJAX and Websockets. It is extremely fast and doesn't require any dependencies on a big fat server like Apache. In general though, the majority of the web app is powered by the Javascript running on the client's machine. Better distribution of resources.

I have used Mongoose with many of my projects but only for websockets. I cannot accept CSS as a GUI library so have tended to shy away from full blown web development . I find it really good. Especially the older version which is multi threaded. My only complaint is that it deletes client connections at will and functions via callbacks making it very hard to wrap in safer languages such as C++ or Lua.


----------



## drhowarddrfine (Dec 30, 2018)

justinnoor said:


> Just curious do you guys use any JavaScript at all in your websites?


Well, of course. You have to for client side manipulation. For some of our smaller sites, they use credit card processors and the only way to use their service is through javascript on both the server and client. They have no other way to do so except other scripting languages.


----------



## justinnoor (Dec 30, 2018)

kpedersen said:


> the murky swamp known as Boost, I will never touch it



Boost can definitely get murky hah. So many different versions, “missing this library”, “missing that library”, etc. Apparently one of the key ingredients behind Beast is its core dependency Asio, the async library based on the proactor design pattern (concurrency without threads). Supposedly it can handle a ridiculous amount of connections, if I can ever make it work! Maybe in another lifetime.

Mongoose looks pretty nice. Thanks for the heads up. I’ll try it out.


----------



## kpedersen (Dec 30, 2018)

Yes! Asio is such a terrible dependency to have. When looking for any decent networking related libraries, I always see the C++ ones have sodding Asio as a dependency or overly utilize some C++20-only standard async architecture that will never work on older or C++ compilers 25 years from now.

I even decided to write my own (https://github.com/osen/libws) just to avoid Asio in a couple of projects haha.

I stopped looking for C++ libraries long ago and decided to just find C99 ones and polish them up a little for safety and C++.


----------



## justinnoor (Dec 31, 2018)

kpedersen said:


> I even decided to write my own (https://github.com/osen/libws) just to avoid Asio in a couple of projects haha



Very impressive. Work project?


----------



## kpedersen (Dec 31, 2018)

justinnoor said:


> Very impressive. Work project?


Thanks 
Originally written as part of a contracting job but I then decided to clean it up and add Windows support.
One day I plan to turn it into this (http://websocketd.com/) but without the non-futureproof choice of Google Go as a language.

A word of warning: Mongoose is better in most ways. Mine is not entirely standards compliant (especially in the standard HTTP). It also supports only plain text websocket streams, not binary.


----------



## reddy (Jan 2, 2019)

I think most of the issues raised regarding the sustainability of the .net stack (namely porting to new platforms), have been solved by Mono.

Mono has no such issues to port mono to new platforms. They are even already able to target web assembly (even though this is still a work in progress). Mono even supports llvm. So with the open-sourcing of the .net framework and the way Mono has been integrating Microsoft's code where it makes sense, I see no downside to using .NET (as long as one uses the Mono implementation - .net is a standard that anyone is free to implement).

Moreover, thanks to language services such as omnisharp, one can now conveniently use emacs to develop. This brings intelliense, autocompletion, refactoring and the like straight to emacs without any vendor lockin/creepy licensing.

To me, besides the features of csharp, a key reason to use .net/mono for a business is its vast standard library and plugins ecosystem. Things such as the extensive network, text, and regex libraries all the way to linq make a huge difference in developer time.

Another key reason that shouldn't be overlooked are build times. Builds are incremental, but are also fast to the point that building after every file change often is a workflow (while it is not even an option in c++). You can work on multi-million lines projects and build in 5 seconds or so. All of this combined makes for a real productivity booster.

FreeBSD + Mono + Emacs/Omnisharp constitute a great technological stack that I think has a brillant future. Mono isn't some sort of poor child, it is a great engineering work having a very interesting architecture.

I personally prefer to spawn two more instances if it can maximize productivity and save me from spawning two extra technological stacks. This makes a lot of difference when it comes to growing a business. One can always rewrite for high-performance down the line when clients are closed and money is in the bank, if there is ever a bottleneck.

I am obviously not advocating for rewriting parts of FreeBSD using .net, I am only saying that it adds plenty of value in the community. The existence of a credible  mono port in the ports tree largely motivated my decision to choose FreeBSD. 

Once this is said, I do not think this community should spend too much efforts trying to dance .net core tango until Microsoft gets its act together. I personally do not plan to use it in the foreseeable future because .net core looks too much like .net framework 1 at the minute. It looks like the old-days microsoft abominations, with poor documentation, non-stable APIs etc... it may take an additional decade before it really becomes a credible alternative in the Unix world. For time being, mono fits the bill, and probably always will considering its far ranging support for platforms (including web assembly, the future of client programming on the web), while Microsoft made clear that .net core focus will be the web server scenario. So time invested on mono is time well invested.

 The performance hit between mono and core is not so terrible and is not even important for the vast majority of people. And if someone is really serious about performance, he can always tweak and optimize mono compile options. However optimizing compile options and building from source is not a mindset commonly found in the windows world which help explain the general feeling. Few people probably know that it is even possible to change the garbage collector algorithm used by mono or write a drop-in replacement (GC being one of the main bottleneck in vm-based languages).


----------



## kpedersen (Jan 2, 2019)

reddy said:


> Builds are incremental, but are also fast to the point that building after every file change often is a workflow (while it is not even an option in c++). You can work on multi-million lines projects and build in 5 seconds or so. All of this combined makes for a real productivity booster.



Building after a file changing in C++ is actually more efficient than in .NET. In .NET, you have to compile and generate the entire assembly (and then generate the binary) whereas in C++ the compiler is instructed to just compile the units that changed and then relink. If you correctly forward declare in headers, then this has never really been a problem.

For tiny projects or non-native compiles, .NET can be faster to generate bytecode but for larger projects compiled to run on bare metal, the build design of C++ greatly wins out.

That said, C++ and .NET have never really competed. .NET has always just piggybacked and consumed C++ binaries via the use of (often out of date) bindings. Java and .NET are the main competitors to one another and whilst I trust Java more (yes, even with Oracle at the wheel), I do see that .NET has more technical merit; especially when it comes to stack / boxed functionality.

Its deprecated now (like all things Microsoft) but a closer competitor would be Microsoft C++/clr:safe and C#. I wish Microsoft had open-sourced that compiler rather than just take it to the grave with them. Bunch of arses


----------



## Bobi B. (Jan 2, 2019)

Frankly the one thing I hate most in C# is, that it changes way too often. The second one is some fundamental classes and interfaces they dropped in .Net Core (`IDataReader` and `DataTable` no more? Really?!?)


----------



## reddy (Jan 2, 2019)

kpedersen said:


> Building after a file changing in C++ is actually more efficient than in .NET. In .NET, you have to compile and generate the entire assembly (and then generate the binary) whereas in C++ the compiler is instructed to just compile the units that changed and then relink. If you correctly forward declare in headers, then this has never really been a problem.
> 
> For tiny projects or non-native compiles, .NET can be faster to generate bytecode but for larger projects compiled to run on bare metal, the build design of C++ greatly wins out.
> 
> ...



I was actually talking about non-native compiles (I am not saying this to reject your whole comment, this is just a remark). 

I don't know, it looked like people were saying that low-level non-interpreted languages (specifically c/c++) should preferably be favored over c# in the unix world, so I wanted to offer a different view. 



Bobi B. said:


> Frankly the one thing I hate most in C# is, that it changes way too often. The second one is some fundamental classes and interfaces they dropped in .Net Core (`IDataReader` and `DataTable` no more? Really?!?)



Honestly this is not my experience, the language evolves but is always 100% backward compatible. If they allowed themselves to break backward compatibility, the first thing they would have done is making null references impossible, which what they often say is their biggest regret which is too late to fix due to backward compatibility. This is where Microsoft is very different than say Google who does not hesitate to break things and discontinue products abruptly.

The second problem you mention relates to the standard library and not csharp per se. .NET ECMA 335 is a technical standard defining how code written in multiple high-level languages can be run in a single VM able to be executed on multiple platforms. C# is only one of these languages among dozens (F#, IronPython etc...) which is a little known fact. The .NET Framework implements the specification, and so do Mono and .Net Core.

These 3 frameworks are 3 different implementations of ECMA 335 and as such come with different standard libraries. To provide API compatibility, the so-called ".NET Standard" defines an API that the standard library of all implementations must implement. Mono always aimed to be API-compatible, but Microsoft formalized things with .NET Standard when they intensified their efforts on .NET Core. This API definition should have existed a long time ago but back in the days Microsoft didn't care about cross-platform (unless it was to sabotage it).

Unfortunately, the data access classes you mention are not part of .NET Standard, and therefore are not required to be implemented by ECMA 335 implementations, and as such Microsoft has decided not implement them in .NET Core for time being. They may be present in Mono though, I am not sure. But the point is, this is not a C# issue.

If you ask me, I personally find ECMA 335 (and the .NET ecosystem it defines) a masterpiece of software architecture and reviewing it is what convinced me that this stack was the future. I find it impressive that they were so spot on, so early (2001). The open-sourcing of the Microsoft's windows-focused implementation proved me right. So does seeing Mono target Web Assembly. But one can only regret that Microsoft waited so long to implement a vision that they had long laid down.

Once this is said, what you are saying about DataTable is exactly the reason I stay away from the .NET Core implementation for time being and only care about Mono (which has superior and more mature tooling in addition to having a much more comprehensove standard library). Right now, there are way too many easter eggs like this one in .NET Core. The only point I am trying to make is that the ecosystem goes far beyond .net core and it is important to understand the big picture because there is in my opinion huge business value in this ecosystem, whether it is in terms of time-to-market, productivity and maintainability. And today, you no longer need to sell your soul yo the devil through obscure licensing to benefit from it.

I think that FreeBSD will see a lot of people coming from the Windows world in the next decade. These people will want to enjoy their new freedom in an OS being no less consistent than the Windows they were used to. Right now we are in a transition period, people do not fully realize yet the vast extent to which their possibilities have changed.


----------



## drhowarddrfine (Jan 3, 2019)

Bobi B. said:


> Frankly the one thing I hate most in C# is, that it changes way too often.


Under the guidance of a relative, who is manager of a large Microsoft shop in Houston, I started my company using all Microsoft .NET stuff for which he got us a lot of software for free under the table. We built a complete system that was ready to launch when...something changed. It all came tumbling down. Microsoft didn't support that anymore and we were to upgrade and re-learn parts we just finished learning and weren't sure we were good at. "Switch to Linux!", my relative told us. Thanks so much.

We lost $50K in funds as we had to rewrite a lot of code and it almost sunk us. We knew Linux wasn't for us the first few days we looked into it. I pulled some old floppies out for a FreeBSD install and you know the story from there.

I will never touch a Microsoft product as long as I can help it.


----------



## reddy (Jan 3, 2019)

Honestly, I won't even try to argue that you can't be burned by Microsoft. You definitely can, and it's too easy to be, even today. I think ECMA 335 and Mono (and maybe .net core 15 years from now) are the exception rather than the rule. I wouldn't even put my money on .net core right now.

I do not touch any Microsoft-related tech apart from that. That would have been quite a huge baby to throw with the water. But even with Mono you need to be wise about which library you want to depend on since they are resource limited. 99% of the time this means thinking twice before using the Microsoft frameworks (such as Winforms) they have ported.

 it's possible not to be burnt by studying Microsoft's trajectory / internal politics / where they are going. Just like you would before using any open-source project. But this needs to be done even more carefully with them, especially back in the days when .net was closed-source. Most of their stuff are still closed-source today.

For example we stopped using SQL Server long ago. We use mono with open-source libraries or build our own. No ASP.NET, ASP.NET MVC, Webforms, WCF, WPF etc... we don't touch any of that. This is a huge BUT that I should probably have added before. All we are interested in is mono implementation of ECMA 335 and the high-level languages of the ecosystem (csharp, fsharp, etc...). For the rest beware. Business is business... you'd better know Microsoft well before adding their libraries/product as a dependency.

We have long decided that being a Microsoft shop wasn't a good idea. However, ECMA 335 is a good idea.  that's the positive I take from our involvement with Microsoft. It may take focusing hard not to throw it with the rest but this is a real deal. I briefly highlighted some technical merits, but there are also business considerations such as access to a huge talent pool etc...


----------



## drhowarddrfine (Jan 3, 2019)

Any technology or company we have to tip toe around is not one I will get involved with. My company turned down work if it ever involved us having to touch Microsoft anything. If MS products were involved, the client had to deal with it and hand us a POSIX compatible environment or interface we approve of. 
Running Mono on UNIX/BSD/Linux is like trying to force fit round pegs into square holes. To this day, I will never understand why professional software is written for and runs on a consumer product like Windows.


----------



## kpedersen (Jan 3, 2019)

reddy said:


> I don't know, it looked like people were saying that low-level non-interpreted languages (specifically c/c++) should preferably be favored over c# in the unix world, so I wanted to offer a different view.



The main benefit Limbo, Java, .NET have that I can completely accept and understand is that they can provide (non-realtime) safety in terms of memory because everything is checked. Perfect for a business usecase because it opens you up to faster deployment and (hate to say it) cheaper programmers because they don't need to be so darn experienced or skilled.

However, In the world of UNIX and Linux, FOSS / open-source (which lets face it... powers UNIX these days), it isn't so much about money. There is no real time or financial pressure. Especially since FOSS developers do a lot of it for fun and recognition the benefits (safety / speed / cheapness) do not actually apply to 99% of open-source projects which make up FOSS. So if you aren't using .NET for these reasons, what other benefit are you using it for? Fun? Doubt it. They are so darn safe that they are boring languages to write software in. Especially since most of your time will be spent making / fixing bindings for native C libraries.

Then you have the other part of FOSS where because it is a hobby, we want to do stuff right! Unlike in our day jobs, we don't just wan't to blitz out crap or stuff that could potentially break in a few years (if Java 1.6 or Mono 1.x is removed from common repos for example). We are quite happy to use a "harder" language because it isn't always about us (the developer), it is about our users and how our software integrates with their workflow. Having to download a massive JVM or CLR just to run our code is quite a disadvantage. This I feel is why the majority of Linux binaries are C/C++ and libraries are still C (not even C++). God, some users bitch about having to install both Qt *and* Gtk. Or Python 2.7 *and* Python 3.x. Those are tiny things compared to Inferno, JVM, CLR.

As it stands C++ is still demonized in the UNIX world (for quite a few good reasons). However, one day if C++ finally overtakes C... then perhaps another 25 years later, Java or .NET might have a chance. If they (or we) are still alive by then


----------



## Vull (Jan 3, 2019)

> it's possible not to be burnt by studying Microsoft's trajectory / internal politics / where they are going.


Not for me, because I'm too naive I guess, and because, y'know, they lie, keep secrets, and play dirty. I'm like Elmer Fudd vs. Bugs Bunny when it comes to anticipating their next moves. They have much more time and resources for planning their next duplicity than I have for anticipating it, so IMO it's better if I don't even try.


----------



## drhowarddrfine (Jan 4, 2019)

Vull said:


> I'm like Elmer Fudd vs. Bugs Bunny when it comes to anticipating their next moves.


Yeah. Don't be a dragon. Dragons is soooo stupid.


----------



## unitrunker (Sep 14, 2019)

FYI - the build steps at the start of this thread no longer work. Microsoft pulled the pre-built FreeBSD SDK binary required for their build script to run. Anyone pursuing this should seriously consider Mono instead.


----------



## drhowarddrfine (Sep 14, 2019)

And then they'll pull the FreeBSD version of Mono somehow. Then Docker will become a paid version since it's company created and sponsored.


----------



## unitrunker (Sep 14, 2019)

drhowarddrfine said:


> And then they'll pull the FreeBSD version of Mono somehow.


The technical issue is - the core-sdk is written in C#. You need to compile the SDK to get a working toolchain. You need a toolchain to get a working SDK. Chicken and egg. You have to cross-compile from Windows or Linux (with FreeBSD tweaks) to start.

It's a bit like building clang or GCC from source - without a working C compiler.

I suspect it is comically plausible that one could use mono to boot-strap core-sdk.


----------



## reddy (Sep 15, 2019)

I'd strongly recommend using mono for the foreseeable future rather than .NET Core. Mono will not go anywhere, it's been around forever now, and is stable and has very mature tooling. And it is the backbone of plenty of things at MS (Xamarin, Android and IOs compatibility etc...) so there is a permanent commitment to it. It is like the .NET framework at this point, it can't go away.

In terms of memory footprint, mono may be less optimized than .NET Core out of the box, but let us remember that the fundamentals of the VM are the same because they both implement the same specification : if you do not touch an AppDomain, it does not get loaded in memory. And if the VM is still too heavy for you, if you are truly at the scale where every megabyte matters (unlikely unless you are operating at a huge scale, of have aggressive hardware constraints), it  likely won't be a big deal for you to tweak mono's compiler options to trim it and optimize it as much as you need.

The memory footprint of the VM of an headless web application on mono is about 60MB to 200MB, most applications would use about 100MB (putting aside load and the specific performance profile and resource usage efficiency of the application). This is negligible most of the time, unless you plan to run on an embedded device having 256mb of ram installed, in which case you'll still be able to play with mono's compiler options. And I am not the type of person considering that running an electron-based text editor using 2GB of RAM is always reasonable.

I bet .NET Core has been optimized for web scenarios to take the number closer to the one of a LAMP stack (even though this is comparing apples to oranges, since .NET/Mono give more isolation and features to every application - you can import DLLs, and do all sort of things in a secure context, so this necessary involves resource usage duplication where on a LAMP stack everything uses the same PHP instance. This is without even mentioning the sandboxing that .NET provides you - for example I'd never expose my filesystem straight to the web - I'm always shocked to see how much of a direct access to the file system PHP apps use and the tweakings with .htaccess files, scary...).

LAMP can run multiple websites by using well under 100MB of memory largely thanks to the fact that everything uses the same PHP instance and lazy execution. But you pay the price at execution time with much slower execution. But if you are hosting 1000 websites and 99% of them get less than 1000 hits per day, then these maths are arguably very advantageous. The right tool for the right job.

For if you are the marketing department of a company having 3000 websites (blogs, review websites,  and all sort of content marketing schemes) to promote a range of specific products using an in-house methodology, then if you are sophisticated, these 3000 websites will likely be powered by a single application, having an integrated dashboard for content editors, and a transparent engine adding styling and graphics assets, and content modules, based on the entity being served (every website would be represented as a well-thought-out entity in your domain model). Then you would for example put a reverse proxy in front of your application to transparently map "marketingdomain1.com" to your backend "http://localhost:<port-to-your-app>/marketing-schemes/entity-name-for-domain-1/" and you have your 3000 websites powered by a single application using 60-200MB of RAM memory.

And the maths work here too. And the thing is, in addition to the huge security benefits coming for free, and to the huge performance benefits at execution time, .NET/Mono and their family of languages (csharp, fsharp etc...) make it very convenient to create and maintain such complex domain models. The experience of creating a complex, yet scalable and maintainable domain model in .NET and seamlessly integrating it with the infrastructure code, while having access to a broad range of expressive languages (csharp, fsharp, but much more), and a wealth of open-source packages for your infrastructure, this experience is quite honestly seamless. Once you have experienced that, you can't fiddle with Python and PHP if you are serious about your business. And I am not talking about Microsoft toolings (which we do not use anyway), I am talking about core concepts and the core features of the languages, and of the ecosystem and of the way everything plays together to foster productivity, quality and shareholder value in an optimal way.

So honestly it really depends of what you are doing, and whether or not you know what you are doing... And to be honest, most .NET shops wouldn't be able to pull out the technological scheme I have described. They need the click-click-click hand holding of Microsoft's tools to ship anything. And I am just talking about infrastructure code here, I am not even talking about the fact that very few teams even know what a domain model is... they know about POCOs.... and glue.... and spaghetti.... and mapping and ETL-ing stuff all over the place.

So it really comes down to what you are doing, and whether or not you know what you are doing. And what I am saying is that in many - if not most situations - if you are a company only deploying your own products,  ECMA 335 is quite a huge baby to throw with the water... You're missing on a lot of value if you dismiss it or do not know about it (which most people do, especially in the UNIX community - but for legitimate historical reasons, but times have changed), and you're probably paying a premium without even realizing it, as you'll have to constantly re-implement here and there many complex and expensive stuff coming for free with ECMA 335 (in addition to introducing codebase complexity, less expressive programming languages etc...).

And once all of this is said.... I just saw a one-year old question on stackoverflow of someone saying that their small  .NET Core application (20 pages or so, this was actually a headless JSON-API....) was using 350MB of RAM.... So bottom line is, honestly, nowadays there is not even a practical need for .NET Core if you know what you are doing.

Old is not always true forever. Change is not always meaningful or positive, but sometimes it is. And new is not always better. For those of us able to take advantage on Mono on Unix, .NET Core is a solution to a problem faced by Microsoft more than it is a solution for us, since there is no actual need in this area. However, we indirectly benefit since they significantly scaled their investment in open-source because of this program. For example, they multiplied the headcount of developers working on Mono while keeping everything open-source, they even open-sourced the proprietary division that allowed Mono to make money. They also open-sourced the .NET framework, MSBuild, all their compilers, and all sorts of things, so the Mono team has been able to do things such as swapping less performant code for code developed by the 6-figure-salary full-time PhDs paid by Microsoft where it made sense.


----------



## drhowarddrfine (Sep 15, 2019)

unitrunker said:


> The technical issue is - the core-sdk is written in C#. You need to compile the SDK to get a working toolchain. You need a toolchain to get a working SDK. Chicken and egg. You have to cross-compile from Windows or Linux (with FreeBSD tweaks) to start.
> 
> It's a bit like building clang or GCC from source - without a working C compiler.


Which exemplifies why I always say people should never use this stuff. It will always be fitting square pegs into round holes. FreeBSD has their own tools that are just as good or better.


----------



## kpedersen (Sep 15, 2019)

reddy said:


> They also open-sourced the .NET framework, MSBuild, all their compilers, and all sorts of things, so the Mono team has been able to do things such as swapping less performant code for code developed by the 6-figure-salary full-time PhDs paid by Microsoft where it made sense.



This made me chuckle. Often code from PhDs isn't always the best for long-term viability. Just check out the garbage collector alone from clr (https://raw.githubusercontent.com/dotnet/coreclr/master/src/gc/gc.cpp)
This sheer volume of over-engineered code is not really maintainable (this alone is bigger than the entirety of TCC: https://github.com/TinyCC/tinycc) and they certainly haven't followed KISS principles.
For an exercise; try getting Mono 1.0 building and running on a current platform. It will take you over a lifetime of manhours to do it. I stay away from "technology" like this.

Compare it to C where it is possible to write a compiler in about a week. Someone much smarter than me could probably even make it production ready in that time.

Even though I mentioned language names; it is the underlying platforms that I am really talking about. VB.NET and CSharp are probably fine languages but until they can drop the runtime complexity; I wouldn't recommend them. But again, that is typical of PhDs, the ideas are often valid but the execution and implementation is often atrocious (this is certainly the case for my thesis). If they can find a better (more portable) solution than a garbage collector and develop a compiler that outputs native binary from CSharp code (similar to dotgnu, unfortunately not what AOT does) then I see CSharp having a much longer life. Oh and just drop VB.NET and give us back VB[6]; it was vastly superior!


----------



## reddy (Sep 15, 2019)

kpedersen said:


> This made me chuckle. Often code from PhDs isn't always the best for long-term viability. Just check out the garbage collector alone from clr (https://raw.githubusercontent.com/dotnet/coreclr/master/src/gc/gc.cpp)
> This sheer volume of over-engineered code is not really maintainable (this alone is bigger than the entirety of TCC: https://github.com/TinyCC/tinycc) and they certainly haven't followed KISS principles.
> For an exercise; try getting Mono 1.0 building and running on a current platform. It will take you over a lifetime of manhours to do it. I stay away from "technology" like this.
> 
> ...



I do not disagree with the underlying point you are making. But I also think that at some point, you always have to make a decision on someone smarter than you that you are going to trust. Even if you insist on keeping the bar low in terms of expertise required, at some point the sheer volume of man-hours required will turn everything into a black box for all practical purposes. So whether the black box exists because the knowledge required is so complex or specialized that you would not be able to re-implement it, or because there would be so much work to do to modify a toolchain/framework/environment that you wouldn't ever realistically have the budget for that, from a practical perspective this makes no difference, it is the same black box. So it all depends of where you arbitrarily decide to set the bar. It all depends of your risk model (which depends of your specific situation - skills, comfort zone, budget etc...).

Personally (after of course doing a risk analysis and triangulating the sanity and opportunity of investing in something both at a technological and at a strategic level), I generally speaking do not mind trusting PhDs to implement very abstract things based on sane concepts. It is usually something they do very well, and because abstract things are a common denominator, there will always be plenty of pairs of eyes and plenty of smart people enjoying optimizing these abstract problems. So I would not worry about the effort required to re-implement the VM, the compiler or such, especially since there is no reason I'd ever need to do so since I have the source code so I could keep using the same version for decades (putting aside the fact that it is unlikely there will ever be a shortage of maintainers).

Also to nitpick a little on your example, I strongly doubt that they'd over-engineer their garbage collector, this is quite a central piece of the whole thing, they are throwing a lot of resoures to extract every performance improvement possible, and I suspect this is why this file is so large as - reading their blog posts - they do not mind handling particular cases if it can makes things 5% faster. Garbage Collection, VM, and the compilers are exactly what I trust them to do best, for these are complex problems, but abstract and well understood problems. Then comes the core library, but as far as application frameworks like WCF etc... not really....

Regarding the garbage collector, they need to support plenty of use cases and customers. And a garbage collector is a very different beast than a compiler. A garbage collector is a complex optimization problem, and when we say optimize, there is the notion of "optimize for what?" (so various types of load to plan for), and how to optimize (various collecting algorithms / approaches to support - Mono even supports replacing the algorithm). So this is quite a file for sure, but this is also quite a complex challenge even on paper. And garbage collection introduces quite a lot of business value and features, it gives a lot of things for free to the developer. But whether or not (or when) runtimes relying on garbage collection are desirable is another question.


----------



## kpedersen (Sep 15, 2019)

reddy said:


> Regarding the garbage collector, they need to support plenty of use cases and customers. And a garbage collector is a very different beast than a compiler. A garbage collector is a complex optimization problem, and when we say optimize, there is the notion of "optimize for what?" (so various types of load to plan for), and how to optimize (various collecting algorithms / approaches to support - Mono even supports replacing the algorithm).



This is one of the exact reasons I prefer a technology to stay away from garbage collectors; they are too complex to support a number of customers use cases whilst remaining sane, elegant and portable. That said; I could rant about garbage collection for longer than I should. I note that the (default) Mono GC (based on Boehm's) is much lighter. This agrees with your suggestion to stick with Mono. 








						mono/boehm-gc.c at main · mono/mono
					

Mono open source ECMA CLI, C# and .NET implementation. - mono/boehm-gc.c at main · mono/mono




					github.com
				




I do try to avoid technology that I don't understand or cannot maintain myself but yes sometimes I do have to rely on stuff magically fabricated by smarter people. However for a programming language where if I can keep things simple I can understand pretty much the entire stack; in this case I don't see much of a reason to go with the black box when given the choice.

Professionally, within reason, I will use whatever technology gets me the most success (But not Unity or anything else involving DRM). I have worked with Mono in the past; it certainly isn't the worst XD.


----------



## drhowarddrfine (Sep 16, 2019)

kpedersen said:


> I do try to avoid technology that I don't understand or cannot maintain myself


Decades ago, when I was learning FreeBSD and programming with C, I was complaining online about a standard library string function that didn't do exactly what I wanted. "Well, why don't you roll your own? Just look at the source, copy and modify it," said one well known veteran. That changed my whole outlook on programming.


----------



## ekingston (Sep 16, 2019)

reddy said:


> I'd strongly recommend using mono for the foreseeable future rather than .NET Core.



Unfortunately, a lot of developers are switching to .NET Core and away from mono. Without .NET Core support these applications become unusable. On that could affect me:


Plex is a media server. It started life as mostly open source but switched to an open/closed hybrid (part of it is open source but key components are closed). My reasons for looking at alternative to Plex go beyond this thread.
When Plex went partial closed, the open-source parts were copied into a new project, EMBY. It too has gone partially closed-source.
But a new project popped up that took the last of the open EMBY and made Jellyfin. The folks behind Jellyfin re-built the core in .NET Core (instead of Mono). The result is that of the three, I can't get Jellyfin to run on FreeBSD.
It won't be the only application with this type of issue. Mono may not be going away any time soon, but if you pay attention to the .NET community, there is a definite push to move all future work to .NET Core.

Plex has an interest in maintaining some level of compatibility with FreeBSD as long as there are NAS options like FreeNAS and they want to target that as an option. The other two don't have the same interests at the moment.


----------



## kpedersen (Sep 16, 2019)

ekingston said:


> a lot of developers are switching to .NET Core and away from mono. Without .NET Core support these applications become unusable.



This provides some pretty good evidence that things aren't quite right with the whole .NET/CLR "design". A programming language should be able to work regardless of the underlying platform. When FreeBSD moved most of the C/C++ ports from GCC to LLVM/Clang; it seems that there was a lot less breakage. And if there was breakage; it could be fixed (because it was an error in the code). VB.NET and CSharp have extremely weak preprocessors; I don't even think it is possible to write conditional code to support all types of CLR .NET VMs.


----------



## reddy (Sep 16, 2019)

There is a compatibility layer, called .NET Standard. .NET Standard is a contract, an API that the various runtimes (Full .Net Framework, .NET Core, Mono) must implement precisely to avoid the kind of situation you describe. Library maintainers wanting to provide a cross-platform library program against .NET Standard. Those choosing to program against a specific runtime explicitly choose not to make their application cross-platform, usually because they want to access APIs only available on the specific platforms they target (which is not a .NET limitation but more a platform limitation).

I'm not saying everything is perfect, for example the size of the .NET Standard API has been hugely increased I think 1 or 2 years ago, probably to make it easier for libraries to target the standard rather than a specific runtime. But From what I see, library developers shoot for cross-compatibility, at the very least because they want to be able to target the Full .NET Framework in addition to .NET core. I feel they put a huge focus on cross-platform, by design this has always been the vision behind this technological scheme since the first version of .NET, but Microsoft also seem to put quite serious efforts into .NET Standard.

I think the real problem here is that your application provider is screwing you. It is as if they decide to drop Linux support because their software now runs on Mac. I wouldn't say this is a Linux issue but more an unfortunate business decision. This type of problem usually comes from the fact that people jumped on beta/alpha technologies too fast. For example, if FreeBSD support is important for their application/customers, why would they use .Net Core while there is an X year old ticket on GitHub clearly indicating that the build tools for FreeBSD are not there yet. I think this is where the issue is. They chose a tool while knowing that no compiler existed for the platform they wanted to target.

I think the problem here is not that the programming language does not work across platforms, it is rather that they chose to program for a different VM, having a different base library and using a different instruction set. But the situation was quite confusing at some point to be fair with all these renaming ASP.NET Core, ASP.NET Next, .NET Core etc.... and even disruptive changes in the developer story (tooling, file formats etc...) and APIs. But to continue to be fair, why use alpha tools for production projects?  Many people do like us simply and use Mono, I do not plan to use .NET Core before 5 - 10 years. It is like deciding that you are going to build your software for FreeBSD14-CURRENT immediately (an even more unstable and risky version than 13-CURRENT).


----------



## tingo (Sep 21, 2019)

ekingston said:


> Without .NET Core support these applications become unusable.


IMNSHO, then you should start looking for replacements for those applications - better find a way forward before they become unusable.
Nothing lasts forever, you have to adapt to a changing world or else you will be left alone on your isolated island of obsolete systems and stuff.

Fine if you have vintage tech as a hobby, not so fine for your day to day life.


----------



## ekingston (Sep 23, 2019)

tingo said:


> IMNSHO, then you should start looking for replacements for those applications - better find a way forward before they become unusable.
> Nothing lasts forever, you have to adapt to a changing world or else you will be left alone on your isolated island of obsolete systems and stuff.
> 
> Fine if you have vintage tech as a hobby, not so fine for your day to day life.



When the problem of not moving forward is lack of support of the newer framework in the OS, the OS might need to be considered as isolating itself on an island.

If you happen to know a 4th streaming media server solution that avoids .NET altogether, I would appreciate knowing about it.


----------



## 17plus9 (Oct 15, 2019)

There is an updated build instruction and pre-build 3.0.100 version. https://github.com/jasonpugsley/core-sdk/wiki/.Net-Core-3.0.0-for-FreeBSD-12


----------



## unitrunker (Oct 16, 2019)

17plus9 said:


> There is an updated build instruction and pre-build 3.0.100 version. https://github.com/jasonpugsley/core-sdk/wiki/.Net-Core-3.0.0-for-FreeBSD-12


Need to eventually get this into ports.


----------



## drhowarddrfine (Oct 16, 2019)

unitrunker Why? We have our own tools that are just as good or better.


----------



## 17plus9 (Oct 16, 2019)

There is first a lot of testing and observation of real-world behavior needed, isn't it?


----------

