Best tools for Deobfuscator .net library is de4net it's free and works good. in supported list i cant see .net reactor v5 . latest is 4.9 . is there any alternative way or modded version of de4net to Deobfuscate .net reactor v5 obfuscated library ?
If you update to .NET Reactor >= v6.0 de4dot isn't even able to recognize that the files are protected with .NET Reactor (except "Native EXE File" is enabled).
Related
I want to work with visual studio 2019 net5.0 framework but there is a little message like this on page => (Net 5.0 out of support) .Is Net 5.0 framework banned from microsoft ? or cancelled ?
help me guyss.
Thanks ........
I hope somebody answers my question.
As Timothy G said. Microsoft will no longer provide servicing updates for .NET 5.0, including security fixes or technical support, and users will need to update their .NET version to a supported version (.NET 6.0) to continue receiving updates.
.NET 5.0 is not an LTS release, so will end support 18 months after release or 6 months after the next release. When .NET 5.0 support ends, applications using this version will continue to work, but the related vulnerabilities may not be fixed as Microsoft only provides support for the supported versions of .NET (ie. .NET Core 3.1 and .NET 6.0) Release a security update. Therefore users are strongly advised to migrate their applications to .NET 6.0.
Upgrade to .NET 6.0
Open the project file (.csproj, .vbproj or *.fsproj file).
Change the target framework value from net5.0 to net6.0, the target framework is defined by the or element.
For more migration matters, please refer to the .NET 6 Compatibility Guide: https://docs.microsoft.com/dotnet/core/compatibility/6.0.
Visual Studio 16.11 will continue to support .NET 5.0 SDK versions until the end of support for .NET Core 3.1 in December 2022. However, the .NET 5.0 SDK does not use the .NET 5.0 runtime when running command-line scenarios, and is not available as a standalone SDK. It is recommended to use .NET 6.0 and Visual Studio 2022 to build applications that run on supported .NET runtimes.
For more support content, please view the official announcement: https://devblogs.microsoft.com/dotnet/dotnet-5-end-of-support-update/.
I have a .net Core 2.2 project. This is created using a Webapplication (Model View Controller) template. I can add my .Net Framework 4.7.1 projects into this core project, it compiles, run - and is deployed on my test servers.
1) Then I read about 2.2 End of Life, and I tried to migrate this to 3.1, and I cannot reference .Net Framework 4.7.1 in 3.1 framework. I don't know what is my next step here.
2)I read that I can convert my dll's to .Net Standard and reference - but, how can I do this?
3)These 4.7.1 dll's are shared by .Net Framework projects and core projects, so if I change this to .Net Standard - will my .Net Framework applications work?
4) Also - should I migrate my 2.2 Core projects to 3.0 because of the EOL? Is that mandatory? How will EOL affect audits if I don't migrate?
First, 2.2 is EOL, because 2.1 is the LTS release. You can downgrade to 2.1 if you don't want to jump to 3.x yet, and you'll still have a year or two of support there, I think.
However, 3.x takes the first step towards the new vision of one .NET (.NET 5 for all workflows), so the sooner you can get there, the better. 3.1, specifically, is the LTS release for 3.x, so stick there if you don't want to be forced to upgrade again for a while.
.NET Core 3.x implements .NET Standard 2.1, which is why you can no longer target .NET Framework with that (no version of .NET Framework implements .NET Standard 2.1 and never will). However, .NET Standard 2.0 is supported by both .NET Core (2.x and 3.x) and .NET Framework 4.6.1+. As a result, if you need to share a library between all these targets, you should target .NET Standard 2.0.
As far as converting your existing libraries go, you simply change the target framework to .NET Standard 2.0. That's literally it. Once you do that, some functionality in the library may fail (anything that requires .NET Framework, i.e. Windows-specific APIs). At that point, you either need to rewrite those parts of the library to use .NET Standard-compatible APIs, or use compiler directives to sub-in alternate implementations for .NET Standard 2.0/.NET Core, at which point, you'd have to multi-target the library (i.e. .NET Framework and .NET Standard 2.0 or even specifically .NET Core). When compiling, DLLs will be generated for each specific target, allowing you to seamless reference the same library from projects targeting any of the library targets.
If you're doing anything with ASP.NET Core components in your libraries, you should factor that code out into separate libraries and target .NET Core 3.1 directly there. There's no point in targeting .NET Standard 2.1, as that code will only ever be applicable to .NET Core, anyways. You should also work in the opposite direction. In other words, if there's anything that's only applicable to .NET Framework projects (Web Forms, etc.), then factor that out into separate libraries that will only target .NET Framework. That will allow you to migrate the remaining parts of the library more easily to .NET Standard 2.0.
I've been using Saxon XSLT and XQuery processor - Free home edition for some of my .NET apps. I need only XSLT 2.0 (since .NET does not support XSLT 3.0). Now that I've moved from .NET Framework to .NET Core, I noticed that the Saxon has not yet supported .NET Core since when installing a Nuget package for Saxon, I get the following error.
Question: Are there other alternatives that someone knows I can use for my .NET Core projects that need XSLT 2.0 and XQuery processing?
Because of the following error my code does not compile since it does not recognize XdmNode, XsltTransformer, etc.
Package 'Saxon-HE 9.9.1.5' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework '.NETCoreApp,Version=v3.0'. This package may not be fully compatible with your project.
XmlPrime https://www.xmlprime.com/xmlprime/ is a pure .NET implementation of XQuery 3.1 and XSLT 2.0, it was developed for the .NET framework and the latest version 4 also to work with Mono.
I have installed the current trial version of 4.1 and have written a .NET Core 3 console application with VS 2019 where I have added the two assemblies XmlPrime.dll and XmlPrime.ExtensionMethods.dll of the XmlPrime installation directory as references to the .NET core project.
Two simple examples adapted from https://github.com/XmlPrime/Examples/tree/master/Query and https://github.com/XmlPrime/Examples/tree/master/Transform then run fine to execute XQuery 3 and XSLT 2 in the .NET Core 3 app.
So technically XmlPrime, at least with some superficial tests, seems an option for .NET Core 3, I don't know about the state of their project however, as far as I know they only occasionally update their trial version and have stopped to sell commercial licenses online. You might need to enquire at the contact details of https://www.xmlprime.com/xmlprime/contact.htm to ask whether they sell full licenses some other way.
In 2022 Saxonica released SaxonCS 11 (https://www.saxonica.com/download/dotnet.xml), its first release of a pure .NET 5 Core implementation of XSLT 3.0, XQuery 3.0, XPath 3.1 (and XSD 1.0 and 1.1 schema validation). The current stable release is 11.5 and runs on .NET 6 and 7.
Furthermore SaxonCS 12 (https://www.saxonica.com/download/dotnet.xml) for .NET 6 and 7 has been released in 2023.
For non-commercial options, I have managed to cross-compile both Saxon HE 10.8 as well as Saxon HE 11.5 Java with the IKVM revived tools to .NET core, find packages and samples on NuGet and Github:
https://www.nuget.org/packages/SaxonHE11s9apiExtensions/
https://github.com/martin-honnen/SaxonHE11IKVMNet6SaxonCSSamplesAdapted
https://www.nuget.org/packages/SaxonHE10Net31/
https://www.nuget.org/packages/SaxonHE10Net31Api/
I'm trying to upgrade my project to .net core 3.0 when it used to be running with asp core 2.1.
The application compile fine but as soon as i start it, the application crash on the app.usespa() function in startup.cs ...
Does someone has already encountered this issue ?
When i create a sample project from scratch with angular it runs well ...
Thanks in advance,
Razgort
One of your library is still not upgraded to 3.x.
use NUGET to update all your libraries to be compatible with 3.x
Microsoft provides a number of command line tools for working with asp.net applications. I haven't had any trouble using these tools. One thing that I can not understand though, is the location of these tools.
Even for applications targeting newer versions of .net, these tools are located in the .net v2 directory. On my machine, that's C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727. Why do these tools not exist in the v3.0 or v3.5 directories? And why do the ones in the older directory work on the newer framework?
This is more of an idle curiosity than required knowledge for me, but I would like to know.
Update:
Thanks for the good answers everyone. These answers raise a new question though. I hope you will forgive me for asking it here, since it is so highly related. If .net 3.5 is really just using the CLR from 2.0, why is 2.0 compatible with Windows 2000, but not 3.5? It would seem to me that if the updates in 3.0 and 3.5 run inside the framework of the earlier version, then they must maintain compatibility with the same platforms as the earlier version too. Why is this wrong?
.NET 3.0 and 3.5 are (basically) just library additions to the 2.0 framework.
The addition of .NET 3.0 didn't mean new compilers or a new CLR. Instead, it's three major new libraries: WCF (Windows Communication Foundation née Indigo), WPF (Windows Presentation Foundation née Avalon) and Windows Workflow or WF.
Basically, remember Framework version != CLR Version. If you configured an IIS Application to use .NET 2.0, you're talking about the 2.0 CLR. WCF Applications use the .NET 2.0 CLR with the new 3.0 WCF libraries.
* .NET Framework 1.x = CLR 1.x
* .NET Framework 2.0 = CLR 2.0
* .NET Framework 3.0 = CLR 2.0
* .NET Framework 3.5 = CLR 2.0 + (C# 3.0 | VB9)
Edit:
To answer your second question, .NET 3.0 and 3.5 have new libraries which reference OS-level features like WPF, which isn't available on Windows 2000. If you write an application in 3.5* but only use functionality and libraries that were also available in 2.0, it can still work on Windows 2000.
*by "in 3.5", we mean write it in Visual Studio 2008 under 3.5 but set your Project Target Framework to 2.0. Scott Hanselman talks about doing this to get ASP.NET MVC to work on .NET 2.0.
It is because the core of .Net has not actually been changed since v2.0. MS marketing types were much derided at the time for forcing the naming scheme in use, where .Net 3, and .Net 3.5 are really just adding additional libraries that run on the .Net 2 core.
Check out Scott Hanselman's blog post for more details.
Because .NET 3.0 and 3.5 are applications of .NET 2.0, not complete, standalone frameworks unto themselves. This is further see in the IIS config, where you only have the option to select .NET 1.0, .NET 1.1, and .NET 2.0. You web.config file will include any .NET 3.0 or .NET 3.5 assemblies as these are written, ultimately, with .NET 2.0 code. More details about that can be seen here: http://www.hanselman.com/blog/HowToSetAnIISApplicationOrAppPoolToUseASPNET35RatherThan20.aspx
Of course, that all changes in .NET 4.0 which will be a completely "new version" of the framework.
v3.0 and v3.5 still uses the v2 DLLs for the core files. Most of the changes are additions to the v2 framework as well as a new compiler for 3.5.