System.Text.Json ships as part of the shared framework in recent versions of .NET so for most users it won't be restored from nuget.org
HN user
akoeplinger
Regional Directors and MVPs aren't employed by Microsoft: https://rd.microsoft.com/en-us/about/
You can use the #readme anchor to link directly to the readme, e.g. https://github.com/ruby/ruby#readme
Quite useful when you want to point people directly at the description.
This was outdated info on the website, I've updated the page. Generics are supported with FullAOT nowadays.
Xamarin isn't based on the .NET Framework. It is based on Mono which is in turn already consuming a lot of code from CoreFX (== .NET Core) and that share will only increase over time.
Source: I'm working on the Mono BCL+Tools team at Xamarin/Microsoft.
There's https://github.com/dotnet/wcf which are the _client_ libraries of WCF for .NET Core.
For the server side of WCF you're right those are only available on .NET Framework right now.
Xamarin is built on top of Mono. The same applies to Unity3D.
We're sharing more and more code with .NET Core now so there's convergence happening but there are still pieces that are unique to us.
Disclaimer: I'm working on Mono for Xamarin/Microsoft.
The .NET Standard spec has multiple _versions_, each of them adding more APIs: https://github.com/dotnet/standard/blob/master/docs/versions...
It's true that .NET Standard 1.0-1.6 had a lot of gaps but these should be rectified with 2.0 now so you shouldn't run into these problems anymore (otherwise there's usually a good reason why a method/API is missing from the standard).
Disclaimer: I'm working on Mono for Microsoft/Xamarin, primarily class libraries and tools.
Great to hear that you're excited by it, we're too :)
This blog post has a few more details and examples of the WebAssembly work: http://www.mono-project.com/news/2017/08/09/hello-webassembl...
Disclaimer: I'm working on Mono for Microsoft/Xamarin (primarily class libraries and tools).
No, the upgrade to 8.1 needs to be explicitly kicked off through the Store: http://windows.microsoft.com/en-US/windows-8/update-from-win...
or bundle up an ASP.NET app with an embedded server
You can do that today: http://docs.asp.net/en/latest/conceptual-overview/dotnetcore...
There's a pretty interesting video of how the Office team uses C++ for their cross-platform efforts from CppCon 2014: https://www.youtube.com/watch?v=3HROqnw-nf4
I chuckled at this as well, so I filed an issue: https://github.com/ResearchKit/ResearchKit/issues/9
Should be fixed by now :)
I'd be interested in how you set it up, can you maybe share it somewhere?
Guides like https://wprogramming.wordpress.com/2011/07/11/remote-pssessi... don't seem "fairly easy" to me (that's why I said it requires a lot more configuration compared to Enter-PSSession when both parties are in the same domain).
Yes, but only if both PCs are in the same domain. Getting PowerShell remoting to work in other environments requires a lot of configuration.
PowerShell web access might be a good alternative: http://blogs.technet.com/b/askperf/archive/2012/11/05/window...
The 2008 R2 development system we have needs to be rebooted every two week, due to Windows Updates [..]
Windows Updates are published once a month (except for very critical fixes), so I wonder how that is possible in your environment?
I'm a bit surprised that you don't seem to have an equivalent of the Handysignatur [0] (eID based on mobile phone) we have in Austria. It's getting more and more popular here, I guess because all you need is a mobile phone (who has a card reader after all?).
I find it incredibly convenient as it gives you immediate access to a growing list of e-government services [1], as well as signing PDFs and even things like a service for cancelling subscriptions online [2].
[0] https://www.handy-signatur.at/hs2/home.aspx?language=en
[1] https://www.handy-signatur.at/hs2/?site=infos/applications
Because it is a lot of work and takes time to integrate the pieces MS open sourced :)
There are also a few cases where the code needs to be tweaked so it works correctly on Mono and the platforms it runs on.
No, it should run on the 4.5 profile just fine as backwards compatibility in the .NET APIs is very good.
Please note that this is still a draft and the .NET 2.0/3.5 assemblies will likely reappear as reference assemblies (i.e. containing only method signatures in IL, so you can build against those profiles but not run on them).
I added a note to the page to make this clear.
HN mods: can we get a "(draft)" note added to the submission title as well?
I just wanted to point out that there's nothing that inherently ties PowerShell to Windows (as expected, it's just a shell after all).
PowerShell provides direct access to [nearly?] the entire Windows OS
PS has access to the .NET Framework which abstracts the OS APIs, not really to Windows directly.
There's also chatter that MS is already working on porting PowerShell to CoreCLR/.NET Core (the cross-plat, open-source version of .NET).
There's already a PowerShell implementation for *nix: https://github.com/Pash-Project/Pash
One of those two is my fork and yes I did it to fix something, but edandersen's point was more geared towards a real fork (i.e. something that takes the project into a different direction) instead of the fork that GitHub requires to send a PR.
I agree with him, we already have a bunch of popular .NET build tools other than MSBuild like FAKE, basing one off of MSBuild doesn't seem to add a lot of value imho.
Yes, there is cross pollination. See this blog post from Miguel de Icaza for more details: http://tirania.org/blog/archive/2014/Nov-12.html
I ported Mono's WinForms implementation to .NET Core some time ago as a proof of concept: https://twitter.com/akoeplinger/status/546832629010817024
Would be great if MS open-sourced WinForms as well so we could fill in the gaps.
fsharp on Ubuntu with Mono dependencies:
sudo apt-get install fsharp
[...]
Need to get 22.2 MB of archives.
After this operation, 66.0 MB of additional disk space will be used.
Personally, I wouldn't call that heavy.Remember that the 10MB figure for CoreCLR you give is just for the runtime alone, it doesn't include any class libraries. The Mono runtime is in the same ballpark.
There are many edge cases you need to consider, so a seemingly simple language feature can become hard to get right quickly.
I highly recommend reading through https://roslyn.codeplex.com/discussions/570551 and the other four revisions of the nameof() spec, they do a very good job at explaining the tradeoffs of each design.
If you look below the repository title on GitHub, it says "mirrored from..". This means GitHub handles the synchronization (they set this up on request for some projects).
For me the advantage is being able to use GitHub's nice UI to browse the source code.
I think what I was aiming at is integration with other tools, rather than adding those checks directly into GitCop (as you said, there are already services that check code, validate CLA etc).
Or maybe provide me with a Travis-like sandbox where I can run my checks with whatever linter/validator/custom code I want and report the results back?
Just fleshing out some ideas here :)