A set of UserControls I've developed for in-house use were written in .NET 2.0 but my current development is in .NET 3.5. Assuming the following:
no need to update these controls in my 2.0 projects
there are no 3.5 features I need in my library
Is there any advantage at all (beyond satisfying a misplaced sense of tidyness) for me to update my control library to 3.5?
I believe even if a machine using my controls doesn't have the .NET 2.0 runtime installed, my library will run fine if it has the 3.5 runtime.
The only reason to bring them to 3.5 would be the tidiness concern. Otherwise they will work just fine with .NET 3.5 in every other aspect. Keep in mind that 3.0 and 3.5 were library extensions to 2.0. I.e. They run top of 2.0. (Things changed with 4.0 however.)
Related
I have created my first WPF project and it is written in .NET framework 4.7.2
I have NO idea about the importance and functionality of this however I want to be able to install it in a few businesses with as little chance of them needing to install a new framework. Perhaps that isn't important and I should just include it in the installer, but that is what I am not sure of.
I tried rolling back to 4.5 .NET however now one of my packages will not install on that framework.
Install-Package : Could not install package 'FluentEmail.Mailgun 2.8.0'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.6', but the package does
not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
If I do any framework lower than 4.7.2 I can't see to run this, however I can't find documentation referring to this needing a specific framework to run.
Any pointers in the right direction would be helpful,
eg. Is the framework important for a basic WPF app not using any crazy tech, just a few API's and mainly data storage?
Can I force this package to install on an earlier based framework or is that going to fail?
The FluentEmail.Mailgun package targets .NET Standard 2.0 which you can see by expanding the Dependencies section at NuGet.org.
.NET Standard 2.0 is implemented by .NET Framework 4.6.1 and later which you read from the compatibility matrix in the docs.
This basically means that you need to target at least 4.6.1 to be able to consume the package in your app.
There is a caveat though:
While NuGet considers .NET Framework 4.6.1 as supporting .NET Standard 1.5 through 2.0, there are several issues with consuming .NET Standard libraries that were built for those versions from .NET Framework 4.6.1 projects. For .NET Framework projects that need to use such libraries, we recommend that you upgrade the project to target .NET Framework 4.7.2 or higher.
So if you are developing a new app, you are recommended to either target .NET Framework 4.7.2 or later or even better .NET Core 3.1 or .NET 5.
If you want the full story of which versions that are officially supported on which operating systems, you should refer to the lifecycle FAQ in the docs.
Targeting 4.5 doesn't make much sense since the support for it ended back in January 2016.
I want to develop a general project, the desktop application must be .Net Framework and I will use EF Core 5.0 in the background and the libraries must be .net standard so that they are compatible with xamarin and Asp.net Core. Everything is fine, but the net framework does not support 2.1. How do I overcome this problem?.
NET 5.0 desktop toolbox has problems. I am someone who uses Devexpress and it does not come out in vehicles. I asked Devexpress and they said they have microsoft-side problems. I didn't know what to do. Syncfusion components do not look the same, unfortunately :(
You have to develop Winforms application using .NET 5. It is replacement of .NET Framework which become deprecated.
https://learn.microsoft.com/en-us/dotnet/desktop/winforms/?view=netdesktop-5.0
I have a standard WPF application developed in .Net framework 4. Now, my client wants a website which I am planning to develop using .Net Core. In order to share the business logic, I need to move the database along business layer to a separate project and here I am planning to use .Net Core. So, all the layers i.e. Data/ Business/ API will be re-written using latest version of .Net Core.
Would I be able to reference business layer written in .Net Core from WPF (.Net Framework 4) project?
Any pointers will be highly appreciated.....
You should implement the common functionality in a .NET Standard library. You will then be able to reference this assembly from all apps that are compatible with the version of the .NET Standard that your common project targets.
The various .NET implementations target specific versions of .NET Standard and the following table on MSDN lists all versions of .NET Standard and the platforms supported: https://learn.microsoft.com/en-us/dotnet/standard/net-standard.
The latest version of .NET Core (currently 2.0 at the time of writing) implements .NET Standard 2.0. The oldest version of the .NET Framework that implements .NET Standard 2.0 is 4.6.1. This means that your WPF app should target 4.6.1 to be able to consume a .NET Standard 2.0 assembly.
.NET Core 1.0 and .NET Framework 4.5 support .NET Standard 1.0.
The .NET Framework 4.0 doesn't support any version of .NET Standard though so you should re-target your WPF app against (at least) .NET Framework 4.5.
Would I be able to reference business layer written in .Net Core from WPF (.Net Framework 4) project?
The answer is yes. You can try it: In Visual Studio create a WPF application project and a .NET Standard library project and then add a reference from the application project to the library project.
There will be NuGet packages that you cannot reference in your .NET Standard project because they only support full .NET Framework but most popular NuGet packages can be referenced from a .NET Standard project. Your question is also tagged [entity-framework-6]. If you want to use Entity Framework from a .NET Standard project you will have to use Entity Framework Core as Entity Framework 6 requires the full framework.
You should probably create a quick spike to determine if you can build your application how you intend to.
I am building a windows presentation form application. The issue I have is that my co-workers have different versions of .net installed on the desktops. If I build it on my machine which has .net version which is 4.6. When another person has a lower version of .net it fails. I can build the application multiple time with different version of .net but I would like to avoid that. So is there a way in Visual Studio to build a WPF that will work on multiple platforms and versions of .net?
You can change your target framework in the project properties (right click the project and select Properties):
Because higher .NET versions are backwards compatible with earlier versions, you can target a lower version that what is on your machine, though it means that you lose out on the newer apis.
So, for example, if you and your colleagues decide that .NET 4.0 is a good target, then having .NET 4.5 or .NET 4.0 will work for building and running the application.
For more information on Framework Targets, see:
What does it really mean to target a framework, and how do I maximize compatibility?
What is the effect of setting a “Target framework” in Visual Studio
I have an application, which I develop in VS 2008 and I target .NET 3.
Unfortunately when I install on a clean computer with .NET 3, it crashes. And besides the usual TypeInitilisationError, I have no clue why.
Updating the same machine to .NET 3.5SP1 makes it run fine.
Is there something broken in VS2008 that prevents from telling me a more detailed error?
How can I be sure I don't use any of the newest classes of the framework?
It is true that I found myself using DropShadowEffect which belongs to 3SP1. I removed it.
But still...it does not work.
What am I doing wrong?
Have you tried to determine which version of the framework is installed on each computer. If you're using .Net 3.5 SP1 to compile the program it actually includes .Net 3.0 sp2 which has some extra features (MultiSelector class to name one) which are not available in .Net 3.0 sp1 which is the default install with .Net 3.0 download from Microsoft.
You can try here for some software that will help:
NetVersionCheck
EDIT:
Visual Studio won't tell you about any errors for this because everything seems fine with the version of .Net 3.0 that it's using. I ran into this problem using the WPF toolkit as it requires the MultiSelector class which didn't arrive until .Net 3.0 sp2. So, Jonathan, if you can show us the error output from your program on the 'Fresh' .Net 3.0 computer then we could probably tell you what you're using that is in .Net 3.0 sp2 that isn't supported in lower versions.
Also, I usually use VS2005 with programs that I want to run under a lower runtime than .Net 3.5sp1, but this really only applies to .Net 2.0 apps.
If we knew what components from .Net 3.0 that you're using, it would help as well!
Noah
Thanks for the answer.
Because of VS2008, on my dev computer i have the latest 3.5SP1.
But in Visual Studio i selected 3 as a target.
And to check i install on a clean computer with 3.0...
So your proposition do tells me which framework is installed, but does not tell me what in my program uses in the newest framework that is not present in 3.0.
Moreover, something must be broken in VS2008 as it should warm me for that...
I feel like this is a problem with VS 2008, but obviously MS feels differently.
VS 2008 comes with .NET 3.5, some .NET 3.0 service pack, and .NET 2.0 SP1. It can only detect whether you are using things that don't belong to a version that is installed on your machine, not whether you are conforming to some service pack. This means that if you target .NET 2.0, but install your software on a machine that does not have .NET 2.0 SP1, if you use anything specific to SP1 your application will fail when it tries to make the call.
The only way to detect this that I have seen is to inspect the changelist of the service packs or to target .NET 3.5. If .NET 3.5 is installed, so are the service packs that come with it. It's not a good solution, but it's the only one I've found.