.NET Core 1.0 Released

[justmy2cents]

Well luckily most linux developers haven't show any interest in .NET, lets hope it stays like that at least for opensource software, i do expect some closed software to try it tho but i expect it won't be much of a success outside maybe Redhat.

now, why would that be so? current .Net license is more FLOSS than many others in wide use

[ElectricPrism]

The only scenario that I personally imagine I'd benefit from this is by it progressing development in mono or wine, assuming I understand that this would partially help them with some core functions.

Other than that I'm happy to keep it as away from FOSS as possible, proprietary on Linux is another story.

The only temptation Microsoft has put out is grabbing a Surface Book Pro and installing Arch Linux on it.

[smitty3268]

Have a read of this shit and laugh :



Thanks again, that doco is brilliant.

your target runtime requires at a minimum :
- 3 x .dll files
- 2 x .so files (note the subtle difference between Dynamic Link Lib vs Shared Object ... your Hello World needs both !!)
- something else called 'corerun' that could be an .ELF file, or could be anything at all ???? Who knows ???

This is Genius !!

Meh. It's pretty much the same thing as Java. If you don't like that, you won't like this either.

[unixfan2001]

SteveOC64

It's called cross-compiling and it's fairly standard practice.
Do you also bitch and moan whenever a software company prefers to compile ARM based software on a regular desktop computer?

[dotnetlover]

Huge .NET fan here. So I'm a little upset you guys aren't excited about it. That said, FreeBSD support mostly works and isn't advertised as fully functional though it may be. Biggest things ahead are ARM32 and ARM64 support.

you can apt-get on Debian and yum on RHEL.

I don't get the CoreCLR failures you are seeing Gentoo guy.

[pipe13]

I had no trouble rtfm and installing dotnet on Fedora 23. Said "Hello" to "Hello World", then tried installing Visual Studio Code. No joy, a raft of errors when trying to
$ cd ~/.vscode/extensions/ms-vscode.cpptools-0.4.2/
$ /usr/local/bin/dotnet restore --configfile NuGet.Config --infer-runtimes
$ Error: System.Threading.Timer 4.0.1-rc3-23803 provides a compile-time reference assembly for System.Threading.Timer on DNXCore,Version=v5.4, but there is no run-time assembly compatible with fedora.23-x64.
One or more packages are incompatible with DNXCore,Version=v5.4 (fedora.23-x64).

But its Brand New Stuff, so I'll wait a week or two before trying again. It's not like all my Emacs/Gcc/Gdb/Qt projects are desperately crying for change.

[dagger]

Yes, but they evidently cannot expect users to be able to read. Do you have the dependent packages installed? Do you have a distribution/version that is supported by their binary packages? (You can also always compile yourself...)

I guess without the comfort of a package manager and the work of package maintainers you'd conclude that no software was tested before its release?

I might not be able to read, but I can copy/paste. Tested on Fedora 23...

[randomizer]

Huge .NET fan here. So I'm a little upset you guys aren't excited about it.

I was kind of excited for it last year. I played around with ASP.NET Core 1.0 (or ASP.NET 5 as it was called at the time) and it was a really awful experience even on Windows. It required non-trivial changes to IIS as well as the deployment process. I was trying it out on a POC project but ran out of time to resolve the problems I had and switched back to ASP.NET 4.5. Then they went and deprecated the entire tool chain and did who knows what with project.json, all during the Release Candidate phase, which somewhat validated my decision not to keep burning time. Hopefully the sandstorm has settled.

[Hi-Angel]

SteveOC64

It's called cross-compiling and it's fairly standard practice.
Do you also bitch and moan whenever a software company prefers to compile ARM based software on a regular desktop computer?

Nah, it is standard practice assuming you target only binaries to the system. But the source released, I guess, in order to allow other people develop it, isn't it? So they ought at least to make sure it would compile on that target system.

[Luke_Wolf]

Huge .NET fan here. So I'm a little upset you guys aren't excited about it. That said, FreeBSD support mostly works and isn't advertised as fully functional though it may be. Biggest things ahead are ARM32 and ARM64 support.

you can apt-get on Debian and yum on RHEL.

I don't get the CoreCLR failures you are seeing Gentoo guy.

This is a Linux forum, therefore you can make mounds of money selling tin foil hats and popcorn the moment Microsoft comes up in the news. Also we apologize for the inconvenience but due to it's overuse we've had to move E.E.E to the free slot on your provided Microsoft Discussion in a Linux Forum bingo card, The reality is that most linux forum goers are ungrateful conspiratorial gits that are either luddites that pray to the glory of the "UNIX philosophy" as a cargo cult or are whiny children that don't understand that developing things takes time when they want it now.

As to what you've said it is certainly a very interesting development that shall have some very profound effects on the industry, Microsoft pointed out in their blog that Samsung has started some massive investments into it, which could be for their smartphones but it could also be for their embedded products like their washers and refrigerators. Either way Microsoft is finally managing .NET correctly, and other companies including Red Hat are responding.

Nah, it is standard practice assuming you target only binaries to the system. But the source released, I guess, in order to allow other people develop it, isn't it? So they ought at least to make sure it would compile on that target system.

It compiles just fine on Linux (See Instructions here https://github.com/dotnet/coreclr/bl...nstructions.md ), the problem is that it does not currently compile on BSD because more work is needed in porting CoreFX to BSD APIs, even though CoreCLR is ready. Hence despite what Michael wrote FreeBSD is not a currently supported platform, but likely will be in the near future. Because of the nature of dynamically linked code however you're not totally up shit creek because you can compile a library targeted at Linux (which is what they're doing) and as long as you don't call into the bits that call into things that are linux specific it won't explode, additionally if you do dynamic dispatch (Which AFAIK they are doing) you can compile the library for Linux and then dynamically call into Linux or BSD APIs depending on what it's running on.