Windows 10: What is the best tool to convert code from Java to .NET Core

PrasadMicrosoft · Jun 15, 2020

I have a requirement for converting Java code into .NET Core, and have been trying to find a good tool for doing code conversion. I could find a Microsoft tool, JLCA which was used for conversion. But, this tool is a old version and doesn't get installed on Windows 10 and also seems like it is deprecated.

Any suggested tools that can be used for Java to .NET Core conversion?

:)

Brink · Jun 15, 2020

.NET Core 3 for Windows Desktop

Intro

In September, we released .NET Core support for building Windows desktop applications, including WPF and Windows Forms. Since then, we have been delighted to see so many developers share their stories of migrating desktop applications (and controls libraries) to .NET Core. We constantly hear stories of .NET Windows desktop developers powering their business with WPF and Windows Forms, especially in scenarios where the desktop shines, including:

UI-dense forms over data (FOD) applications

Responsive low-latency UI

Applications that need to run offline/disconnected

Applications with dependencies on custom device drivers

This is just the beginning for Windows application development on .NET Core. Read on to learn more about the benefits of .NET Core for building Windows applications.

Why Windows desktop on .NET Core?

.NET Core (and in the future .NET 5 that is built on top of .NET Core) will be the future of .NET. We are committed to support .NET Framework for years to come, however it will not be receiving any new features, those will only be added to .NET Core (and eventually .NET 5). To improve Windows desktop stacks and enable .NET desktop developers to benefit from all the updates of the future, we brought Windows Forms and WPF to .NET Core. They will still remain Windows-only technologies because there are tightly coupled dependencies to Windows APIs. But .NET Core, besides being cross-platform, has many other features that can enhance desktop applications.

First of all, all the runtime improvements and language features will be added only to .NET Core and in the future to .NET 5. A good example here is C# 8 that became available in .NET Core 3.0. Besides, the .NET Core versions of Windows Forms and WPF will become a part of the .NET 5 platform. So, by porting your application to .NET Core today you are preparing them for .NET 5.

Also, .NET Core brings deployment flexibility for your applications with new options that are not available in .NET Framework, such as:

Side-by-side deployment. Now you can have multiple .NET Core versions on the same machine and can choose which version each of your apps should target.

Self-contained deployment. You can deploy the .NET Core platform with your applications and become completely independent of your end users environment – your app has everything it needs to run on any Windows machine.

Smaller app sizes. In .NET Core 3 we introduced a new feature called linker (also sometimes referred to as trimmer), that will analyze your code and include in your self-contained deployment only those assemblies from .NET Core that are needed for your application. That way all platform parts that are not used for your case will be trimmed out.

Single .exe files. You can package your app and the .NET Core platform all in one .exe file.

Improved runtime performance. .NET Core has many performance optimizations compared to .NET Framework. When you think about the history of .NET Core, built initially for web and server workloads, it helps to understand if your application may see noticeable benefits from the runtime optimizations. Specifically, desktop applications with heavy dependencies on File I/O, networking, and database operations will likely see improvements to performance for those scenarios. Some areas where you may not notice much change are in UI rendering performance or application startup performance.

By setting the properties <PublishSingleFile>, <RuntimeIdentifier> and <PublishTrimmed> in the project file you’ll be able to deploy a trimmed self-contained application as a single .exe file as it is shown in the example below.

Code:

<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.0</TargetFramework>
<PublishSingleFile>true</PublishSingleFile>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
<PublishTrimmed>true</PublishTrimmed>
</PropertyGroup>
Click to expand...

Differences between .NET Framework desktop and .NET Core desktop

While developing desktop applications, you won’t notice much difference between .NET Framework and .NET Core versions of WPF and Windows Forms. A part of our effort was to provide a functional parity between these platforms in the desktop area and enhance the .NET Core experience in the future. WPF applications are fully supported on .NET Core and ready for you to use, while we are working on minor updates and improvements. For Windows Forms the runtime part is fully ported to .NET Core and the team is working on the Windows Forms Designer. We are planning to get it ready by the fourth quarter of 2020 and for now you can check out the Preview version of the designer in Visual Studio 16.4 Preview 3 or later. Don’t forget to set the checkbox in the Tools->Options->Preview Features->Use the Preview of Windows Forms designer for .NET Core apps and restart the Visual Studio. Please keep in mind that the experience is limited for now since the work on it is in progress.

Breaking changes

There are a few breaking changes between .NET Framework and .NET Core but most of the code related to Windows Forms and WPF areas was ported to Core as-is. If you were using such components as WCF Client, Code Access Security, App Domains, Interop and Remoting, you will need to refactor your code if you want to switch to .NET Core.

Another thing to keep in mind – the default output paths on .NET Core is different from on .NET Framework, so if you have some assumptions in your code about file/folder structure of the running app then it’ll probably fail at runtime.

Also, there are changes in how you configure the .NET features. .NET Core instead of machine.config file uses <something>.runtimeconfig.json file that comes with an application and has the same general purpose and similar information. Some configurations such as system.diagnostics, system.net, or system.servicemodel are not supported, so an app config file will fail to load if it contains any of these sections. This change affects System.Diagnostics tracing and WCF client scenarios which were commonly configured using XML configuration previously. In .NET Core you’ll need to configure them in code instead. To change behaviors without recompiling, consider setting up tracing and WCF types using values loaded from a Microsoft.Extensions.Configuration source or from appSettings.

You can find more information on differences between .NET Core and .NET Framework in the documentation.

Getting Started

Check out these short video tutorials:

Porting from .NET Framework to .NET Core

First of all, run the Portability Analyzer and if needed, update your code to get a 100% compatibility with .NET Core. Here are instructions on using the Portability Analyzer. We recommend to use a source control or to backup your code before you make any changes to your application in case the refactoring would not go the way you want, and you decide to go back to your initial state.

When your application is fully compatible with .NET Core, you are ready to port it. As a starting point, you can try out a tool we created to help automate converting your .NET Framework project(s) to .NET Core – try-convert.

It’s important to remember that this tool is just a starting point in your journey to .NET Core. It is also not a supported Microsoft product. Although it can help you with some of the mechanical aspects of migration, it will not handle all scenarios or project types. If your solution has projects that the tool rejects or fails to convert, you’ll have to port by hand. No worries, we have plenty of tutorials on how to do it (in the end of this section).

The try-convert tool will attempt to migrate your old-style project files to the new SDK-style and retarget applicable projects to .NET Core. For your libraries we leave it up to you to make a call regarding the platform: weather you’d like to target .NET Core or .NET Standard. You can specify it in your project file by updating the value for <TargetFramework>. Libraries without .NET Core-specific dependencies like WPF or Windows Forms may benefit from targeting .NET Standard:

<TargetFramework>netstandard2.1</TargetFramework>

so that they can be used by callers targeting many different .NET Platforms. On the other hand, if a library uses a feature that requires .NET Core (like Windows desktop UI APIs), it’s fine for the library to target .NET Core:

<TargetFramework>netcoreapp3.0</TargetFramework>

try-convert is a global tool that you can install on your machine, then you can call from CLI:

C:\> try-convert -p <path to your project>

or

C:\> try-convert -w <path to your solution>

As previously mentioned, if the try-convert tool did not work for you, here are materials on how to port your application by hand.

Videos

Simple porting case

YouTube

Documentation

Simple porting case

Advanced porting case (Part 1, Part 2)

Overview of the porting process

Olia Gavrysh
Program Manager, .NET
Click to expand...

Source: https://devblogs.microsoft.com/dotne...ndows-desktop/

Tweet

— Twitter API (@user) View on Twitter
Click to expand...

Brink · Jun 15, 2020

.NET Core 1.0 is now released!

I feel like it's the culmination of all these years of work in .NET and Open Source. This is why I came to work at Microsoft; we wanted to open source as much as we could and build a community around .NET and open source at Microsoft. 15 years and the work of thousands of people later, today we released .NET Core 1.0.

Take a moment and head over to http://dot.net and check out the download page. It's got a really nice place you can try out C# directly in the browser without having to install anything! There's also a great C# Tutorial with interactive browser-based tools as well.

.NET Core 1.0 runs on Windows, Mac, and several flavors of Linux including RedHat Enterprise Linux and Ubuntu. It supports C#, VB, and F# and modern constructs like generics, Language Integrated Query (LINQ), async support and more. The Core Runtime, libraries, compiler, languages and tools are all open source on GitHub where contributions are accepted, tested and fully supported.

Getting started with .NET Core

If you use Visual Studio 2015 (and remember, Visual Studio Community is free!) you should get VS2015 Update 3 first then install the .NET Core Tools for Visual Studio.

If you don't want to use VS, consider using Visual Studio Code for free and install the C# extension from the marketplace to get a great code editing experience along with the .NET Core SDK for Windows. Of course, if you're on Mac/Linux/Whatever, go over to http://dot.net and download whatever's right for you!

If you want all the advanced and specific downloads for .NET or .NET Core, there's a table here.

What is .NET Core? Here's some details from the .NET Blog:
.NET Core is a new cross-platform .NET product. The primary points of .NET Core are:

Cross-platform: Runs on Windows, macOS and Linux.

Flexible deployment: Can be included in your app or installed side-by-side user- or machine-wide.

Command-line tools: All product scenarios can be exercised at the command-line.

Compatible: .NET Core is compatible with .NET Framework, Xamarin and Mono, via the .NET Standard Library.

Open source: The .NET Core platform is open source, using MIT and Apache 2 licenses. Documentation is licensed under CC-BY. .NET Core is a .NET Foundation project.

Supported by Microsoft: .NET Core is supported by Microsoft, per .NET Core Support

.NET Core is composed of the following parts:

A .NET runtime, which provides a type system, assembly loading, a garbage collector, native interop and other basic services.

A set of framework libraries, which provide primitive data types, app composition types and fundamental utilities.

A set of SDK tools and language compilers that enable the base developer experience, available in the .NET Core SDK.

The ‘dotnet’ app host, which is used to launch .NET Core apps. It selects and hosts the runtime, provides an assembly loading policy and launches the app. The same host is also used to launch SDK tools in the same way.

Blogs

Here are the major blogs carrying the announcement.

Announcing .NET Core 1.0

Announcing ASP.NET Core 1.0

Visual Studio 2015 Update 3 and .NET Core 1.0 Available Now

We are also releasing .NET documentation today at docs.microsoft.com, the new documentation service for Microsoft.

The documentation you see there is just a start. You can follow our progress at core-docs on GitHub. ASP.NET Core documentation is also available and open source.

Have fun!
Click to expand...

Source: .NET Core 1.0 is now released! - Scott Hanselman

Brink · Jun 15, 2020

Announcing .NET Core, .NET Native and NuGet Updates in VS 2017 RC

We just released updates to the .NET Core SDK, .NET Native Tools and NuGet, all of which are included in Visual Studio 2017 RC. You can also install the .NET Core SDK for command-line use, on Windows, Mac and Linux. Please check out the ASP.NET blog to learn more about Web Tools updates and the Visual Studio blog for the Visual Studio 2017 RC update.

Install Visual Studio 2017 RC

Install .NET Core 1.0 SDK – RC3

The following improvements are the .NET highlights of the release:

.NET Core – The csproj project format has been simplified and project migration is much more reliable.

.NET Native – Major performance increase for SIMD and other performance improvements.

NuGet – .NET Framework, UWP, .NET Core and other .NET projects can now use PackageReference instead of packages.config for NuGet dependencies.

Note: csproj projects created with earlier releases of Visual Studio 2017 or on the command-line with the .NET Core SDK must be manually updated to load in the latest release. Please read the Updating .NET Core Projects section, below, for more information.

.NET Core

The .NET Core tools have been significantly improved in this update, fixing bugs and usability issues. A major focus of this release has been simplifying the project file and improving project migration. We are no longer using the “preview” term, but “RC3” to match Visual Studio 2017 RC.

The tools in the new SDK produce and operate on csproj projects. If you are using project.json projects, including with Visual Studio 2015, then please wait to install the new SDK until you are ready to move to csproj and MSBuild. If you are a Visual Studio user, you will get the SDK when you install Visual Studio 2017. See Known issues for Web Tools, and ASP.NET and ASP.NET/.NET Core in Visual Studio 2017.

Getting the Release

This .NET Core SDK release is available in Visual Studio 2017 RC, as part of the .NET Core cross-platform development workload. It is also available in the ASP.NET Web workload and an optional component of the .NET Desktop workload. These workloads can be selected as part of the Visual Studio 2017 RC installation process. The ability to build and consume .NET Standard class libraries is available in the all of the above workloads and in the UWP workload.

You can also install the .NET Core SDK release for command-line use on Windows, macOS and Linux by following the instructions at .NET Core 1.0 – RC3 Download.

The release is also available as Docker images, in the dotnet repo. The following images include the new SDK:

1.0.3-sdk-msbuild-rc3

1.0.3-sdk-msbuild-rc3-nanoserver

1.1.0-sdk-msbuild-rc3

1.1.0-sdk-msbuild-rc3-nanoserver

The aspnetcore-build repo has also been updated.

.NET Core SDK Components

This release contains the .NET Core Tools 1.0 RC3, the .NET Core 1.0.3 runtime and the .NET Core 1.1.0 runtime. No changes have been made to the .NET Core runtime in this release. .NET Core 1.0.3 and 1.1.0 were both released previously.

The .NET Core SDK includes a set of .NET Core Tools and one of more runtimes. In previous SDK releases, there was only ever one runtime included. This change in approach was made to make it easier to acquire all supported runtimes as a single step. This experience helps when you are collaborating with developers who are using multipe runtimes. It also makes it easier to update multiple runtimes on your machine when fixes are released. The SDK naturally gets larger, but not as much as you might guess since there is only ever one set of tools in the package. It also enables us to improve the tools for everyone more easily...
Click to expand...

Read more: https://blogs.msdn.microsoft.com/dot...in-vs-2017-rc/

Windows 10: What is the best tool to convert code from Java to .NET Core

What is the best tool to convert code from Java to .NET Core

What is the best tool to convert code from Java to .NET Core

What is the best tool to convert code from Java to .NET Core

What is the best tool to convert code from Java to .NET Core - Similar Threads - best tool convert

What is the best user migration tool?

What is the best user migration tool?

What is the best user migration tool?

Convert vb.net code to c#.net and vice-versa.

Convert vb.net code to c#.net and vice-versa.

Net core 3.1

What is the best OST to PST Converter Software?

.NET Core tooling update for Visual Studio 2019 Preview 2

Updating Visual Studio 2017 RC – .NET Core Tooling improvements

Users found this page by searching for:

JLCA Visual Studio 2019