I made the big mistake of taking some NuGet library updates today. It forced me to either roll back a week's worth of work or upgrade to ASP .NET Core 3.0. I hate to use stuff that's not production, but I didn't want to untangle the libraries either, so I upgraded. Then it forces me to retarget .NET Standard 2.1 libraries. Which I did.
My problem now is with the client UWP code. When I try to compile, I get:
error : Project '..\ClassLibrary1\ClassLibrary1.csproj' targets 'netstandard2.1'. It cannot be referenced by a project that targets 'UAP, Version=v10.0.10586'.
This happens even with a virgin UWP and .NET Standard 2.1 library. Any clues on how to make Visual Studio 2019 client code work with the latest upgrade?
All Windows 10 SDKs currently don't support .NET Standard 2.1.
Windows 10 19H2 is using the same SDK number as 19H1, so it is unlikely that it will support .NET Standard 2.1. (But I certainly hope it does.)
Microsoft hasn't made an official announcement, but Windows 10 20H1 is getting a meaningful SDK update, so it is likely that it will support it. And once that's the case, UWP apps will require 20H1 to run (so that will become the minimum supported version).
One of the big issue with this situation is that Entity Framework Core 3.0 requires .NET Standard 2.1, so it can't be used in UWP apps for now (Update: This issue is resolved with Entity Framework Core 3.1 supporting .NET Standard 2.0).
By the way, as an experiment, I was able to fork Entity Framework Core 3.0 (for SQLite) and make it compile on .NET Standard 2.0. I basically had to manually copy a few new APIs from .NET Core 3.0 (like IAsyncXXX). And it worked, so it is an option for people who really need it. Note that, I did not try it with the SQL Server provider.
Update: The UWP team is planning to enable UWP apps to use .NET 5 and that's when UWP will support .NET Standard 2.1 (and more). This could happen in 20H2 or 21H1.
UWP does not support .Net standard 2.1 yet. It only support till .Net standard 2.0 and that too from windows 1709 onwards.
If you look at the link for 2.1 it states
Platform Support
An upcoming version Universal Windows Platform
so it may be 19H2
UPDATE
Microsoft is going to release a new framework called WinUI 3, this is going to support UWP as well as Win32 based application model. WinUI 3 would support .Net 5 for both the platforms. WinUI 3 preview is going to be available in mid May 2020, with final release in late 2020. WinUI 3 would be supported on windows 10 1803+.
Related
I used to program in .NET 4.7.2 (and still do), but my High School uses .NET 6
Currently we have started using C# console in .NET 6
I don't want to update to .NET 6 because i would also have to change my Unity editor version to one that supports VS2022
Is it possible to open .NET 6 projects in .NET 4.7.2, or am i gonna have to update Unity and reinstall VS, while scouring every part of my C:// partition to clean up junk/leftovers? I am very tight on free space especially on C://
No, you can't (if you mean anything more then editing text, cause for this you can use even notepad). But depending on language features used potentially you can copy-paste code into a .NET Framework 4.7.2 project and compile it. Or not, cause at least some newer features are not supported by older framework version.
Also you don't need full blown VS upgrade. You can look into installing just the .NET 6 SDK and VS Code (which requires less space compared to VS 2022).
Though I hugely recommend to extend your disk.
I have visual studio 2015 professional editton, and i want to create my first MVC web application which should be a .net core. now i am watching an online learning demo, which mentioned to create this project:-
while inside my visual studio i have these options:-
so which option i need to chose?
second question, how i can be sure that i am using the latest version of MVC?
Thanks
First, there is no such thing as MVC 6. It's ASP.NET Core. Second, the decision of whether to use .NET Core or .NET Framework comes down to what you need to do. .NET Core is cross-platform (Windows, Mac and Linux), whereas .NET Framework is Windows-only. .NET Core is also lighter weight, faster, and has a number of new CLR features, compared to .NET Framework. Virtually the only reason to use .NET Framework is if you have a dependency on something that utilizes Windows-specific APIs, meaning it can't be run cross-platform. Otherwise, you should always use .NET Core, if you can get away with it.
ASP.NET Core is really just a collection of NuGet packages, and like other NuGet packages, they can be updated easily. However, the difference is that these NuGet packages are generally tied to a particular version of .NET Core, and thus, the appropriate version of the packages are installed based on which version of .NET Core you're targeting. For example, if you're targeting netcoreapp2.2 then you'll see that that packages like Microsoft.AspNetCore.App will be brought in with versions like 2.2.x.
So, to answer your question about staying up to date, it essentially entails installing the latest version of the .NET Core SDK, and then changing your project to target that new version. Then, all the ASP.NET Core NuGet packages will naturally update accordingly.
I am building an F# console application with Visual Studio 2013 Ultimate. The target framework is .Net 4.5
The version of FSharp.Core installed on my computer (presumably by installing VS 2013) is 4.3.1.0.
On NuGet there are two versions of FSharp.Core, 4.0.0 published April 12, 2012 and one with an ID of Fsharp.Core.3 verison 0.0.2 published March 5, 2013.
I am looking for guidance as to when one should use each of these versions, the version numbering is confusing me and I would have expected to find the latest production release on NuGet.
Am I missing something?
You should not be obtaining FSharp.Core from nuget. Microsoft does not publish any official F# bits to nuget today (though this could potentially change in the future). It's common for 3rd-party packages to bundle FSharp.Core (since presumably that's the version used for testing/validation of that 3rd-party component), but nuget should not currently be used as a mechanism for getting FSharp.Core updates or new versions.
The versioning story for FSharp.Core is sadly rather complex, and definitely not as simple as "higher version means newer." A key thing to realize is that there are 2 axes - what F# version does the runtime support, and what .NET framework version/profile does it target.
Below are the official FSharp.Core versions that ship with VS 2013 (find these dropped under %ProgramFiles(x86)%\Reference Assemblies\Microsoft\FSharp).
4.3.1.0 (F# 3.1/.NET 4) This is the most recent official version. Unless you have a requirement to target .NET 2, or you are using some legacy F# component that won't work with 3.1, this is the version you should use for any new desktop app.
4.3.0.0 (F# 3.0/.NET 4) These are the same bits that shipped with VS 2012. It is included so that you can continue working on F# 3.0 projects in VS 2013 without retargeting them to 3.1. You should use this if you have a legacy F# 3.0 desktop project that you are not ready to move to 3.1 yet.
2.3.0.0 (F# 3.0/.NET 2) These are the same bits that shipped with VS 2012. The only reason to use this is if you are targeting .NET 2. The .NET 2 side of things is not being developed further, btw - new features, versions, etc will be done for FSharp.Core targeting .NET 4+; the .NET 2 FSharp.Core is still fully supported, but it is frozen.
3.3.1.0 (F# 3.1/"Portable") This version targets .NET portable profile 7 (.NET 4.5/Windows Store). Use this if you are creating a component for a Windows store app and you don't care about Silverlight. This profile is newly supported in VS 2013.
2.3.5.1 (F# 3.1/"Portable (Legacy)") This version targets .NET portable profile 47 (.NET 4/Silverlight 5/Windows Store). Use this if you are creating a Silverlight component. This profile was also supported in VS 2012, and referred to at that time as simply "Portable."
2.3.5.0 (F# 3.0/"Portable (Legacy)") This version targets .NET portable profile 47 (.NET 4/Silverlight 5/Windows Store). These are the same bits that were included in VS 2012. Included in VS 2013 to enable you to continue working on F# 3.0 portable/silverlight projects.
.NET portable profiles are a big PITA and cause a ton of complexity. This site has a good summary to help understand: http://blog.stephencleary.com/2012/05/framework-profiles-in-net.html
So for your specific scenario (new console app) use 4.3.1.0.
Edit 7/2015:
Here's a table that probably explains the story better than the wall of text above. I've tried to use colors to indicate the motivation for the version numbers. You'll see the versioning of the portable libraries was a bit ad hoc and inconsistent in VS 2012 and 2013, but is finally consistent and predictable starting with VS 2015. This is up to date with F# 4.0, which just released.
Today I would probably rather follow these guidelines
In short, you can/should reference FSharp.Core from NuGet
We have a large system of .net framework 3.5, but seems that z3 4.0 C# API is only meant for .net framework 4.0. Is there anyway for our system to use that API without upgrading the .net framework version currently (it is quite hard to do so)?
The current code for the .NET interface requires .NET 4.0 because it depends on some features that were first introduced in this release (e.g., System.Numerics and System.Collections.Concurrent). Upgrading to 4.0 should not be a major problem though, and it is only required for the top-level application as it should be backwards-compatible with other components that were compiled for the 3.5 framework (with few exceptions, see MSDN .NET version compatibility).
If your code does not require BigIntegers, it would be possible to work around these issues for us; I could create a "special edition" just for you. There is some effort involved with this though, and there would be no future updates, so we should only consider this if it is absolutely necessary.
We are currently looking into the possibility of releasing the source code of the .NET API, so in the future such adapdations and modifications can be done by end-users themselves. Until that is the case, I would request interested users to contact myself directly so we can discuss "special editions" on a case-by-case basis.
I have searched various online resources and found conflicting information about the possibility of ASP.NET MVC 1.0 web apps running against the latest build of Mono (2.4.x). According to the Mono site, ASP.NET 2.0 is supported. According to Microsoft, ASP.NET MVC 1.0 requires the 3.5 version of the framework. From what I've read, ASP.NET 3.5 makes use of the 2.0 framework under the hood.
Has anyone got an ASP.NET MVC 1.0 web app running on Linux with Apache using mod_mono ?
Thanks
Yes, though you'll want to update the latest bugfix release for best compatibility. Note that Mono 2.4.2.3 actually includes the real ASP.NET MVC library, which was open-sourced by Microsoft under the MS-PL license.
The relationship between .NET and Mono version numbers is very complicated, as there is no direct mapping between .NET versions and features that Mono has implemented. .NET versions aren't exactly straightforward either, as 3.0 was simply additional assemblies added to the 2.0 framework, and similarly, 3.5 is additions to the 2.0SP1 framework - and the 3.5 assemblies do not depend on the 3.0 ones.
Mono features are driven by demand, using data collected using the Mono Migration Analyser.
For example, Mono has supported core .NET 2.0 features like generics since 2005 or so, but only with Mono 2.0 were the Windows Forms 2.0 and ASP.NET 2.0 components considered feature-complete - except for Web Parts, which will likely never be implemented due to low demand. And there are a couple of very Windows-specific features, like System.Management, which will also likely never be implemented as they simply cannot be mapped to non-Windows systems. Apart from such caveats, 2.0 support is now very complete.
Mono 2.0 also included full C# 3, LINQ-to-objects and LINQ-to-XML support, which are features from the .NET 3.5 framework. With Mono 2.4, the ASP.NET 3.5 features are essentially feature complete, and the only major missing 3.5 feature is LINQ-to-SQL, which should be in Mono 2.6. However, there's still no support for the .NET 3.0 assemblies - WCF, WPF, WF. WCF is being worked on but there are no plans for WPF at this time - some degree of WPF compatibility is provided via Moonlight, the Silverlight implementation.