We Keep Coding

C# getting my program to run on a .Net 1.1, win XP system

So I've made the program on windows 10 Visual studio Version 10 in c# as a console application. The program is just monitoring file changes with fsw. I'm now faced with the challenge of doing literally everything in my power to not have to install anything on the PC of which this program will have to run (as in company they don't normally like us installing anything on the old pc's). So I believe I need to compile the program in a lower version of .Net if possible?
Any help regarding the matter would be appreciated as most things I find is people wanting to move from 1.1 to higher versions or the odd reference to web applications or c++.
Also, (though it may be obvious) I'm not a coder, not even my job really and thus I am quite inexperienced so any answers dumbed down a lot would be incredibly useful.
Thanks in advance!

First of all, check if .Net framework is installed if you have not already, and in that case what version it has.
According to .Net version and dependencies windows XP does not include any .Net version. That page also include links on how to check version. The last .net release for windows XP is .Net 4.0. See .Net system requirements.
So there is no indication that you should use .Net 1.1. Either you would use whatever version is installed, or you install some version you want (i.e. the highest supported), or you do not install any version, and do something else.
Modern versions of Visual studio allow targeting of .Net framework from 2.0 and onwards. And I'm fairly sure you can run .Net 2.0 and later version on windows 10 if you install the framework. Using .Net 1.1 would probably require you to use windows XP as the development system, so I would avoid this if at all possible.
I would recommend using a virtual machine for testing, since it allows you to test on windows XP on your machine, and makes it easy to revert any failures. I would probably recommend migrating the entire PC to a virtual machine it at all possible, since this would reduce magnitude of hardware failures, and make backup and restoring much easier.

Multiple versions of .NET on the same server

So I've always known it's okay to run multiple versions of the .NET framework on a single computer (client or server alike). This question, though a bit old, talks about this.
A while back, however, I was tasked with creating a new ASP.NET application, and I was trying to decide whether to use the full .NET framework or .NET Core, and I came across this article from Microsoft. The article states that if I need side-by-side installations of the framework, I should use .NET Core. Here's the full quote:
To install applications with dependencies on different versions of
.NET, we recommend .NET Core. .NET Core offers side-by-side
installation of different versions of the .NET Core runtime on the
same machine. This side-by-side installation allows multiple services
on the same server, each of them on its own version of .NET Core.
But I thought side-by-side installations of the Framework were already possible without .NET Core? What am I missing?
The reason I ask is that I currently have an old ASP.NET application that uses the .NET Framework 2.0, and I am now working on one that uses .NET Core. I ran into some issues that got me considering switching the .NET Core app to the full .NET Framework 4.6, but that Microsoft article got me a bit confused.
The question is: will I be able to run both apps (.NET framework 2.0 and 4.6) on the same Windows 2008 R2 server without issues? If so, then what is that article referring to?
One last thing: both my apps (old and new) use Crystal Reports. There's a possibility that the new app might need a newer version of Crystal Reports than the old app. Will I be able to run different versions of Crystal Reports like this on the same server? Is this the situation in which I would require .NET Core like the Microsoft article says?
Thank you

Side-by-side installations of the framework are not only possible, they are a fact. NET 1.0, 2.0 and everything past 4.0 all have separate installations. However:
.NET 3.0 and 3.5 both use the 2.0 runtime and are therefore not truly separate.
Similarly, .NET 4.5 and all versions above all use the 4.0 runtime and are therefore not separate from each other. To further complicate things, when you install a later version, the base 4.0 runtime is actually upgraded.
Last but not least, which framework version gets picked to run your application has changed with .NET 4.0. The rules for this are rather complicated and depend on both the versions installed and the application configuration; see this article for a full discussion.
To your question, then:
Will I be able to run both apps (.NET framework 2.0 and 4.6) on the
same Windows 2008 R2 server without issues?
If .NET Framework 2.0 and 4.6 are both installed, then yes. Assuming no special configuration settings, the 2.0 application will run on the 2.0 framework, but it can also be configured to use the 4.6 framework (which will present itself as the 4.0 runtime).
If so, then what is that article referring to?
The article is referring to the fact that the full .NET Framework has gradually abandoned the idea of perfectly separate side-by-side installations by having no separations between minor version (and sometimes even major versions), while .NET Core has doubled down on the idea by allowing self-contained deployment. That is to say, not only can a .NET Core 1.0 and a .NET Core 2.0 application coexist without any risk of sharing dependencies the way a .NET Framework 2.0 and 3.5 application would, even two .NET Core 1.0 applications can exist together without sharing dependencies, something which is not possible for full .NET Framework applications. If (say) a patch is installed for .NET 2.0, it will affect all .NET 2.0, 3.0 and 3.5 applications, at least on the binary level. You cannot choose to have some applications affected by the patch and not others (although configuration switches are usually added for behavior that breaks compatibility).
One last thing: both my apps (old and new) use Crystal Reports.
There's a possibility that the new app might need a newer version of
Crystal Reports than the old app. Will I be able to run different
versions of Crystal Reports like this on the same server? Is this the
situation in which I would require .NET Core like the Microsoft
article says?
This is independent of the framework and depends on how Crystal Reports itself handles versioning. According to the manufacturer, the answer is yes, for major releases but not minor updates:
Side-by-side installation of different major release version of
Crystal Reports designer is supported since Crystal Reports 9,
because each major release version installs the software in different
directory.
You do not require .NET Core to make side-by-side installation of different assembly versions possible. What's more, even if you used a self-contained deployment of your .NET Core application, it would likely still refer to the shared installation of Crystal Reports on the machine, not to a self-contained deployment of Crystal Reports (I don't think such a thing exists; I'm not even sure Crystal Reports is currently supported on .NET Core).
Last but not least: note that some versions of .NET are no longer officially supported. The policies on what versions are supported (and where) are fairy complex, depending as they do on whether the Framework was part of the OS or not, but detailed here. .NET 4.6 has some very nasty JIT compiler bugs (fixed in 4.6.1), so you really don't want to be using it anyway, official support or no. If your server does not yet have any version of .NET past 2.0 installed, you may as well jump directly to the latest supported version for your OS (as of writing, 4.8).

.NET Core vs Mono

What is the difference between .NET Core and Mono?
I found a statement on the official site that said: "Code written for it is also portable across application stacks, such as Mono."
My goal is to use C#, LINQ, EF7 and Visual Studio to create a website that can be ran/hosted on Linux.
Someone told me that he wanted it to be "in Mono", but I don't know what that means. I know I want to use the .NET Core 1.0 with the technologies I listed above. He also said he wanted to use "fast CGI". I don't know what that means either.
Can you help me make sense of all these terms and if my expectations are realistic?

Necromancing.
Providing an actual answer.
What is the difference between .Net Core and Mono?
.NET Core now officially is the future of .NET. It started for most part with a re-write of the ASP.NET MVC framework and console applications, which of course includes server applications. (Since it's Turing-complete and supports interop with C dlls, you could, if you absolutely wanted to, also write your own desktop applications with it, for example through 3rd-party libraries like Avalonia, which were a bit very basic at the time I first wrote this, which meant you were pretty much limited to web or server stuff.) Over time, many APIs have been added to .NET Core, so much so that after version 3.1, .NET Core will jump to version 5.0, be known as .NET 5.0 without the "Core", and that then will be the future of the .NET Framework. What used to be the full .NET Framework will linger around in maintenance mode as Full .NET Framework 4.8.x for a few decades, until it will die (maybe there are still going to be some upgrades, but I doubt it). In other words, .NET Core is the future of .NET, and Full .NET Framework will go the way of the Dodo/Silverlight/WindowsPhone.
The main point of .NET Core, apart from multi-platform support, is to improve performance, and to enable "native compilation"/self-contained-deployment (so you don't need .NET framework/VM installed on the target machine.
On the one hand, this means docker.io support on Linux, and on the other, self-contained deployment is useful in "cloud-computing", since then you can just use whatever version of the dotnet-CORE framework you like, and you don't have to worry about which version(s) of the .NET framework the sysadmin has actually installed.
While the .NET Core runtime supports multiple operating systems and processors, the SDK is a different story. And while the SDK supports multiple OS, ARM support for the SDK is/was still work in progress. .NET Core is supported by Microsoft. Dotnet-Core did not come with WinForms or WPF or anything like that.
As of version 3.0, WinForms and WPF is also supported by .NET Core, but only on Windows, and only by C#. Not by VB.NET (VB.NET support planned for v5 in 2020). And there is no Forms Designer in .NET Core: it's being shipped with a Visual Studio update later, at an unspecified time.
WebForms are still not supported by .NET Core, and there are no plans to support them, ever (Blazor is the new kid in town for that).
.NET Core also comes with System.Runtime, which replaces mscorelib.
Oftentimes, .NET Core is mixed up with NetStandard, which is a bit of a wrapper around System.Runtime/mscorelib (and some others), that allows you to write libraries that target .NET Core, Full .NET Framework and Xamarin (iOS/Android), all at the same time.
the .NET Core SDK does not/did not work on ARM, at least not last time I checked.
"The Mono Project" is much older than .NET Core.
Mono is Spanish and means Monkey, and as a side-remark, the name has nothing to do with mononucleosis (hint: you could get a list of staff under http://primates.ximian.com/).
Mono was started in 2005 by Miguel de Icaza (the guy that started GNOME - and a few others) as an implementation of the .NET Framework for Linux (Ximian/SuSe/Novell). Mono includes Web-Forms, Winforms, MVC, Olive, and an IDE called MonoDevelop (also knows as Xamarin Studio or Visual Studio Mac). Basically the equivalent of (OpenJDK) JVM and (OpenJDK) JDK/JRE (as opposed to SUN/Oracle JDK). You can use it to get ASP.NET-WebForms + WinForms + ASP.NET-MVC applications to work on Linux.
Mono is supported by Xamarin (the new company name of what used to be Ximian, when they focused on the Mobile market, instead of the Linux market), and not by Microsoft.
(since Xamarin was bought by Microsoft, that's technically [but not culturally] Microsoft.)
You will usually get your C# stuff to compile on mono, but not the VB.NET stuff.
Mono misses some advanced features, like WSE/WCF and WebParts.
Many of the Mono implementations are incomplete (e.g. throw NotImplementedException in ECDSA encryption), buggy (e.g. ODBC/ADO.NET with Firebird), behave differently than on .NET (for example XML-serialization) or otherwise unstable (ASP.NET MVC) and unacceptably slow (Regex). On the upside, the Mono toolchain also works on ARM.
As far as .NET Core is concerned, when they say cross-platform, don't expect that cross-platform means that you could actually just apt-get install .NET Core on ARM-Linux, like you can with ElasticSearch. You'll have to compile the entire framework from source.
That is, if you have that space (e.g. on a Chromebook, which has a 16 to 32 GB total HD).
It also used to have issues of incompatibility with OpenSSL 1.1 and libcurl.
Those have been rectified in the latest version of .NET Core Version 2.2.
So much for cross-platform.
I found a statement on the official site that said, "Code written for
it is also portable across application stacks, such as Mono".
As long as that code doesn't rely on WinAPI-calls, Windows-dll-pinvokes, COM-Components, a case-insensitive file system, the default-system-encoding (codepage) and doesn't have directory separator issues, that's correct. However, .NET Core code runs on .NET Core, and not on Mono. So mixing the two will be difficult. And since Mono is quite unstable and slow (for web applications), I wouldn't recommend it anyway. Try image-processing on .NET core, e.g. WebP or moving GIF or multipage-tiff or writing text on an image, you'll be nastily surprised.
Note:
As of .NET Core 2.0, there is System.Drawing.Common (NuGet), which
contains most of the functionality of System.Drawing. It should be
more or less feature-complete in .NET-Core 2.1. However,
System.Drawing.Common uses GDI+, and therefore won't work on Azure
(System.Drawing libraries are available in Azure Cloud Service
[basically just a VM], but not in Azure Web App [basically shared
hosting?])
So far, System.Drawing.Common works fine on Linux/Mac, but has issues on iOS/Android - if it works at all, there.
Prior to .NET Core 2.0, that is to say sometime mid-February 2017, you could use SkiaSharp for imaging (example) (you still can). Post .net-core 2.0, you'll notice that SixLabors ImageSharp is the way to go, since System.Drawing is not necessarely secure, and has a lot of potential or real memory leaks, which is why you shouldn't use GDI in web-applications; Note that SkiaSharp is a lot faster than ImageSharp, because it uses native-libraries (which can also be a drawback). Also, note that while GDI+ works on Linux & Mac, that doesn't mean it works on iOS/Android.
Code not written for .NET (non-Core) is not portable to .NET Core.
Meaning, if you want a non-GPL C# library like PDFSharp to create PDF-documents (very commonplace), you're out of luck (at the moment) (not anymore). Never mind ReportViewer control, which uses Windows-pInvokes (to encrypt, create mcdf documents via COM, and to get font, character, kerning, font embedding information, measure strings and do line-breaking, and for actually drawing tiffs of acceptable quality), and doesn't even run on Mono on Linux
(I'm working on that).
Also, code written in .NET Core is not portable to Mono, because Mono lacks the .NET Core runtime libraries (so far).
My goal is to use C#, LINQ, EF7, visual studio to create a website
that can be ran/hosted in linux.
EF in any version that I tried so far was so goddamn slow (even on such simple things like one table with one left-join), I wouldn't recommend it ever - not on Windows either.
I would particularly not recommend EF if you have a database with unique-constrains, or varbinary/filestream/hierarchyid columns. (Not for schema-update either.)
And also not in a situation where DB-performance is critical (say 10+ to 100+ concurrent users).
Also, running a website/web-application on Linux will sooner or later mean you'll have to debug it.
There is no debugging support for .NET Core on Linux. (Not anymore, but requires JetBrains Rider.)
MonoDevelop does not (yet) support debugging .NET Core projects.
If you have problems, you're on your own. You'll have to use extensive logging.
Be careful, be advised extensive logging will fill your disk in no time, particularly if your program enters an infinite loop or recursion.
This is especially dangerous if your web-app runs as root, because log-in requires logfile-space - if there's no free space left, you won't be able to login anymore.
(Normally, about 5% of diskspace is reserved for user root [aka administrator on Windows], so at least the administrator can still log in if the disk is almost full. But if your applications run as root, that restriction does not apply for their disk usage, and so their logfiles can use 100% of the remaining free space, so not even the administrator can log in any more.)
It's therefore better not to encrypt that disk, that is, if you value your data/system.
Someone told me that he wanted it to be "in Mono", but I don't know
what that means.
It either means he doesn't want to use .NET Core, or he just wants to use C# on Linux/Mac. My guess is he just wants to use C# for a Web-App on Linux. .NET Core is the way to go for that, if you absolutely want to do it in C#. Don't go with "Mono proper"; on the surface, it would seem to work at first - but believe me you will regret it because Mono's ASP.NET MVC isn't stable when your server runs long-term (longer than 1 day) - you have now been warned. See also the "did not complete" references when measuring Mono performance on the techempower benchmarks.
I know I want to use the .Net Core 1.0 framework with the technologies
I listed above. He also said he wanted to use "fast cgi". I don't know
what that means either.
It means he wants to use a high-performance full-featured WebServer like nginx (Engine-X), possibly Apache.
Then he can run mono/dotnetCore with virtual name based hosting (multiple domain names on the same IP) and/or load-balancing. He can also run other websites with other technologies, without requiring a different port-number on the web-server. It means your website runs on a fastcgi-server, and nginx forwards all web-requests for a certain domain via the fastcgi-protocol to that server. It also means your website runs in a fastcgi-pipeline, and you have to be careful what you do, e.g. you can't use HTTP 1.1 when transmitting files. Otherwise, files will be garbled at the destination.
See also here and here.
To conclude:
.NET Core at present (2016-09-28) is not really portable, nor is is really cross-platform (in particular the debug-tools).
Nor is native-compilation easy, especially for ARM.
And to me, it also does not look like its development is "really finished", yet.
For example, System.Data.DataTable/DataAdaper.Update is missing...
(not anymore with .NET Core 2.0)
Together with the System.Data.Common.IDB* interfaces. (not anymore with .NET Core 1.1)
if there ever was one class that is often used, DataTable/DataAdapter would be it...
Also, the Linux-installer (.deb) fails, at least on my machine, and I'm sure I'm not the only one that has that problem.
Debug, maybe with Visual Studio Code, if you can build it on ARM (I managed to do that - do NOT follow Scott Hanselman's blog-post if you do that - there's a howto in the wiki of VS-Code on github), because they don't offer the executable.
Yeoman also fails. (I guess it has something to do with the nodejs version you installed - VS Code requires one version, Yeoman another... but it should run on the same computer. pretty lame
Never mind that it should run on the node version shipped by default on the OS.
Never mind that there should be no dependency on NodeJS in the first place.
The kestell server is also work in progress.
And judging by my experience with the mono-project, I highly doubt they ever tested .NET Core on FastCGI, or that they have any idea what FastCGI-support means for their framework, let alone that they tested it to make sure "everything works". In fact, I just tried making a fastcgi-application with .NET Core and just realized there is no FastCGI library for .NET Core "RTM"...
So when you're going to run .NET Core "RTM" behind nginx, you can only do it by proxying requests to kestrell (that semi-finished nodeJS-derived web-server) - there's no fastcgi support at present in .NET Core "RTM", AFAIK. Since there is no .net core fastcgi library, and no samples, it's also highly unlikely that anybody did any testing on the framework to make sure fastcgi works as expected.
I also question the performance.
In the (preliminary) techempower-benchmark (round 13), aspnetcore-linux ranks on 25% relative to the best performance, while comparable frameworks like Go (golang) rank at 96.9% of peak performance (and that is when returning plaintext without file-system access only). .NET Core does a little better on JSON-serialization, but it does not look compelling either (go reaches 98.5% of peak, .NET core 65%). That said, it can't possibly be worse than "mono proper".
Also, since it's still relatively new, not all of the major libraries have been ported (yet), and I doubt that some of them will ever be ported.
Imaging support is also questionable at best.
For anything encryption, use BouncyCastle instead.
Can you help me make sense of all these terms and if my expectations
are realistic?
I hope i helped you making more sense with all these terms.
As far as your expecations go:
Developing a Linux application without knowing anything about Linux is a really stupid idea in the first place, and it's also bound to fail in some horrible way one way or the other. That said, because Linux comes at no licensing costs, it's a good idea in principle, BUT ONLY IF YOU KNOW WHAT YOU DO.
Developing an application for a platform where you can't debug your application on is another really bad idea.
Developing for fastcgi without knowing what consequences there are is yet another really bad idea.
Doing all these things on a "experimental" platform without any knowledge of that platform's specifics and without debugging support is suicide, if your project is more than just a personal homepage. On the other hand, I guess doing it with your personal homepage for learning purposes would probably be a very good experience - then you get to know what the framework and what the non-framework problems are.
You can for example (programmatically) loop-mount a case-insensitive fat32, hfs or JFS for your application, to get around the case-sensitivity issues (loop-mount not recommended in production).
To summarize
At present (2016-09-28), I would stay away from .NET Core (for production usage). Maybe in one to two years, you can take another look, but probably not before.
If you have a new web-project that you develop, start it in .NET Core, not mono.
If you want a framework that works on Linux (x86/AMD64/ARMhf) and Windows and Mac, that has no dependencies, i.e. only static linking and no dependency on .NET, Java or Windows, use Golang instead. It's more mature, and its performance is proven (Baidu uses it with 1 million concurrent users), and golang has a significantly lower memory footprint. Also golang is in the repositories, the .deb installs without problems, the sourcecode compiles - without requiring changes - and golang (in the meantime) has debugging support with delve and JetBrains Gogland on Linux (and Windows and Mac). Golang's build process (and runtime) also doesn't depend on NodeJS, which is yet another plus.
As far as mono goes, stay away from it.
It is nothing short of amazing how far mono has come, but unfortunately that's no substitute for its performance/scalability and stability issues for production applications.
Also, mono-development is quite dead, they largely only develop the parts relevant to Android and iOS anymore, because that's where Xamarin makes their money.
Don't expect Web-Development to be a first-class Xamarin/mono citizen.
.NET Core might be worth it, if you start a new project, but for existing large web-forms projects, porting over is largely out of the question, the changes required are huge. If you have a MVC-project, the amount of changes might be manageable, if your original application design was sane, which is mostly not the case for most existing so-called "historically grown" applications.
December 2016 Update:
Native compilation has been removed from .NET Core preview, as it is not yet ready...
Seems like they have improved pretty heavily on the raw text-file benchmark, but on the other hand, it's gotten pretty buggy. Also, it further deteriorated in the JSON benchmarks. Curious also that entity framework shall be faster for updates than Dapper - although both at record slowness. This is very unlikely to be true. Looks like there still are more than just a few bugs to hunt.
Also, there seems to be relief coming on the Linux IDE front.
JetBrains released "Project Rider", an early access preview of a C#/.NET Core IDE for Linux (and Mac and Windows), that can handle Visual Studio Project files.
Finally a C# IDE that is usable & that isn't slow as hell.
Conclusion: .NET Core still is pre-release quality software as we march into 2017. Port your libraries, but stay away from it for production usage, until framework quality stabilizes.
And keep an eye on Project Rider.
2017 Update
Have migrated my (brother's) homepage to .NET Core for now.
So far, the runtime on Linux seems to be stable enough (at least for small projects) - it survived a load test with ease - mono never did.
Also, it looks like I mixed up .NET-Core-native and .NET-Core-self-contained-deployment. Self-contained deployment works, but it is a bit underdocumented, although it's super easy (the build/publish tools are a bit unstable, yet - if you encounter "Positive number required. - Build FAILED." - run the same command again, and it works).
You can run
dotnet restore -r win81-x64
dotnet build -r win81-x64
dotnet publish -f netcoreapp1.1 -c Release -r win81-x64
Note: As per .NET Core 3, you can publish everything minified as a single file:
dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish -r linux-x64 -c Release /p:PublishSingleFile=true
However, unlike go, it's not a statically linked executable, but a self-extracting zip file, so when deploying, you might run into
problems, especially if the temp directory is locked down by group
policy, or some other issues. Works fine for a
hello-world program, though. And if you don't minify, the executable size will clock in at something around 100 MB.
And you get a self-contained .exe-file (in the publish directory), which you can move to a Windows 8.1 machine without .NET framework installed and let it run. Nice. It's here that dotNET-Core just starts to get interesting. (mind the gaps, SkiaSharp doesn't work on Windows 8.1 / Windows Server 2012 R2, [yet] - the ecosystem has to catch up first - but interestingly, the Skia-dll-load-fail doesn't crash the entire server/application - so everything else works)
(Note: SkiaSharp on Windows 8.1 is missing the appropriate VC runtime files - msvcp140.dll and vcruntime140.dll. Copy them into the publish-directory, and Skia will work on Windows 8.1.)
August 2017 Update
.NET Core 2.0 released.
Be careful - comes with (huge breaking) changes in authentication...
On the upside, it brought the DataTable/DataAdaper/DataSet classes back, and many more.
Realized .NET Core is still missing support for Apache SparkSQL, because Mobius isn't yet ported. That's bad, because that means no SparkSQL support for my IoT Cassandra Cluster, so no joins...
Experimental ARM support (runtime only, not SDK - too bad for devwork on my Chromebook - looking forward to 2.1 or 3.0).
PdfSharp is now experimentally ported to .NET Core.
JetBrains Rider left EAP. You can now use it to develop & debug .NET Core on Linux - though so far only .NET Core 1.1 until the update for .NET Core 2.0 support goes live.
May 2018 Update
.NET Core 2.1 release imminent.
Maybe this will fix NTLM-authentication on Linux (NTLM authentication doesn't work on Linux {and possibly Mac} in .NET-Core 2.0 with multiple authenticate headers, such as negotiate, commonly sent with ms-exchange, and they're apparently only fixing it in v2.1, no bugfix release for 2.0).
But I'm not installing preview releases on my machine. So waiting.
v2.1 is also said to greatly reduce compile times. That would be good.
Also, note that on Linux, .NET Core is 64-Bit only !
There is no, and there will be no, x86-32 version of .NET Core on Linux.
And the ARM port is ARM-32 only. No ARM-64, yet.
And on ARM, you (at present) only have the runtime, not the dotnet-SDK.
And one more thing:
Because .NET-Core uses OpenSSL 1.0, .NET Core on Linux doesn't run on Arch Linux, and by derivation not on Manjaro (the most popular Linux distro by far at this point in time), because Arch Linux uses OpenSSL 1.1. So if you're using Arch Linux, you're out of luck (with Gentoo, too).
Edit:
Latest version of .NET Core 2.2+ supports OpenSSL 1.1. So you can use
it on Arch or (k)Ubuntu 19.04+. You might have to use the .NET-Core
install script though, because there are no packages, yet.
On the upside, performance has definitely improved:
.NET Core 3:
.NET-Core v 3.0 is said to bring WinForms and WPF to .NET-Core.
However, while WinForms and WPF will be .NET Core, WinForms and WPF in .NET-Core will run on Windows only, because WinForms/WPF will use the Windows-API.
Note:
.NET Core 3.0 is now out (RTM), and there is WinForms and WPF support, but only for C# (on Windows). There is no WinForms-Core-Designer. The designer will, eventually, come with a Visual Studio update, somewhen. WinForms support for VB.NET is not supported, but is planned for .NET 5.0 somewhen in 2020.
PS:
echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
export DOTNET_CLI_TELEMETRY_OPTOUT=1
If you've used it on windows, you probably never saw this:
The .NET Core tools collect usage data in order to improve your
experience. The data is anonymous and does not include command-line
arguments. The data is collected by Microsoft and shared with the
community. You can opt out of telemetry by setting a
DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 using your
favorite shell. You can read more about .NET Core tools telemetry #
https://aka.ms/dotnet-cli-telemetry.
I thought I'd mention that I think monodevelop (aka Xamarin Studio, the Mono IDE, or Visual Studio Mac as it is now called on Mac) has evolved quite nicely, and is - in the meantime - largely usable.
However, JetBrains Rider (2018 EAP at this point in time) is definitely a lot nicer and more reliable (and the included decompiler is a life-safer), that is to say, if you develop .NET-Core on Linux or Mac. MonoDevelop does not support Debug-StepThrough on Linux in .NET Core, though, since MS does not license their debugging API dll (except for VisualStudio Mac ... ). However, you can use the Samsung debugger for .NET Core through the .NET Core debugger extension for Samsung Debugger for MonoDevelop
Disclaimer:
I don't use Mac, so I can't say if what I wrote here applies to FreeBSD-Unix based Mac as well. I am refering to the Linux (Debian/Ubuntu/Mint) version of JetBrains Rider, mono, MonoDevelop/VisualStudioMac/XamarinStudio and .NET-Core. Also, Apple is contemplating a move from Intel-processors to self-manufactured ARM(ARM-64?)-based processors, so much of what applies to Mac right now might not apply to Mac in the future (2020+).
Also, when I write "mono is quite unstable and slow", the unstable relates to WinFroms & WebForms applications, specifically executing web-applications via fastcgi or with XSP (on the 4.x version of mono), as well as XML-serialization-handling peculiarities, and the quite-slow relates to WinForms, and regular expressions in particular (ASP.NET-MVC uses regular expressions for routing as well).
When I write about my experience about mono 2.x, 3.x and 4.x, that also does not necessarely mean these issues haven't been resolved by now, or by the time you are reading this, nor that if they are fixed now, that there can't be a regression later that reintroduces any of these bugs/features. Nor does that mean that if you embed the mono-runtime, you'll get the same results as when you use the (dev) system's mono runtime. It also doesn't mean that embedding the mono-runtime (anywhere) is necessarely free.
All that doesn't necessarely mean mono is ill-suited for iOS or Android, or that it has the same issues there. I don't use mono on Android or IOS, so I'm in no positon to say anything about stability, usability, costs and performance on these platforms. Obviously, if you use .NET on Android, you have some other costs considerations to do as well, such as weighting xamarin-costs vs. costs and time for porting existing code to Java. One hears mono on Android and IOS shall be quite good. Take it with a grain of salt. For one, don't expect the default-system-encoding to be the same on android/ios vs. Windows, and don't expect the android filesystem to be case-insensitive, and don't expect any windows fonts to be present.

In the .NET world there are two types of CLRs, "full" CLRs and Core CLRs, and these are quite different things.
There are two "full" CLR implementations, the Microsoft native .NET CLR (for Windows) and the Mono CLR (which itself has implementations for Windows, linux and unix (Mac OS X and FreeBSD)). A full CLR is exactly that - everything, pretty much, that you need. As such, "full" CLRs tend to be large in size.
Core CLRs are on the other hand are cut down, and much smaller. Because they are only a core implementation, they are unlikely to have everything you need in them, so with Core CLRs you add feature sets to the CLR that your specific software product uses, using NuGet. There are Core CLR implementations for Windows, linux (various) and unix (Mac OS X and FreeBSD) in the mix. Microsoft have or are refactoring the .NET framework libraries for Core CLR too, to make them more portable for the core context. Given mono's presence on *nix OSs it would be a surprise if the Core CLRs for *nix did not include some mono code base, but only the Mono community and Microsoft could tell us that for sure.
Also, I'd concur with Nico in that Core CLRs are new -- it's at RC2 at the moment I think. I wouldn't depend on it for production code yet.
To answer your question you could delivery your site on linux using Core CLR or Mono, and these are two different ways of doing it. If you want a safe bet right now I'd go with mono on linux, then port if you want to later, to Core.

This is no more .NET Core vs. Mono. It's unified.
Update as of November 2020 - .NET 5 released that unifies .NET Framework and .NET Core
.NET and Mono will be unified under .NET 6 that would be released in November 2021
.NET 6.0 will add net6.0-ios and net6.0-android.
The OS-specific names can include OS version numbers, like net6.0-ios14.
Check below articles:
https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/
https://github.com/dotnet/maui

You have chosen not only a realistic path, but arguably one of the best ecosystems strongly backed(also X-platforms) by MS. Still you should consider following points:
Update: Main doc about .Net platform standard is here: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md
Update: Current Mono 4.4.1 cannot run latest Asp.Net core 1.0 RTM
Although mono is more feature complete, its future is unclear, because MS owns it for some months now and its a duplicate work for them to support it. But MS is definitely committed to .Net Core and betting big on it.
Although .Net core is released, the 3rd party ecosystem is not quite there. For example Nhibernate, Umbraco etc cannot run over .Net core yet. But they have a plan.
There are some features missing in .Net Core like System.Drawing, you should look for 3rd party libraries
You should use nginx as front server with kestrelserver for asp.net apps, because kestrelserver is not quite ready for production. For example HTTP/2 is not implemented.
I hope it helps

.Net Core does not require mono in the sense of the mono framework. .Net Core is a framework that will work on multiple platforms including Linux. Reference https://dotnet.github.io/.
However the .Net core can use the mono framework. Reference https://docs.asp.net/en/1.0.0-rc1/getting-started/choosing-the-right-dotnet.html (note rc1 documentatiopn no rc2 available), however mono is not a Microsoft supported framework and would recommend using a supported framework
Now entity framework 7 is now called Entity Framework Core and is available on multiple platforms including Linux. Reference https://github.com/aspnet/EntityFramework (review the road map)
I am currently using both of these frameworks however you must understand that it is still in release candidate stage (RC2 is the current version) and over the beta & release candidates there have been massive changes that usually end up with you scratching your head.
Here is a tutorial on how to install MVC .Net Core into Linux. https://docs.asp.net/en/1.0.0-rc1/getting-started/installing-on-linux.html
Finally you have a choice of Web Servers (where I am assuming the fast cgi reference came from) to host your application on Linux. Here is a reference point for installing to a Linux enviroment. https://docs.asp.net/en/1.0.0-rc1/publishing/linuxproduction.html
I realise this post ends up being mostly links to documentation but at this point those are your best sources of information. .Net core is still relatively new in the .Net community and until its fully released I would be hesitant to use it in a product environment given the breaking changes between released version.

This question is especially actual because yesterday Microsoft officially announced .NET Core 1.0 release. Assuming that Mono implements most of the standard .NET libraries, the difference between Mono and .NET core can be seen through the difference between .NET Framework and .NET Core:
APIs — .NET Core contains many of the same, but fewer, APIs as the .NET Framework, and with a different factoring (assembly names are
different; type shape differs in key cases). These differences
currently typically require changes to port source to .NET Core. .NET
Core implements the .NET Standard Library API, which will grow to
include more of the .NET Framework BCL APIs over time.
Subsystems — .NET Core implements a subset of the subsystems in the .NET Framework, with the goal of a simpler implementation and
programming model. For example, Code Access Security (CAS) is not
supported, while reflection is supported.
If you need to launch something quickly, go with Mono because it is currently (June 2016) more mature product, but if you are building a long-term website, I would suggest .NET Core. It is officially supported by Microsoft and the difference in supported APIs will probably disappear soon, taking into account the effort that Microsoft puts in the development of .NET Core.
My goal is to use C#, LINQ, EF7, visual studio to create a website
that can be ran/hosted in linux.
Linq and Entity framework are included in .NET Core, so you are safe to take a shot.

To be simple,
Mono is third party implementation of .Net framework for
Linux/Android/iOs
.Net Core is microsoft's own implementation for same.
.Net Core is future. and Mono will be dead eventually. Having said that .Net Core is not matured enough. I was struggling to implement it with IBM Bluemix and later dropped the idea. Down the time (may be 1-2 years), it should be better.

This is one of my favorite topics and the content here was just amazing. I was thinking if it would be worth while or effective to compare the methods available in Runtime vs. Mono. I hope I got my terms right, but I think you know what I mean. In order to have a somewhat better understanding of what each Runtime supports currently, would it make sense to compare the methods they provide? I realize implementations may vary, and I have not considered the Framework Class libraries or the slew of other libraries available in one environment vs. the other. I also realize someone might have already done this work even more efficiently. I would be most grateful if you would let me know so I can review it. I feel doing a diff between the outcome of such activity would be of value, and wanted to see how more experienced developers feel about it, and would they provide useful guidance. While back I was playing with reflection, and wrote some lines that traverse the .net directory, and list the assemblies.

.NET Framework 2.0 vs 3.5/4.0... any possible advantage to use the older version?

My project leader insists on using Visual Studio 2005 which only targets the .NET 2.0 framework and only supports C# 2.0 syntax.
He insists that the 2.0 framework has higher compatiblity and performance for older computers. By old, I mean 5-8 year old Windows XP machines.
Assuming we only support a minimum of Windows XP / Server 2003, is there any advantage at all to using .NET 2.0?
I am pretty sure that even targeting .NET 2.0 we can take advantage of C# 3.0 syntax in our code (lambdas, auto-implemented properties, etc.) if we upgrade past VS2005.

.Net 2.0 is considered to be more widely deployed, but 3.5 isn't far behind any more. However, that's no reason to limit yourself to Visual Studio 2005 or C# 2.0. Visual Studio 2010 can target .Net 2.0, and use C# 3.0 features when it does so to boot.

.NET 2 is no longer supported by Microsoft. Well, Microsoft makes the terms tougher to explain. For Windows XP and Windows Server 2003, you have to at least use .NET Framework 3.5 SP1,
http://blogs.technet.com/b/lifecycle/archive/2010/04/30/net-framework-3-5-sp1-and-later-now-supported-as-part-of-microsoft-windows.aspx
so that you can receive assistance from Microsoft support team.
Therefore, I see no reason to stay on .NET 2.
"the 2.0 framework has higher compatiblity and performance for older computers" is a joke for me. When you lose support-ability from Microsoft, you lose everything.

Normally, people who would like to use the older version is mainly because they think the old one is more stable and better to production.
But .NET 2.0 is quite out of date already, and .NET 3.5 and .NET 4.0 have been proven to be very stable and make things easier. (such as LINQ, you can try functional style programming via it, very fluent and productive)
For the IDE part, Microsoft rebuild the visual studio 2010, it is more stable and productive, and it is also can target .NET2.0 if you want.
So, why not use Visual Studio 2010 instead of 2005, even if your project is purely .NET2.0, the former also has downward compatibility.

Deploying c# app - user need to install .net framework?

Hey guys - I just wrote an app using c# and ready to deploy it. Never deployed a c# app before.
I deployed it and VC# outputted a .application file, application folder, and an installer. One of my users ran the installer (Windows 7) and was prompted to download/install the .net framework - which took upwards of 10 minutes. This is not acceptable for how simple my app is.
Moreover, I will need this app to be able to run on mac osx and linux if possible. Should I have wrote this in Java instead (poor planning on my part). What are my options?

C# is compiled to bytecode that runs on the CLR, the virtual machine that's at the core of the .NET framework. So yes, you need the .NET framework to run that.
Most current versions of Windows (XP, Vista, 7, etc.) come with some version of the .NET framework pre-installed, so your users don't have to download and install it. However, you might have used a version that's not already installed on the computers of (some of) your users.
For Linux and Mac OS X there is Mono, which is an open source implementation of .NET, but it does not contain everything that Microsoft's .NET contains, so your program might not work fully on Mono.
Using Java is not a real solution in the sense that your users would need to download and install the JRE (Java Runtime Environment) to run Java programs, very similar to the .NET framework. An advantage if you'd have used Java, is that Java is much more cross-platform compatible than .NET (Microsoft has no real interest in making .NET run on anything else than Windows).

.NET apps require the .NET framework. Java apps require the JRE. Your app is simple because .NET has done a lot of the work for you. A lot of companies write desktop apps in C++, but you will have to be mindful of cross-platform issues.

Yes, with any language that compiles to run on a managed runtime (.NET or Mono CLR, Java JVM) you will need to have that runtime installed. A C# application can compile to run on Windows on the .NET CLR, or on all the platforms you mention to run on the Mono runtime instead. Alternatively, a Java application would compile to run on the Java JRE, which is also compatible with all the platforms you mention.
So with either language there is potentially this extra installation overhead, and with either language you can achieve what you want.

You'll need to have .NET installed on your client's system in order to use your application.
As for running cross-platform - depending on how your Application is written, this can be simple or difficult.
You may want to look at Silverlight. This is directly supported on OS X and works on Linux via Moonlight.
Another alternative is to use Mono to run your .NET application on other platforms.

A C# app will need an implementation of the CLR (.NET) running on the local machine in order to run. A Java app will need an implementation of the JVM so it is really no different. On Windows, I would expect most people to have a .NET install.
Take a look at the Mono project as far as running it on Linux and Mac:
http://mono-project.com/Main_Page
One thing you can consider is using an older version of the .NET framework to ensure that the greatest number of people have it installed. I would use .NET 3.5 or even 2.0 if you do not need fancy new features. That would have been installed already on Windows 7 for example.
Since the Windows 7 user had to download the framework I assume you are currently targeting .NET 4 which means you must be using Visual Studio 2010 (or an express version). Here is a link that tells you how to target a different version of the framework:
http://msdn.microsoft.com/en-us/library/bb398202.aspx
One quick note about Mono, it is an excellent cross-platform option but it does not support the Windows Presentation Foundation (WPF) GUI framework at this point. You will either have to use Windows Forms or create different front-ends for different platforms.
If you want to create a Linux GUI (also available on Windows and Mac) you can try GTK#:
http://www.mono-project.com/GtkSharp
For a Mac native GUI you can check out MonoMac:
http://mjhutchinson.com/journal/2010/06/09/monomac_in_monodevelop
An excellent IDE for cross-platform .NET development is MonoDevelop (it will read your VC# project files):
http://monodevelop.com/

Like Java, .Net languages need a runtime installed. The full .Net framework is sometimes too big for small applications, so there is a smaller version of it call the compact framework with a smaller footprint that will install and download faster. You can read about it at http://msdn.microsoft.com/en-us/netframework/aa497273.aspx. As noted by other answers most current versions of Windows come with various versions of .Net framework, so this installation may not be needed for every user.
As far as your cross platform needs go Mono allows for running .Net applications on Linux, I am not sure about running them on OSX. My assumption is you can not. Unfortunately your cross platform requirements made .Net a bad choice, and you should have gone with Java.

Other people gave you complicated answers. Well here's my simple answer. .NET framework is needed to run .NET applications and so do Java need JVM (as MCain said). Starting with Windows Vista, Microsoft includes .NET Framework built inside Windows. And in addition, .NET have versions, from 1.0 to 4.0. With Vista and Windows 7, .NET 3.5 is installed by default. I think your app is targeted for .NET 4.0 which is why a Windows 7 user needed to install .NET framework. For me, if I have to write a simple program, I'll use .NET 2.0 (later version = larger libraries, etc) so that my users (if they are Vista or Windows 7) don't have to install .NET again to run my software. You can choose which version of .NET you will target from New Project Window in Visual Studio.

You can change the target framework in the properties tab. If you start a project in VS2008 the default is .net 3.5 and for VS2010 it is .net 4.0. If you don't need the advanced features you can change your target back to 2.0 which should be available on most computers by now (I would guess far over 90%). Be sure to remove dependencies which are not available in 2.0 (like System.Linq, System.DataSet.Extensions) and the accociated imports (But the compiler will tell you what to do).