Without specifying RuntimeIdentifiers in my csproj I got win7-x64 on both win7 and win10 machines. Both builds works (based on full framework).
I cannot find docs about - how to choose right RID and what is the difference between same-architecture-and-platform RIDs?
The.NET Core defaults to win7 for
.NET Framework projects. In most cases, win10 and win7 runtime identifiers produce identical output, especially for .NET Framework projects.
The difference only matters if you depend on a NuGet packages that has Windows 10 specific APIs, which very few do, if any. Choose the runtime identifier that matches the minimum platform you support. E.g. if you don't intend to support Windows 7, 8, or 8.1, use win10.
Or use both if you want to support multiple platforms. RuntimeIdentifiers accepts a semicolon separated list.
When you deliberately want your apps to be only used by Windows 10 users.
That can be pleasant if your apps do use Windows 10 specific features, which is not obvious for console and web apps, but might be typical when Microsoft introduces other project types such as GUI apps.
What I can think of at this moment is Windows 10 only things such as HTTP/2 support.
Related
I am used to the dot net framework building a .exe file that I can release
However in .Net Core 2.0 I need to specify a runtime id when creating the .exe
for example
dotnet publish --runtime win7-x84
where the runtime id is win7
What factors should I consider when choosing the run time id?
Do I need to be releasing multiple .exe versions to cater for my clients on different operating systems?
I have looked at the document here
What factors should I consider when choosing the run time id?
Well, the main factor you should consider is a target Operating System, where the application will be launched. Everything became much simpler after .NET Core 2.0 added support of portable RIDs. Portable RIDs do not include OS details, e.g.: win-x64 or linux-x86. If operating systems belong to one platform (Windows or Linux) you could publish one version of application that will run on all OS from the family. So to build application for whole family of x64 Windows OS run the following publish command:
dotnet publish --configuration Release --runtime win-x64
Do I need to be releasing multiple .exe versions to cater for my
clients on different operating systems?
According to above explanation, there is no need in separate versions for different OS within one family. You don't need to build new versions for win7, win8, win10, etc. However you still need to publish two application versions for support of x86 and x64 architectures. It is possible to build only one x32 version that will run on both x32 and x64. However it will run in 32-bit mode on x64 OS, which should be avoided.
This question contains a lot of other details about compatibility between different RIDs and OS. Much of this outdated since portable RIDs were introduced but there is still plenty of useful info.
I've created a new ASP.NET 5 project and I faced with something that I didn't understand well about how the new ASP.NET works.
In my references there are DNX 4.5.1 and DNX Core 5.0. When I install a new package from Nu-Get, some packages install successfully in both and some tell me they aren't supported by DNX Core 5.0.
Can I use many versions of DNX for supporting my packages or I must bound the things with DNX Core 5.0 to enjoy the advantages of ASP.NET 5, like cross-platform and others?
ASP.NET 5 projects are multi-targeted, which means you can compile for multiple platforms simultaneously. In your case .NET 4.5.1 targets ASP.NET 5 on the full .NET runtime (4.5.1) and .NET Core (5.0). When you compile your project, ASP.NET 5 actually creates output for both of these targets so - assuming you get the code to compile for both platforms - the application can run on either of them. It's possible to run additional targets to your projects.
When you actually run your application though, you have to pick a specific version of the .NET runtime you want to run under. In Visual Studio there's a drop down in the project settings where you can select that runtime that actually executes. When you use command line publish you also specify which platform to publish to with a parameter (if omitted it uses the active DNX runtime I believe).
As to the differences - .NET Core is a trimmed down version of the full .NET runtime, that is cross-platform and can run on Windows and other platforms like Linux and OSX. Because it has to run on other platforms a lot of the platform specific Windows features are not supported in this runtime, and as the platform is still evolving some APIs are simply not implemented yet in .NET Core. This is the reason you are likely to see many compile errors when you target .NET Core with existing code/libraries. In order to run on .NET core existing .NET code typically needs at least some minor adjustments to account for the smaller API footprint and potentially serious redesign to work around missing functionality.
If you need to use existing code and depend on assemblies/NuGet packages that are based on previous versions of .NET you have to stick with the full .NET version. You can still take advantage of the new ASP.NET 5 features and eco-system, as well as getting the benefit of the full .NET runtime and full API surface you are used to from previous .NET versions. The downside is that the runtime is Windows only and has a bigger resource footprint.
.NET Core is a new runtime and you should treat it as such. Migrating to this platform is likely not a trivial task. The benefits of this platform is a much leaner footprint and that it can run across multiple OS platforms.
It's likely that it'll take some time for the full potential of .NET Core to come to fruition as Microsoft expands the feature set and cross-platform compatibility but we won't really know what this will look like since it is still in Beta (well RC but it's really a beta with major changes still coming in RC2).
I read that WinRT does not have a layer that support .NET applications here: seek to 1:55 seconds http://www.youtube.com/watch?v=TI0ABjSKAGU
I also read that .NET 4.5 framework provided support for Windows Runtime here Differences between .NET 4.0 and .NET 4.5 in High level in .NET.
Here is my confusion:
Does that mean that I can run my .NET application on Windows Runtime now? How WinRT supports my .NET app? I have an idea that .NET can only be used to create web applications which are usually consumed using webbrowsers. If WinRT had a browser then why WinRT had problems in running my .NET application?
WinRT is an OS/layer which is installed on ARM based machines and tablets (Surface tablet).
I want to know what type of .NET application I will be developing for WinRT given that I now have support for Windows Runtime in .NET 4.5 framework.
If you are developing an application for the Windows Store, you will be developing it using the Windows Runtime (WinRT). That is the only option today. After you've made that choice, you can choose between a C#/XAML or a HTML/WinJS user interface. You don't "choose" .NET 4.5. You're selecting the Windows Runtime.
There are two distinct platforms, and overlapping terminology:
Windows Runtime (usually abbreviated as WinRT) and .NET
The .NET platform has existed and been available for production development purposes since the release of Visual Studio 2002 and .NET 1.0. Using this platform, and its modern versions (4.5.1 with Visual Studio 2013), you can build what would be considered a traditional Windows executable or application. From Windows Services, desktop applications written for several different UI platforms (WinForms and WPF), and sophisticated web applications all can be created and are portable across all modern versions of Windows, with the exception of WindowsRT. WindowsRT runs traditionally on lower powered ARM processors, and cannot execute a traditional application written for .NET.
Unfortunately, the names and capabilities are very confusing. WinRT (Windows Runtime), which is the platform, can be used to create Windows Store applications. It cannot be used currently to build what would be considered a native desktop application. .NET 4.5 cannot be used to build a Windows Store application. The WinRT platform can target any modern Windows device, from tablet, to desktop. WinRT also runs on Windows RT, which are the lower powered, non-x86 chipsets like ARM.
All platforms share several languages: C#, VB, and C++.
The WinRT's libraries manifest as a layer that look identical to nearly identical in many cases to .NET libraries. In fact, the documentation can often be used for either in common cases. More confusingly, it's sometimes referred to as .NET for Windows Store apps. You'll see how it's not a complete .NET 4.5 implementation.
The confusion often comes from the fact that they are so similar. The underlying code for WinRT is not .NET. It is opaque (and mostly written in C++). It looks like .NET 4.5, and often performs/behaves like .NET 4.5, but it isn't the same platform as is used by a traditional .NET 4.5 application. While you can create code that can run as a portable class library and use functionality and APIs that are common to all platforms (.NET and WinRT), a WinRT application can not directly call .NET 4.5 code.
The Windows Runtime is a highly sandboxed and API-curated developer experience, much like is available on various phone platforms, like the Windows Phone Runtime, iOS, and Android. If you look at the "surface" area of the .NET platform and CLR, you'll see how large and complex it has become, and that there are a lot of capabilities that either don't make sense in the context of a Windows Store application, or simply aren't safe. I expect over several releases Microsoft will include additional features to the Windows Runtime from the core Windows OS. Those APIs may/may not mirror similar functionality found in .NET 4.5.
However, on a Windows 8+ system, a Windows .NET application can access a subset of the APIs available in the WinRT (the marketing folks at Microsoft refer to it as a "streamlined" set of APIs). For example, you cannot access the WinRT UI platform and create a desktop application that builds its interface using WinJS or XAML, which are only available in a WinRT application.
.NET Framework Support for Windows Store Apps and Windows Runtime
A solution containing my MVC application is having nearly 20 different projects (one of them is MVC, few are WCF service applications, and the rest are class libraries.
They all work, and gets build fine.. but the issue is they are giving warnings related to platforms while doing build. I have checked in the configuration manager that some of them are set as "x86" platform, and some of them are set for "Any CPU" and I feel I receive the warnings due to this.
As a developer, and in order to support cross-platform, I think I need to set all projects under this solution to target "AnyCPU".
I would like to know if this is the safer approach? or if there is any risk involved during deployment?
Any inputs over this, much appreciated.
AnyCPU is the least restrictive and should be fine. x86 will restrict to 32-bit process and require running in WOW64 mode on 64-bit platforms. x64 will limit it to 64-bit. AnyCPU creates DLLs that can run in the current loaded process (whether it is 32 or 64 bit). This should be the option unless you have some sort of limitation or optimization that requires you to target a specific platform.
I'm wondering about best practices to develop ASP.NET MVC apps with an option to deploy on Linux. If you are creating these kinds of MVC apps,
What Linux/Mono platform are you targeting?
How much of the development are you doing on Windows and how much on Linux?
Are you using an ORM to abstract the database? Which one?
Are you running a build engine on Linux? What about tests?
What other tools are you using?
How much additional work has it been to target Linux in addition to Windows?
What ugly or pleasant surprises have you encountered?
The company I work for targets Mono on Linux as our main deployment environment. Thus there is no "additional" work - we provide the whole stack, from hardware, through operating system (customized and trimmed) to applications. Using Open Source gives huge savings for us and our clients (and yes, we do contribute back to the OS Projects we rely on).
The important thing is to constantly test using your actual target (sorry, Mono on Windows doesn't count). Sure, developers use Visual Studio, but the continous integration (using CruiseControl.Net, you'll need Mono 2.4.2 to run it on Linux) is done both on Windows and Linux, testing all Mono versions we expect to work on (it got much more stable recently, but still, regressions do happen between releases). It's quite easy to run parallel Mono versions on one *nix system, you can even include an svn snapshot build if you prefer to catch upstream regressions early. If you don't roll out your own distribution, then remember that most Linux vendors ship Mono with custom patches - this has caused problems for us before. Also, many distributions have a lot of lag updating Mono, and this is a rapidly advancing project.
For database layer we use mostly "plain" ADO.NET - Oracle (with dotConnect for Oracle, they support Mono) and SQLite (Mono ships with a working connector). I have also used the official ADO.NET Driver for MySQL (Connector/NET) and it, too, works well. ORM mappings are more tricky, but NHibernate is usable (keep in mind that they do not support Mono officially).
As for the build engine and tests - NAnt and NUnit are well known and well tested. With most recent versions of Mono xbuild (clone of MSBuild) actually got usable, but prepare yourself for contributing quite a lot patches if you decide to use it for more complex scenarios.
Write tests. Lots of them. Be prepared to contribute patches and bugreports, and if you use commercial components - make sure the supplier officially supports Mono.
Nathan Bridgewater's blog has some nice articles showing, among other things:
running MVC3 with razor on mono
migrating ASP.NET MVC from Windows/SQL Server to Linux/MySQL
installing and running MonoDevelop
installing mono from source
http://iws.io/get-mvc3-razor-running-on-mono/
Take a look at the Mono project. Sounds like that is what you are looking for. If I remember correctly, they have ASP.NET MVC integrated into it now.
I have never worked with Mono, but from my understanding there are not many differences.