I am new to .NET and c#.
There are so many good examples out there made for .NET 4.0, but when I do NUGET it complains that the target .net version mismatches.
I am developing for Windows 8 and Windows Phone 8, so they use .NET 4.5.
Is there any way to just convert the old projects and force them to use .NET 4.5?
Or do I need to wait for the author to update his project?
You can develop for Windows 8 with .NET 4.0, that's not a problem. Also you can load .NET 4.0 projects into Visual Studio 2012 and then change the properties of the project to .NET 4.5 if you want to. Also all APIs should be usable by themselves without modification.
So do you have a project that is for .NET 4.5 and you're trying to add .NET 4.0 stuff from NUGET or what?
Naturally WinRT projects are totally different from "normal" .NET projects, so they will need converting.
If you're developing Windows Store or phone applications, you'll need updated projects, as it's a separate runtime. It's "4.5", but it's not the standard 4.5 runtime. If you're developing desktop applications using .NET 4.5, you should be able to use .NET 4 (and earlier) assemblies without issue.
The best option here, when possible, is to have the dependencies by a Portable Class Library usable by all target platforms, but this would require the other projects to be designed this way.
Depends on what references you use in your code, if they are untouched by 4.0 to 4.5 conversation then you are in luck, however if that is not case you will need author to update code of project to match 4.5.
Related
I asked this before but if i downgrade to .NET 3.5 I am not able to do some things with the windows form application I get errors because some things that have been added in later versions are not in the version that I am using.
I am making the application for Windows 7.
Link to previous: Can you launch a app C# so it doesn't need the .NET
As C# is essentialy a human-readable version of .NET's intermediate language (IL) you cannot run an application created using C# without .NET runtime installed.
You don't need to downgrade anything - just change target version to 3.5. However, you'll have to stick to features of 3.5 and below in that case.
If you want to use 4.0+ - just make an installer for your app which installs .NET 4.0 runtime alongside.
P.S.
I personally really doubt that there is noticable count of boxes running Windows 7 without at least .NET 4.0.
Just include the required Framework for your application in the Installer. They should be able to run side-by-side.
Currently trying to learn about the .NET Platform Standard I've found myself quite confused about the idea of "different platforms".
I'll try to make my point clear. What I currently now about the .NET Framework is that .NET is roughly speaking made up of the CLR, the BCL and supporting software to boot the CLR and provide the interface between the virtual machine and the underlying OS.
So when we code using the .NET Framework we indeed target some version of the framework because the types we are using from the BCL come with the framework and so depend on the specific version.
Now, .NET Core is quite different as I understood. It is not all packed together like that. We have the CoreCLR which is a lightweight VM to run the IL, the CoreFX which are the libraries properly organized as NuGet packages and we had up to now the DNX/DNVM/DNU which provided the supporting stuff like booting the CoreCLR and interfacing with the OS.
Anyway, despite if we install the framework on Windows 7, Windows 8 or Windows 10, we code against the framework.
Now, on the .NET Platform Standard spec we see the following definition:
Platform - e.g. .NET Framework 4.5, .NET Framework 4.6, Windows Phone 8.1, MonoTouch, UWP, etc.
Also we see after that a list of platforms, which includes
.NET Framework 2.0 - 4.6
Windows 8
Windows Phone 8.1
Silverlight 4, 5
DNX on .NET Framework 4.5.1 - 4.6
DNX on .NET Core 5.0
Now this confuses me completely. I always though: we code against the .NET Framework and the framework is the framework no matter what.
But here we have these platforms which includes the .NET framework as just one of many platforms. We have for example Windows 8, but wait a minute, running .NET on Windows 8 is not just the same thing as running .NET on any other OS? Why it is separate from the .NET Framework 2.0 - 4.6 platform?
We also have DNX as a specific platform. This makes me wonder: the platform is that "supporting stuff" related to booting the Virtual Machine and providing the interface with the OS? Or the platform includes the Virtual Machine?
Anyway, as can be seen I'm quite confused. What are those platforms indeed and how this relates to my current understanding of the .NET Framework? Also, why .NET Framework 2.0 - 4.6 is described separetely? Isn't everything described here some version of .NET Framework unless .NET Core?
we code against the framework.
Well, sure you are. When you manipulate strings in your code then you'll always use System.String. And it (almost) always behaves the exact same way with the exact same methods and properties.
But displaying the string does have implementation details that you cannot really ignore:
If you want to show it in a Unix terminal on Linux or OSX then you need to target Mono or CoreCLR, the framework implementations that can run on such operating systems.
If you want to show it in a Windows Store app (aka WinRT, aka Windows 8, aka UWP) then it is actually a HSTRING under the hood, an very well hidden detail that you don't have to worry about. But does require an UI gadget, like Windows.UI.Xaml.Controls.TextBlock, a class that is highly specific to WinRT
If you want to show it in a browser then you need to target ASP.NET or Silverlight, framework hosts that were optimized to run on a web server or as an add-in for a browser.
If you want to show it on a device that is powered by a small lithium-ion battery, like a phone, then you'll inevitably have to deal with a framework version that was optimized to use as little power as possible. That does affect the code you have to write, there is a huge difference between code that burns 100 Watts and code that keeps a tiny battery alive for 8 hours. Nothing you can directly see, beyond the need to use async/await a lot, but certainly something that affected the runtime very heavily. Targeting Xamarin or WinRT is required.
If you want to show it on any operating system then you do need to target a framework version that does not use the kind of tricks that .NET uses on Windows to have an EXE launch the CLR virtual machine. That requires dnx.exe, just like you'd use java.exe or python.exe for programs written in Java or Python.
It would be lovely if those implementation details did not matter. But not the way it works in practice, as .NET proliferates and becomes available on more and more devices and operating systems it inevitably also becomes more convoluted. Choose your intended targets early, it is important.
There are many Frameworks (.NET Framework, WinRT, UWP, Silverlight, .NET Core, Windows Phone, Mono, Micro Framework und the old Compact Framework) not just only the .NET Framework.
The new way is to program against a platform standard which supports one or more of this frameworks. The platform standard defines an API which matches one or more frameworks. This means if your application supports platform standard 1.1 you will probably support almost all frameworks. Platform standard 1.4 will support .NET Framework 4.6.x and .NET Core only
Have a look at this document: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md
Now this confuses me completely. I always though: we code against the .NET Framework and the framework is the framework no matter what.
No, there are actually plural .NET frameworks or platforms as you like to call them. Prior to .NET Standard, you used to target a single framework (maybe the full one, currently at version 4.6.3, if you develop web applications or windows services). DLLs targeting a framework are not compatible with another one. I.E. a DLL developed for the full .NET framework cannot be executed on Windows phone 8.1.
These frameworks actually implement a quite small common set of librairies, but also specific libraries for dealing with the platform they are intended for. I.E. libraries for managing a web server hosted on IIS in the full .NET framework, or functions for dealing with a mobile phone in the windows phone 8.1 framework.
Before .NET Standard was the PCL
There was although a workaround, called PCL which stands for "Portable Class Libraries". By using only the small common subset of methods/assemblies in two or more .NET frameworks, one could develop a library that could be included in projects targeting different frameworks. For instance, PCL profile 37 means you want your library to be usable in .NET Framework 4, Silverlight 5, and Windows 8 projects.
Please have a look at this for a list of PCL profiles and their compatibilities (I don't know if it's exhaustive): http://danrigby.com/2014/05/14/supported-pcl-profiles-xamarin-for-visual-studio-2/
Now what about .NET Standard ?
The goal with .NET Standard is to simplify this and get rid of PCLs. Roughly, .NET Standard defines a contract (a set of classes and methods), that will be implemented by all .NET frameworks. If you develop a library that targets .NET Standard, you're sure it can run on all .NET frameworks. It's the basic idea/goal behind it (even though it's a bit more subtle).
Have a look at this for the exact compatibility: https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/#user-content-whats-new-in-net-standard-20
If you look at the compatibility table, you'll see that a library targeting .NET Standard 1.6 is usable as is (no need to recompile it) in .NET Framework 4.6.3 and .NET Core 1.0 applications.
In other words, we can say that .NET Framework 4.6.3 and .NET Core 1.0 both implement the .NET Standard 1.6 contract: its classes and methods.
If you also want your DLL to be usable in a windows phone 8.1 project, you'll have to target .NET Standard 1.2, which offers less functions than .NET Standard 1.6 (no System.Net.Sockets for instance).
See here for a list of available namespaces in each version of .NET Standard https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#user-content-list-of-net-corefx-apis-and-their-associated-net-platform-standard-version
I'm working on an old project. It was built by others long time ago, and it was built on .Net 2.0. Now, I need to add a new feature to it. However, coding wise, the new feature is supported by API/Class based on .Net 4.0. Obviously, it has to reference some new dll based on .Net 4. So, I made 2 versions of the program. One is for .Net 2.0 which does not have the new feature, and the other is .Net 4.0.
Now, the project manager asked: is it possible to make these 2 versions into ONE version? so in the code, it detects the .Net version, and then decides whether enable/disable the new feature.
If the user had .Net 4.0 installed, this should not be a problem. HOWEVER, there are some users, they are still using old windows servers which only have .Net 2.0 installed, and because of their work, install .Net 4.0 and reboot the system will be a problem. So, basically, this means the program has to be able to run on .Net 2.0.
Is this possible? How to do it? Any suggestions?
Thanks
****** add more info
I can detect .Net version. but I want to know how to do this:
If on the user's system, it is .net 2.0, run the code supported by .net 2.0 only; if the user's system is .net 4.0, run the code supported by .net 4.0.
Thanks
You need to target a .NET framework when doing a build. You're going to need to create 2 separate builds.
I have a module which is using .Net 4.5 features and our application works for XP users also. So I was thinking of moving this .net 4.5 dependent module to separate project. How can I have a solution which is having two projects targeting to different version?
Each project in a solution is targeting it's specific version of .NET, so there is nothing special to that, BUT you can NOT reference that project/module targeting .NET 4.5 from the .NET 4.0 project.
If you need to target .NET 4.5 for some module your main application must also target .NET 4.5, so if there is no way around that features you need to ditch XP support, which is IMO not a bad thing as XP is not a supported OS anymore.
IF that feature from .NET 4.5 is the async/await-feature you could use the Microsoft.Bcl.Async-package an keep targeting .NET 4.0...
I'm a bit confused about targeting .net 4.0 app to run on windows 8.x. In my understanding, windows 8.0 comes with 4.5 and windows 8.1 comes with 4.5.1. So my question, if I build a WinForms or WPF client app targeting c#/.net 4.0 (in Visual Studio Project settings) and of course only using .net 4.0 features (i.e, no features from .net 4.5.x), then will this app run fine on windows 8.x without having install .net 4.0 framework (that is, only relying on what comes installed with OS)? Basically, I'm trying to avoid forcing end user to install .net 4.0 framework on their machine before running the app.
Looking at DLLs properties of various Microsoft DLLs (e.g., System) they show same runtime version when targeting either .net 4.0 or .net 4.5.x --> v4.0.30319. So my understanding here is that 4.0 and 4.5.x are targeting same clr runtime version So, my .net 4.0 app should run fine???
From ref here (http://msdn.microsoft.com/en-us/library/bb822049%28v=vs.110%29.aspx), it says .net 4.0 can't even be installed on win8.x.
In my tests, targeting .net 4.0 and running on clean install of win8.1 seems to work fine (without having to install anything else) but looking for advice on gotchas.
Thanks.
Note that the .NET framework is intrinsically backwards compatible - .NET 4.5 will execute .NET 4.0 code just fine. This can be seen even within a solution in that a .NET 4.5/4.5.1 project can reference an older .NET project without incident. This includes .NET 4.0, as well as earlier versions.
In addition to the backwards compatibility, .NET 4.5 does run on the CLR 4.0 - 4.5 is simply a library and compiler expansion.
Possible gotchas
This emphasis on backwards compatibility is why we almost never see functions disappear from the .NET Framework, just get marked [Obsolete]. it's a good idea to check if any functions you use have become Obsolete, though this is rare and such functions usually continue to work as expected.
Windows 8 does NOT like Drive mapping, and will demand that you use UNC paths if you application touches any networks drives.
Windows 8 can be far more aggressive with requiring Admin privileges to run, up to and including needing to explicitly start VS as admin when trying to compile a program which outputs to C:\Program Files\...
Final note: ALWAYS test your application on the targeted platform before releasing to users.
Per this question:
.NET Framework 4.5 was released on 15 August 2012., a set of new or improved features were added into this version. The .NET Framework 4.5 is only supported on Windows Vista or later. The .NET Framework 4.5 uses Common Language Runtime 4.0, with some additional runtime features.
I would say then that by virtue of having .NET 4.5 installed you will also always have .NET 4.0 installed. I don't think this should be an issue then!
From the link you posted:
Each new version of the .NET Framework retains features from the previous versions and adds new features.
Also from that link:
The .NET Framework 4.5 is an in-place update that replaces the .NET Framework 4 on your computer, and similiarly, the .NET Framework 4.5.1 4.5.2, and 4.6 Preview are in-place updates to the .NET Framework 4.5, which means that they use the same runtime version, but the assembly versions are updated and include new types and members.
So, if a system has 4.5, it will be able to run apps targeted for 4.0 as well. The fact that some versions cannot be installed most likely only means that they are already included from the start.