I have an application that we are going to upgrade from .net framework 4.6 to .net 6.
However one class library has to be run in .net 5 because of limitations in a Linux version that we have to use.
So I wonder if it is possible to use the .net 5 library with .net 6?
I tested experimentally on a simple case. The .NET6 app referencing .NET5 library could be built without any warnings or errors and ran without runtime problems:
Some related quotes from Microsoft Docs:
If you're using libraries to break down an application into several components, we recommend you target net5.0 or net6.0. For simplicity, it's best to keep all projects that make up your application on the same version of .NET. Then you can assume the same BCL features everywhere. (...)
To me, this sounds like a good practice to have everything on the same version (5 or 6), but not like a strong requirement.
I'm not 100% confident about edge cases, however. I couldn't find any confirmation of compatibility. At the moment, I would hesitate running a complex production app built from components mixing 5 and 6.
Related
If I have a .NET Standard 2.0 library project that is being consumed by a .NET 6.0 console project, are there any performance benefits if I also instruct the compiler to produce a .NET 6.0 version of the library?
I don't plan to use any functionality available on .NET 6.0, I just want to know if the .NET 6.0 version receives extra-love from the compiler.
Asked the same thing on Twitter, and was fortunate enough to receive feedback from reputed experts Bartosz Adamczewski, Immo Landwerth, Jared Parsons and Lucas Trzesniewski
Here is the question link.
Here are the most relevant bits of info you can extract from the original Twitter thread:
What you might gain is better IL, so things like strings and certain
other things are handled better by the front-end compiler C# and
better IL is generated, this, in turn, could provide better codegen in
JIT - Bartosz Adamczewski
#jaredpar can correct me but for the most part the code gen isn’t
depending on the target framework, except for cases where the code gen
users specific APIs, which is rare. - Immo Landwerth
That is correct. At the compiler level there is no concept of target
frameworks, there are just references. Hence all decisions about code
gen are based on the API in the references. - Jared Parsons
In the case of .NET 6, you'll get access to some new APIs such as
DefaultInterpolatedStringHandler, so for instance all of your string
interpolation expressions ($"...") will get a perf boost just by
targeting net6.0. Also, there are new method overloads such as
StringBuilder.Append that take string interpolation handlers as
parameters. Your string interpolation expressions will target these
instead when targeting net6.0, and your code will allocate less than
on other targets. So yes, in some cases, your code will get more
love by the compiler if you add a net6.0 target 🙂 - Lucas
Trzesniewski
We are developing a cross platform mobile application using Xamarin. I have noticed there are different ways of structuring your code using Shared code or PCL/.net standard.
I attempted to use .net standard and what i have found is that it doesn't include all the libraries such as using ado stuff , datatable/datasets using system.data. Or using system.net for example. Other functions have less overloads and seems that its a stripped version of .net to work across platforms. Is there any way to add this functionality or use a broader range of .net?
You are correct - .Net Standard and .Net Core are stripped down versions of the full .Net framework. They contain only features that can be used on all platforms (Mac, Android, iOS, Linux, Windows, etc.)
The full .Net framework only needs to work on Windows, so there are additional things that you can do based on the fact that there is less complexity in implementing and that the code base is more mature (cross platform is still pretty new by C# standards). To the best of my memory, System.Net should work if you have your references correct, but System.Data will not (or at least direct database access is not possible)
You can regain some functionality through NuGet packages, but it won't be the same as using WinForms or something like that...
My best advice would be to program against an API. You can use a web server that runs on the normal (full) .Net framework, and does all the heavy lifting using all the .Net features that you are accustomed to. Your Xamarin app would send and receive data from the API and basically provide a mobile front end for whatever you are doing. This approach makes sense for most apps anyway, and is generally what you would be doing anyway if you used Swift and Java to create separate iOS and Android apps.
I'm working with the code from google drive in visual studio 2012 (C#). I managed with hours of fiddling around with nuget reference the necessary libraries.
I compiled the test application and got the following warnings:
'Google.Apis.Authentication.OAuth2.DotNetOpenAuth.NativeApplicationClient' is obsolete: 'NativeApplicationClient is not supported any more and it's going to be removed in 1.7.0-beta. Consider using the new Google.Apis.Auth NuGet package which supports .NET 4, .NET for WindowsStore apps, Windows Phone 7.5 and 8 and Portable Class Libraries as well'
'Google.Apis.Authentication.OAuth2.GoogleAuthenticationServer' is obsolete: 'GoogleAuthenticationServer is not supported any more and it's going to be removed in 1.7.0-beta. Consider using the new Google.Apis.Auth NuGet package which supports .NET 4, .NET for Windows Store apps, Windows Phone 7.5 and 8 and Portable Class Libraries as well'
'Google.Apis.Drive.v2.DriveService.Scopes' is obsolete: 'Use DriveService.Scope instead. This enum is going to be removed in version 1.7.0-beta.'
I did not modify the code other than adding in the client_ID and client_secret. Other than that, it appears to run...
I'll also mention that I am using the nuget Google.Apis.Auth package.
The code behind the DriveService.Scopes warning is using DriveService.Scopes not Google.Apis.DriveService.Scopes (look at the code on the link; mine is the same).
With the google admin api being deprecated and google breaking the old api almost every other week it seems, I'm anxious to get on the new API. However, with what I'm seeing here I'm wondering if that's a good idea or not. I could be trading the frying pan for the fire. With that said, what are we supposed to be using if your current example is already obsolete?
First of all you should use the latest version of the library, that's the version that we maintain, provide fixes, new features and so on. You can get it using NuGet.
The sample code in the page you mentioned wasn't updated lately. Take a look in our samples repository (and specifically in the Drive API sample).
Google.Apis.Auth is the right package to use. The reason the old package (Google.Apis.Authentication) is obsolete is based on the fact the we wanted to support different Windows platforms like WP, Windows 8 applications, ASP.NET MVC. We also simplified the OAuth2 "dance" which was so complicated before.
Last thing - If we make any incompatible changes in the library we document them in our announcement blog, so our users will be able to make the right adjustments . I recommend you subscribing to this blog to get updates about our library.
Hope everything is clear now :)
We have a large game built with Flex SDK 4.0.0, using Flex 4 as the GUI framework and (largely) PureMVC as the architectural framework.
Since we need to add right-to-left text/layout support to the game in the near future and the layoutDirection property is only available in Flex SDK 4.1.0 or later, we obviously need to change the SDK with which we build our project.
Are there any known pitfalls and issues that we could run into when making the switch? What are the things to keep a close eye one (ANT tasks? namespaces? custom components? charting?) because they could break during the migration?
We finally decided to make a bigger step and go directly for SDK 4.6.0/FP11.1 and while doing so we will be refactoring lots of stuff anyway.
I'm trying to understand if moonlight is a framework which is similar yet independent to the mono framework in exactly the same way as silverlight is similar yet independent for dot net framework.
I'm trying to write a library that works for both moonlight and mono and I was wondering if I would need to target specific frameworks (as is the case with silverlight and dot net).
Moonlight uses the Mono runtime but, like Silverlight, uses a subset of the available .NET framework. So yes, you'll need to target different frameworks for desktop vs Moonlight (Moonlight uses the 2.1 profile, same as Silverlight).