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
Related
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.
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.
The CUDA FAQ says:
CUDA defines vector types such as float4, but doesn't include any
operators on them by default. However, you can define your own
operators using standard C++. The CUDA SDK includes a header
"cutil_math.h" that defines some common operations on the vector
types.
However I can not find this using CUDA SDK 5.0. Has it been removed/renamed?
I've found a version of the header here. How is it related to the one that's supposed to come with SDK?
The cutil functionality was deleted from the CUDA 5.0 Samples (i.e. the "SDK"). You can still download a previous SDK and compile it under CUDA 5, you should then have everything that came with previous SDK's.
The official notice was given by nvidia in the CUDA 5.0 release notes (CUDA_Samples_Release_Notes.pdf, installed with the samples). As to why, I imagine that the nvidia sentiment regarding cutil probably was something like what is expressed here "not suitable for use in a real application. It is completely unsupported" but people were using it in real applications. So one way to try put a stop to that is to delete it, I suppose. That's just speculation.
Note some additional useful info provided in the release notes:
CUTIL has been removed with the CUDA Samples in CUDA 5.0, and replaced
with helper functions found in NVIDIA_CUDA-5.0/common/inc:
helper_cuda.h, helper_cuda_gl.h, helper_cuda_drvapi.h,
helper_functions.h, helper_image.h, helper_math.h, helper_string.h,
helper_timer.h
These helper functions handle CUDA device
initialization, CUDA error checking, string parsing, image file
loading and saving, and timing functions. The CUDA Samples projects no
longer have references and dependencies to CUTIL, and now use these
helper functions going forward.
So you may find useful functions in some of those header files.
in latest SDK helper_math.h implement most of required operator, however its still missing logical operators like OR or AND
I have gotten google protocol buffers to work with Linux as the server, and C#.Net under windows as the client. However, I don't see a way to generate C++.net. Can someone point me to how I can do that?
Thanks.
Ivan
I'm not aware of a full C++ .NET implementation, and none is listed in the 3rd party add-ons, so I think you have a few options:
use the unmanaged C++ implementation (presumably the google version), and map between your unmanaged and managed types manually
use one of the C# implementations (protobuf-net or protobuf-csharp-port would be my preferences, depending on whether you want idiomatic .NET versus idiomatic protobuf), and compile this as a C# library, and simply reference the C# library from you C++ .NET project
write (and ideally contribute) a C++ .NET translator to your implementation of choice (since you have tagged protobuf-net, I will make the observation that this means writing an xslt file for protobuf-net)
If you want the most pragmatic C++ option, I'd choose the first. If you want the most pragmatic .NET option, I'd choose the second. If you demand a proper C++ .NET file that you can include in your existing project, I'd choose the third.
Currently I am working in a project that uses MFC a lot, but it seems to me that MFC technology is not widely used nowadays. How deprecated is MFC? What are the alternatives for it? I am using VS2010 on Windows.
Thank you for your answers.
Windows Forms and WPF are becoming more and more popular these days,
but seeing that a new version of MFC was released just a few months ago (see here) I wouldn't call it deprecated just yet.
Yes, MFC is not what you would call state-of-the-art. If you are starting a new (UI) application from scratch, you should come up with really strong reasons to use MFC (for example, you have already existing code). There are many disadvantages, for exeample the document/view archtiecture, which is only suitable for small UI applications or the high amount of customization you need to put in, if you want controls that are not included in this framework (and you certainly will at some point). Additionally, it is not that easy to test MFC classes, which you should have in mind as well.
Widely used are approaches with a MVC (model-view-controller) architecture. You can read more about these two archiectures here:
Document / View as used in MFC
Model View Controller
As you are considering MFC, I assume you already have knowledge in C++. Therefore, the Qt Framework from Trolltech / Nokia might be interesting for you. It supports MVC architecture, is cross-platform compatible and still actively developed.
MFC is not so bad. The problem is that most of the components (windows/widgets) are pretty bad or more precisely very inflexible. As Hans said it's 18 years of backward compatibility and therefore every clock cycle and memory byte counted. This hurts today.
I'm using it because Windows Forms and WPF is just not useable for cross platform GUI development where the lingua franca of the backend is C or C++ (if Java is not an option for your project for whatever reason).
Depending on what you want to do and how important a very native looking GUI is, MFC might be the only choice, especially when you can afford to buy third party components and use the feature-pack or Ribbons.
I not commenting on QT/GTK/FLTK or other toolkit as long as you don't tell us more about your project