I'm converting an old application from .Net 4x to .Net 6, and I can't seem to find a replacement for Microsoft.Practices.EnterpriseLibrary.Validation. In newer code we've used System.ComponentModel.DataAnnotations for similar functionality, but it looks like a lot of the attributes have different names. Has anyone come across a fix?
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.
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've got an old VB4 app I want to look at to convert/re-write into something maintainable.
I have the source, but of course, nothing to compile it with, and VS2010 doesn't like the vbp and won't open it.
Although it installs, it won't run - failing with an out of memory error. I want to try an updated version of Jet 3.0, but I can't seem to get the files referenced in this link http://support.microsoft.com/kb/q151186/
So a few questions:
1) Where is the latest version of Jet 3.0?
2) Is running the app in VB4/5/6 the only viable option to be able to view the forms, designers, etc to convert the app?
1) If at all possible move to Jet 4.0/DAO 3.6 as they have been included in every version of Windows since Windows 2000. It's not worth your while trying to use an older version of Jet with all the install problems you will likely encounter. You might have a few syntax changes to make but I doubt they will be that severe.
2) I have no idea about how good or bad the upgrade path is from VB3 to newer versions of VB. If you don't get an answer here the real long time VB Classic (not VB.NET) experts hang out in http://groups.google.com/group/microsoft.public.vb.general.discussion/topics?hl=en That said the VB6 IDE works well in Windows 7 once you know about one particular install trick which requires creating a 0 byte msjava.dll file in the Windows directory.
1) Where is the latest version of Jet 3.0?
2) Is running the app in VB4/5/6 the only viable option to be able to
view the forms, designers, etc to convert the app?
1 - I'd try to dig up an old copy of Access (or Office)
2 - Actually I doubt it'll even work in vb6 (and vb5 might be an adventure), the project upgrade paths weren't very smooth back then, but yes, you're pretty much stuck. As far as I know there was never anything else that would emulate those designers.
If you can find a version of VB4, or Access 95, then this would come with JET3.
2) Realistically you would need VB4 to have the best chance of opening this. Try to find someone who has some old MSDN disk sets.
You might try a later version. The jump from VB4 to 6 might be too much. I imagine it would open but perhaps not run in VB5 as I presume Microsoft looked at people upgrading projects from the immediately prior version.
We have a legacy vb6 application that uses an ancient windows media player component, msdxm.ocx, to embed ultrasound (pregnancy) video's in the medical record.
This doesn't work any more on Windows 7: it has a newer version of msdxm.ocx which cannot be referenced from vb6.
The newer version of the embeddable player is wmp.dll, so we are planning to upgrade the application to the newer version for Windows 7.
Before we have to find it all out the hard way by ourselves: does someone have experience with this upgrade from msdxm.ocx to wpm.dll? Is there a list of things to consider when upgrading? Or a table to convert constants and events from the first to the second?
I haven't seen anything listing their object models side-by-side or offering any "conversion."
The msdxm.ocx was really a scriptable IE object and should not have been used in VB6 programs. Lots of people did though. Windows 7 still has this OCX but starting with Vista (or perhaps IE7?) its interfaces changed in a way that seems to prevent use in VB6 programs.
You might want to try running a tool like ActiveX Documenter aginst working versions of both libraries to assist your efforts though. The RTF output documents might be a starting point for writing your own conversion guide.
msdxm.ocx should still work if you put the OCX file in C:\Windows\SysWOW64 and register it.
I've tried on my Win7 and it works on my music player legacy app.
Don't know about Windows 8 though, but it might still be the same, MS might changed folder again then.