I'm new in the .NET-world.
I just built my first application with .NET-versionn 4.0 and am wondering if its a wise choice to lower the target-framework as much as possible (to 3.0 maybe) if it still works then.
Whats best-practice when it comes to choosing the appropriate .NET-version?
If you are targeting Windows desktop users, you can be pretty confident they have at least .NET 2.0 and probably higher. It is unlikely they will have .NET 4 though. Unless you know the audience (eg. a business customer), choosing .NET 4 will likely limit your reach at this point.
.NET 4 introduces the first real platform change in a while in that it is built on the CLR (Common Language Runtime) version 4. Before that, .NET 2.0, 3.0, and 3.5 all ran on version 2 of the CLR.
The only difference between .NET 2.0, 3.0, and 3.5 are the in the framework (the libraries). Most of the libraries are unchanged but new libraries where added with each version. It depends what libraries you use. If you include all the libraries you need in your application then you can run anything that .NET 3.5 can do on .NET 2.0.
If you need a legal way of distributing .NET 3.5 era libraries to a .NET 2.0 audience, one option is shipping some assemblies from the Mono Project.
For example, you might find that the only .NET 3.5 assembly you need is System.Core.dll. If you include the Mono version of System.Core.dll with your application, it will run just fine on .NET 2.0 and up even though you are using ".NET 3.5" features (like LINQ for example).
If you are using ASP.NET then it really does not matter what they have as you are just feeding them HTML.
EDIT: I was not aware that Windows Presentation Foundation (WPF) required a service to be running. I have used Mono to add .NET 3.5 features to .NET 2.0 apps but I have not used WPF.
You cannot get the WPF assemblies from anywhere but Microsoft though so you cannot redistribute those anyway. Mono projects tend to use GTK# for the GUI although Windows Forms is also available cross-platform.
Choosing the framework version to support is mainly a question of your target user group.
If you are developing a tool for a
corporate environment, you might be
limited by the framework version that
the default configuration of the
corporation supports (which sometimes
might be a version or two behind the
latest version) - or you are lucky
and the IT department is willing to
upgrade their platform to the latest
version.
If you are targeting home users you
should consider that not everyone is
already having the latest framework
version installed, and not every user
is willing to download and install a
new version just to use your tool. So
you need to consider if you can allow
to ignore such users or not.
Of course, you can always include the latest version with your setup, but don't forget that the framework installation requires administrative rights.
Related
I'm reading a book from Mark J Price, where he states:
Since .NET Framework 4.5.2, it has been an official component on the Windows operating system.
vs
.NET Core is fast-moving and because it can be deployed side by side with an app, it can change frequently.
I don't really get this. Whether I use one or the other, I do still need to install the SDK and runtime for both of them? So what does he mean?
In all cases you only need the (partial) runtime to run, not the SDK. The SDK is only for development.
As for the rest:
on some operating systems a .net version is available by default. These versions can change beteen OS (Windows) versions. You'll need to see which version is applicable for you.
.net core (and it's follow up .net 5+) is not always standard available on the OSses. But .net core (and .net 5+) offers the ability to include the required runtime components in the build. This will increase your build by approx. 140 MB, but you can be sure you have all the required prerequisites.
You can pick whatever suits you best but be aware of the end-of-life-dates of the framework: .net, .net core, .net 6+.
For version 4.5.2 specific:
.NET Framework 4.5.2, 4.6, and 4.61 retire on April 26, 2022.
So I wouldn't start developing new applications with that version.
As mentioned by #MAtthewWatson, more info on the single file publishing (which includes the runtime), see: this link.
Captured image in case the link will change:
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).
TL;DR:
Given: I wrote a library with relatively portable functionality (for example, Left.Pad.©.dll). I want to make it available though NuGet.
Requirement: If somebody wants to use my library on any version of any platform on any version of any operating system with any updates installed by writing code in any IDE or any code editor, they should be able to do it.
Question: What is the minimum set of NuGet target frameworks to achieve that?
Bonus question: If there're any "dead" frameworks which shouldn't be targeted, or something else which should be taken into consideration when choosing target frameworks, you can mention it too.
Thoughts (old version):
NuGet packages support multiple .NET Framework versions and profiles, for example, a package can provide net20, net30, net35, net40, net45, sl3, sl4, sl5 etc. versions. However, assuming there aren't always differences in the functionality of a package, providing a lot of versions would be a waste of build time and package size and cause unnecessary complexity. On the other hand, providing a package just for the lowest supported Framework version could cause missing functionality, for example .NET 4 supports in-process side-by-side execution of multiple CLR versions, but previous versions don't, so this feature will be lost if just a version for .NET 3.5 is provided (I'm not sure; I've never used it and don't know the details). If a PCL version is provided, the logic is simple I assume: just exclude versions which PCL covers.
At the moment of writing, the easiest way is to create a .NET Standard 1.1 project. It supports
.NET Core 1.0 and higher
.NET Framework 4.5 and higher
Mono, Xamarin, Windows Phone and more...
So pretty much all of the modern platforms. If you want to support older platforms, ex. .NET Framework 3.0, add this as a separate "folder" in NuGet. This way, newer .NET Core applications can still use your package.
More information
.NET Standard acts a replacement for PCL. The lowest .NET Framework you can target with PCL is 4.0, which isn't much lower than 4.5 with .NET Standard 1.1 (thus won't make your package much more accessible).
PCL also doesn't seem to support .NET Core, while .NET Standard nearly supports all platforms:
Also note that according to Microsoft, only .NET Framework 3.5 SP1 and .NET Framework >= 4.5.2 are currently supported. All other .NET Framework versions already reached end of life and won't get any updates. Windows Phone is also dead and Silverlight isn't getting anywhere too.
As #Lex Li mentioned in the comments, .NET Standard 1.1 has a very low API surface, which means there are maybe some important APIs missing. Because of that, most NuGet packages use a higher .NET Standard version. It is recommended to use the lowest .NET Standard version possible.
So with .NET Standard 1.1, you will support a huge majority of the modern frameworks. Sadly, I couldn't find any .NET Framework distribution statistics...
If you really want to make your package available for every platform, take a look at the possible target platforms for NuGet. I think you need atleast net11 and netstandard1.0, maybe add some Silverlight and .NET MicroFramework support...
Solution of 2018
Based on given asnwers and assuming no dependency on platform-specific technologies (like System.Drawing, ASP.NET or WPF; in which case just target the platform you can and be done with it):
netstandard1.0—netstandard2.0 Start with .NET Standard 1.0 and go up until you reach maximum functionality.
This should cover:
.NET Framework 4.5
.NET Core 1.0
Mono 4.6
Xamarin.iOS 10.0
Xamarin.Android 7.0
Windows Universal 10.0
Windows non-Universal 8.0 (up to .NET Standard 1.2)
Windows Phone 8.1 (up to .NET Standard 1.2)
Windows Phone Silverlight 8.0 (up to .NET Standard 1.0)
If you can't reasonably implement the library within the limits of relatively small .NET Standard 1.0–1.2, the last three points are likely to be excluded. If you still need them, see points below.
.NET Standard 1.5+ increases the requirements on the versions of the frameworks and operating systems, so multi-targeting .NET Standard versions may be required for maximum compatibility.
portable-net40+* The next major point is obsolete PCL. Its .NET Framework 4.5+ versions aren't relevant as they're mostly covered by .NET Standard. If you want to support Windows Phone 8 and non-Universal Windows Store 8, you should do it through PCL, unless you're limited by API, in which case you'll have to add platform-specific targets.
If you don't need any of additional platforms and .NET Framework 4.0 provides some useful additional functionality over .NET 3.5, you can target it directly, not through PCL.
This should cover:
.NET Framework 4.0
Windows non-Universal 8.0
Windows Phone 8.0
Windows Phone Silverlight 8.0
net20—net35 If you want to support ancient desktop Windows versions (like Windows XP) and unupdated more recent Windows versions (like Windows Vista+ with .NET 3.0+), you should add support for desktop .NET Framework targets directly. Note that as of 2018-01-01, the lowest supported .NET is 3.5 SP1, so going lower than that is probably unnecessary and will likely limit API available to you too much with no real benefits.
This should cover:
.NET Framework 2.0-3.5
Windows XP
There're other platforms, namely Xamarin-specific ones, Tizen, .NET Micro etc. They can be accessed only by targeting them directly.
This should cover:
Everything else
TL;DR
Something like netstandard1.1+portable-net40+win8+net35 covers every relevant platform.
Solution of the future
When old .NET versions completely die, only .NET Standard should remain. Well, unless Microsoft invents yet another cross-platform unification technology, like it already did with .NET, .NET PCL, .NET Standard...
TL;DR
Use the lowest netstandard you can.
You should target .net framework 2.0 and above. The decision should be based on the platform the application will run in production.
.net 2.0 comes included in Windows 2008 server (SP2 and onward) and people still use it extensively in production.
Ref https://en.wikipedia.org/wiki/.NET_Framework
If you want it to be used not only on Windows - .NET Standard is the way to go. Target latest as question of what libraries to use comes early in a project and is rarely revisited and new projects tend to use recent versions of frameworks and libraries.
What .NET Standard versions are supported by what versions of other frameworks (GitHub).
What .NET Framework versions are supported by which Windows Server versions (MS Docs).
Server version share in SpiceWork network. It is not a representation of global data, but it's best data I found to get idea of Windows Server market share.
Info on Linux prerequisites for .NET Core versions (MS Docs).
You can find recent market shares of user devices based on internet usage easily.
See the numbers, pick platforms you want to reach and cross-reference it with which versions of .NET are available on them.
Targeting .Net Standard would give your nuget package the luxury of being employable in .NET framework ,.NET core, mono, Xamarin, Universal Windows Platform, and Windows Phone projects.
See the following taken from this answer
To decide which version of .Net standard you should target use the following table:
Source.
Looking at the above table I would recommend going with .Net standard 1.0 if you care about Windows Phone Silverlight or .Net standard 1.2 if you do not.
Also, as far as I noticed lots of people that chose .net core are actually using .net core 2.0 so you might want to create a seperate nuget version for them with .net standard 2.0.
About the second part of your question, even if a specific framework is dead that does not mean that it would go away instantly, it would be still used for several years before it is completely dead, simply moving to different options takes time.
Another thing that I would take into consideration is the common used libraries, like Masstransit, EPPlus, and the commonly used IOCs, etc.. I would take a general look on the frameworks supported by them and follow because many undergoing projects might be driven by such libraries.
We distribute a .NET 3.5 assembly to more parties to be referenced and used in different applications.
We are now intending to upgrade this assembly to .NET 4.6 so it will benefit of all performance and security improvements in this .NET version and not for using new .NET features.
But we don't want to break existing applications that are using it.
Some consumer applications might still be using .NET 3.5 so they won't be able to use it, so I was thinking how about having two projects targeting two .NET versions (3.5 and 4.6), but same code files.
What would you recommend for maintaining and distributing one assembly code base for both .NET 3.5 and .NET 4.6 version lines?
Later Edit: This question is not about referencing a .NET 4.6 assembly in .NET 3.5, it's about how can a .NET 4.6 application to use my assembly and benefit of the security and performance of .NET 4.6 while running it. The 3.5 apps should continue to use my 3.5 assembly.
Look into creating your own nuget repository and publish the libraries in each specific version of .net needed. (For one package can have varying .net versions as needed).
Once in your nuget repository they have their own version and can be updated either in lockstep or differently. That way the consumers can use the target version as needed for the target .net version.
See Hosting Your Own NuGet Feeds
There seem's to be an assumption that an identical code base compiled in .Net 4.6 will gain "performance and security". This isn't true. If the codebase is identical it will perform identically and the security will be the same.
Each iteration of .Net contains the previous one (it's actually a monolythic process that Microsoft are trying to move away from, hence projects such as Katana)
Each new version of the .NET Framework retains features from the
previous versions and adds new features.
source
Simply upgrading the framework will not magically make you code faster or more secure.
At a previous company we used to do as you are suggesting and ship a .NET 3.5 version (for users on XP) and a .NET 4.0+ (up to 4.5) version.
The way we did this was to have two separate solutions basically called the same and have each of the projects mirrored from the .NET 4.0 version into the 3.5 version. These were actual projects added to the solution.
For the files we simply linked the .NET 4.0 files directly into these projects, but we did have to manually create each folder so that the namespaces matched. For any code that was not supported by .NET 3.5 we had to create an actual file in the 3.5 solution and re-write entirely that feature so that it would compile with 3.5.
This was not fun and actually wasted a lot of development time simply looking after a legacy solution. In the end we migrated everything to .NET 4.5 and expressed to users that we were discontinuing support for the 3.5 version, for us there was not cost for the user to upgrade so it was up to them if they wished to upgrade hardware for new functionality.
In conclusion I would say if you don't need to I would recommend that you don't attempt to support both solutions, it will impact your development time and frustrate developers when they've written this nice feature using the concurrent functionality to then realize this isn't in .NET 3.5 (I know what this is like because I've had it happen).
Hello friends i need an explanation regarding .NET framework pre-requisite while installing the published application in the target machine.
As java is downward compatible, by which i mean that if i have installed java v1.6 and if the application is developed using java v1.5 (i also mean that only classes and packages available in 1.5 are used to build the appln.)
I am sure that the application developed will definitely run by installing the latest or higher versions of jre or j2se.
Similarly in the case of .NET platform suppose if i develop my application using .NET framework 3.5 and in the target machine i have installed .NET framework 4.0 (the latest) even then it prompts to install the .NET framework 3.5 why is this so?
The real time example is i have downloaded and tried installing MySQL workbench and also installed .NET framework 4.0 But it still asks to install the .NET framework 3.5 before running the MySQL installation.
My question is does .NET framework is downward compatible as java or .NET?
Version Compatibility in the .NET Framework:
The .NET Framework 4 is
backward-compatible with applications
that were built with the .NET
Framework versions 1.1, 2.0, 3.0, and
3.5. In other words, applications and components built with previous
versions of the .NET Framework will
work on the .NET Framework 4.
However, in practice, this
compatibility can be broken by
seemingly inconsequential changes in
the .NET Framework and changes in
programming techniques. For example,
performance improvements in the .NET
Framework 4 can expose a race
condition that did not occur on
earlier versions. Similarly, using a
hard-coded path to .NET Framework
assemblies, performing an equality
comparison with a particular version
of the .NET Framework, and getting the
value of a private field by using
reflection are not backward-compatible
practices. In addition, each version
of the .NET Framework includes bug
fixes and security-related changes
that can affect the compatibility of
some applications and components.
If your application or component does
not work as expected on the .NET
Framework 4, use the following
checklists.
For .NET Framework 2.0, 3.0, and 3.5 applications:
Check .NET Framework 4 Migration
Issues for any changes that might
affect your application and apply the
workaround described.
If you are recompiling existing source
code to run on the .NET Framework 4,
or if you are developing a new version
of an application or component that
targets .NET Framework 4 from an
existing source code base, check
What's Obsolete in the .NET Framework
for obsolete types and members, and
apply the workaround described.
(Previously compiled code will
continue to run against types and
members that have been marked as
obsolete.)
If you determine that a change in the
.NET Framework 4 has broken your
application, check the Runtime
Settings Schema to determine whether
you can use a runtime setting in your
application configuration file to
restore the previous behavior.
If you encounter an issue that is not
documented, file a Microsoft Connect
bug and contact netfxcf#microsoft.com
with the bug number.
Yes, .Net 4 framework is backwards compatible with applications built on previous versions of .Net. You can see this link on MSDN for more info.
If you have .Net 3.5 or .Net 4 installed and a third party still requires either (or and older version) then the installer is not checking the correct prerequisite install conditions.