Code Monkey home page Code Monkey logo

try-convert's Introduction

try-convert NuGet Badge

This is a simple tool that will help in migrating .NET Framework projects to .NET Core.

How to use it

Install it as a global tool here:

dotnet tool install -g try-convert

If you already have it installed, make sure to update:

dotnet tool update -g try-convert

If you're using the tool again, make sure you've got the latest release: https://github.com/dotnet/try-convert/releases

How to use the tool

Nagivate to the root of your solution and simply execute:

try-convert

Alternatively, you can do

try-convert -w .

If you only want to convert a specific subfolder, solution, or project, type:

try-convert -w path-to-folder-or-solution-or-project

If you want more help from the tool, run:

try-convert -h

Because this is for converting older .NET Framework (Windows) projects, the tool only works on Windows.

NOTE: Do not use this tool from the Visual Studio developer command prompt. There is special MSBuild resolution that happens there and it ends up being incompatible with the tool. Please use a normal terminal application.

Status

Unit Tests (Debug) Unit Tests (Release)
ci Build Status Build Status
official Build Status Build Status

How to build

Simple: clone the repo and run

build.cmd

To use the tool locally, you need to build it from source. Once it's built, the tool will live under:

/artifacts/bin/try-convert/Debug/net6.0/try-convert.exe

Alternatively, you can look at the following directory and copy that into somewhere else on your machine:

mv /artifacts/bin/try-convert/Debug/net6.0/publish C:/Users/<user>/try-convert

You can invoke the tool from the publish directory as well.

Support policy

This tool is not supported in any way. Nobody will be on the hook for fixing any issues with it, nor is anyone who builds this tool obliged to add any requested features.

This is an open source project built by members of the .NET team in their spare time. Although we'll strive to fix issues and add features if people ask for them, the default answer to any issue filed will be, "we'll review a pull request that implements this".

Who is this tool for?

This tool is for anyone looking to get a little help migrating their projects to .NET Core (or .NET SDK-style projects).

As the name suggests, this tool is not guaranteed to fully convert a project into a 100% working state. The tool is conservative and does as good of a job as it can to ensure that a converted project can still be loaded into Visual Studio and build. However, there are an enormous amount of factors that can result in a project that may not load or build that this tool explicitly does not cover. These include:

  • Complex, custom builds that you may have in your solution
  • API usage that is incompatible with .NET Core
  • Unsupported project types (such as Xamarin, WebForms, or WCF projects)

If the bulk of your codebase is generally capable of moving to .NET Core (such as lots of class libraries with no platform-specific code), then this tool should help quite a bit.

It is highly recommended that you use this tool on a project that is under source control.

What does the tool do?

It loads a given project and evaluates it to get a list of all properties and items. It then replaces the project in memory with a simple .NET SDK based template and then re-evaluates it.

It does the second evaluation in the same project folder so that items that are automatically picked up by globbing will be known as well. It then applies rules about well-known properties and items, finally producing a diff of the two states to identify the following:

  • Properties that can now be removed from the project because they are already implicitly defined by the SDK and the project had the default value
  • Properties that need to be kept in the project either because they override the default or are not defined in the SDK.
  • Items that can be removed because they are implicitly brought in by globs in the SDK
  • Items that need to be changed to the Update syntax because although they're brought in by the SDK, there is extra metadata being added.
  • Items that need to be kept because they are are not implicit in the SDK.

This diff is used to convert a given project file.

Attribution

This tool is based on the work of Srivatsn Narayanan and his ProjectSimplifier project.

try-convert's People

Contributors

augustoproiete avatar brandonh-msft avatar cartermp avatar dotnet-maestro[bot] avatar dotnokato avatar drewnoakes avatar dsplaisted avatar ejohn54 avatar emimontesdeoca avatar gerrit-amagno avatar herizzon avatar icnocop avatar jbtule avatar jmarolf avatar joerobich avatar jonfortescue avatar kschlobohm avatar lg2de avatar mattjeanes avatar mjrousos avatar mmitche avatar orange-puff avatar sotteson1 avatar srivatsn avatar sunandabalu avatar sweekriti91 avatar tomaustin700 avatar trivalik avatar twsouthwick avatar ujjwalchadha avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

try-convert's Issues

Unable to compile using Linux

I can't compile using my Debian 10.

0>------- Started building project: try-convert
0>/usr/share/dotnet/sdk/3.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.PackTool.targets(107,5): Error MSB4018 : The "GenerateShims" task failed unexpectedly.
System.IO.DirectoryNotFoundException: Could not find a part of the path '/runtimes/win-x64/native/apphost.exe'.
   at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirectory, Func`2 errorRewriter)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String path, OpenFlags flags, Int32 mode)
   at System.IO.FileStream.OpenHandle(FileMode mode, FileShare share, FileOptions options)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
   at System.IO.FileSystem.CopyFile(String sourceFullPath, String destFullPath, Boolean overwrite)
   at System.IO.File.Copy(String sourceFileName, String destFileName, Boolean overwrite)
   at Microsoft.NET.HostModel.AppHost.BinaryUtils.CopyFile(String sourcePath, String destinationPath)
   at Microsoft.NET.HostModel.AppHost.HostWriter.CreateAppHost(String appHostSourceFilePath, String appHostDestinationFilePath, String appBinaryFilePath, Boolean windowsGraphicalUserInterface, String assemblyToCopyResorcesFrom)
   at Microsoft.NET.Build.Tasks.GenerateShims.ExecuteCore()
   at Microsoft.NET.Build.Tasks.TaskBase.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask)
0>------- Finished building project: try-convert. Succeeded: False. Errors: 1. Warnings: 0

Exception when trying to convert solution

When trying to convert this solution, I get the following exception:

$ try-convert -w Inquirer.sln
System.InvalidOperationException: Sequence contains more than one matching element
   at System.Linq.ThrowHelper.ThrowMoreThanOneMatchException()
   at System.Linq.Enumerable.SingleOrDefault[TSource](IEnumerable`1 source, Func`2 predicate)
   at MSBuild.Abstractions.MSBuildHelpers.GetOrCreatePackageReferencesItemGroup(IProjectRootElement rootElement) in /_/src/MSBuild.Abstractions/MSBuildHelpers.cs:line 257
   at MSBuild.Conversion.Project.ProjectRootElementExtensions.AddPackage(IProjectRootElement projectRootElement, String packageName, String packageVersion) in /_/src/MSBuild.Conversion.Project/ProjectRootElementExtensions.cs:line 293
   at MSBuild.Conversion.Project.ProjectRootElementExtensions.RemoveOrUpdateItems(IProjectRootElement projectRootElement, ImmutableDictionary`2 differs, BaselineProject baselineProject, String tfm) in /_/src/MSBuild.Conversion.Project/ProjectRootElementExtensions.cs:line 175
   at MSBuild.Conversion.Project.Converter.ConvertProjectFile() in /_/src/MSBuild.Conversion.Project/Converter.cs:line 69
   at MSBuild.Conversion.Project.Converter.Convert(String outputPath) in /_/src/MSBuild.Conversion.Project/Converter.cs:line 28
   at MSBuild.Conversion.Program.Run(String project, String workspace, String msbuildPath, Boolean diffOnly, Boolean noBackup) in /_/src/try-convert/Program.cs:line 85

Test projects do not convert correctly and result in TestContainer was not found error

Hi,

I am attempting to convert a .net framework test project to core and I am running into the following issue. Once converted the project shows as a class library and no tests seem to be discovered. When a test is ran manually the test output is the following:

StreamJsonRpc.RemoteInvocationException: The following TestContainer was not found 'C:\... path to test dll'
   at StreamJsonRpc.JsonRpc.<InvokeCoreAsync>d__96`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.TestWindow.Host.TestStoreHandler.<AddSourceBasedTestsAsync>d__23.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.TestWindow.Extensibility.ILoggerExtensions.<CallWithCatchAsync>d__9.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.GetClrWatsonExceptionInfo(Exception exceptionObject)
Executing test method: PatientLedger.PatientLedgerTests.TestClass.Test1
System.InvalidOperationException: Sequence contains no elements
   at System.Linq.Enumerable.Single[TSource](IEnumerable`1 source)
   at Microsoft.VisualStudio.TestWindow.Controller.TestContainerConfigurationQueryByContext.<GetTestContainerConfigurationsInternalAsync>d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.TestWindow.Controller.TestContainerConfigurationQuery.<GetTestContainerConfigurationsAsync>d__16.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.TestWindow.Controller.TestRunConfiguration.<UpdateAsync>d__13.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.TestWindow.Controller.RunOperation.<RunTestsAsync>d__15.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.TestWindow.Controller.Operation.<<Execute>b__37_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.TestWindow.Extensibility.ILoggerExtensions.<CallWithCatchAsync>d__10`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.GetClrWatsonExceptionInfo(Exception exceptionObject)

I have uploaded a sample solution here: https://github.com/tomaustin700/TestConvertIssue

I am building try-convert locally as the current released version is missing the following fix #156

Could not load file or assembly System.Configuration.ConfigurationManager

I'm getting the following exception when attempting to run try-convert.exe after dotnet tool install -g try-convert:

C:\Users\rubin\Syncthing\Source\RAAF\aeon>try-convert -w Orbital.sln --no-backup
System.IO.FileNotFoundException: Could not load file or assembly 'System.Configuration.ConfigurationManager, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.
File name: 'System.Configuration.ConfigurationManager, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
   at Microsoft.Build.Evaluation.ToolsetConfigurationReader..ctor(PropertyDictionary`1 environmentProperties, PropertyDictionary`1 globalProperties)
   at Microsoft.Build.Evaluation.ToolsetReader.ReadAllToolsets(Dictionary`2 toolsets, ToolsetRegistryReader registryReader, ToolsetConfigurationReader configurationReader, PropertyDictionary`1 environmentProperties, PropertyDictionary`1 globalProperties, ToolsetDefinitionLocations locations)
   at Microsoft.Build.Evaluation.ProjectCollection.InitializeToolsetCollection(ToolsetRegistryReader registryReader, ToolsetConfigurationReader configReader)
   at Microsoft.Build.Evaluation.ProjectCollection..ctor(IDictionary`2 globalProperties, IEnumerable`1 loggers, IEnumerable`1 remoteLoggers, ToolsetDefinitionLocations toolsetDefinitionLocations, Int32 maxNodeCount, Boolean onlyLogCriticalEvents, Boolean loadProjectsReadOnly)
   at Microsoft.Build.Evaluation.ProjectCollection..ctor(IDictionary`2 globalProperties, IEnumerable`1 loggers, IEnumerable`1 remoteLoggers, ToolsetDefinitionLocations toolsetDefinitionLocations, Int32 maxNodeCount, Boolean onlyLogCriticalEvents)
   at Microsoft.Build.Evaluation.ProjectCollection..ctor(IDictionary`2 globalProperties, IEnumerable`1 loggers, ToolsetDefinitionLocations toolsetDefinitionLocations)
   at Microsoft.Build.Evaluation.ProjectCollection..ctor(IDictionary`2 globalProperties)
   at Microsoft.Build.Evaluation.ProjectCollection..ctor()
   at MSBuild.Abstractions.MSBuildWorkspace..ctor(ImmutableArray`1 paths, Boolean noBackup) in /_/src/MSBuild.Abstractions/MSBuildWorkspace.cs:line 23
   at MSBuild.Abstractions.MSBuildWorkspaceLoader.LoadWorkspace(String path, Boolean noBackup) in /_/src/MSBuild.Abstractions/MSBuildWorkspaceLoader.cs:line 45
   at MSBuild.Conversion.Program.Run(String project, String workspace, String msbuildPath, Boolean diffOnly, Boolean noBackup) in /_/src/try-convert/Program.cs:line 73

--diff-only option leaves *.csproj.old files in the directory

Summary

When running the --diff-only option on a valid project file, it looks like try-convert leaves temporary project files to produce the report document. The same files are present when removing the --diff-only option, which makes sense, because you may want a backup copy of the project file that has been edited.

Problem

Unnecessary files are left behind after try-convert completes its process.

Sample CMD Script

try-convert --project .\path\to\project.csproj --diff-only
dir .\path\to\report.txt /B
dir .\path\to\*.csproj* /B

Expected Directory Results

report.txt
project.csproj

Actual Directory Results

report.txt
project.csproj
project.csproj.old

Unable to convert .NET Framework 4.8 Test Project

Hi,
I am trying to convert a .NET Framework 4.8 Test project but I am getting the following error:

Not all project type guids are supported.
All supported project type guids:
        fae04ec0-301f-11d3-bf4b-00c04f79efbc
        60dc8134-eba5-43b8-bcc9-bb4bc16c2548
All given project type guids:
        {3AC096D0-A1C2-E12C-1390-A8335801FDAB}
        {FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}

It seems that #70 added the functionality to convert test projects, should 3AC096D0-A1C2-E12C-1390-A8335801FDAB have been added to

Guid.Parse("{60DC8134-EBA5-43B8-BCC9-BB4BC16C2548}") // WPF
?

Hope you can help!
Tom

Replace well-known .NET Framework references with NuGet packages

This might be related to #48.

Some .NET Framework references have been replaced by NuGet packages, for example:

  • Microsoft.CSharp
  • Microsoft.VisualBasic
  • System.ComponentModel.Composition
  • System.ComponentModel.DataAnnotations
  • System.Data.SqlClient

The converter should remove the <Reference> items (because they won't resolve) and add corresponding <PackagReference> items instead.

Remove any imported targets/props that come from packages

Imports that packages stamp in the project files can safely be removed for modern NuGet. If someone is using a very old NuGet where this isn't true, we'll probably just WONTFIX any issues anyways.

Example:

  • StyleCop Class targets
  • Old-style xUnit targets and props

Missing reference to Microsoft.CSharp

In my projects where I use COM automation, I rely on C#'s dynamic keyword.

The converter removed the reference to Microsoft.CSharp:

<Reference Include="Microsoft.CSharp" />

but didn't add a package reference, which I had to do manually:

<PackageReference Include="Microsoft.CSharp" Version="4.6.0" /> 

Convert should exclude missing files

I have found that many my projects had old files in the file system that weren't included in the project. After the conversion they were added to the compilation which caused errors. We should detect those and add exclusions.

Solution folders should be ignored

Right now, the tool reports that solution folders aren't a supported solution item. Since they don't need any conversion but are quite common, the output shouldn't mention them at all:

Actual:

P:\CoreFxTools\src\(Notes) is not a supported solution item and will be skipped.
P:\CoreFxTools\src\experimental is not a supported solution item and will be skipped.
P:\CoreFxTools\src\apps is not a supported solution item and will be skipped.
P:\CoreFxTools\src\components is not a supported solution item and will be skipped.
P:\CoreFxTools\src\shared is not a supported solution item and will be skipped.
P:\CoreFxTools\src\tests is not a supported solution item and will be skipped.
P:\CoreFxTools\src\components is not a supported solution item and will be skipped.
P:\CoreFxTools\src\Solution Items is not a supported solution item and will be skipped.
Conversion complete!

Expected:

Conversion complete!

Spurious ProductVersion properties

After the conversion virtually all my projects have an odd <ProductVersion> in the project:

<ProductVersion>8.0.30703</ProductVersion>

UseWindowsForms true property is missing

<UseWindowsForms>true</UseWindowsForms> is missing and the line below needs to be added to all forms and .Designer files (maybe because something is missing from project file.

Imports System.Windows.Forms

Remove comment with Before/After targets

This is boiler plate that was part of a template at some point and can be safely removed:

<!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
       Other similar extension points exist, see Microsoft.Common.targets.
  <Target Name="BeforeBuild">
  </Target>
  <Target Name="AfterBuild">
  </Target>
  -->

Include list

Only have the tool work on a minimal amount of project kinds for now.

Console, class lib, WPF, WinForms

Installation doesn't work, error local source

I downloaded nupkg file from releases page and wrote the command to install,
dotnet tool install -g try-convert --version 0.1.50202 --add-source F:\Projects\C#\try-convert.0.1.50202.nupkg
but error occurs:

C:\Program Files\dotnet\sdk\3.0.100\NuGet.targets(123,5): 
error : Local source "F:\Projects\C#\try-convert.0.1.50202.nupkg" 
doesn't exist. [C:\Users\username\AppData\Local\Temp\lenwl3hq.4vq\restore.csproj]

Why is that?

Notify user about System.Web reference

We reject old-style aspnet since you need to do a rewrite, but libraries referencing System.Web are a thing, and although aren't directly translatable to .NET Core, could still be useful.

Support converting projects with nuget dependencies using project.json

Michael Bates via this tweet asked:
Some of used project.json because there was support for that in nuget and it had features that packages.config didn't. Is there conversion for that here?

From @rrelyea (me):
NuGet team had conversion code working for UWP projects when opened in VS, if they were targetting a new enough version of UWP (Min Target Version).
The main entry point for that converter code is here:
https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Clients/NuGet.VisualStudio.Implementation/Extensibility/VsProjectJsonToPackageReferenceMigrator.cs
That code was written to run inside of VS...but it might be helpful if somebody wanted to add this capability to try-convert.

Exception when trying to convert Workspace, when multiple identitcly PropertyGroup are present

Hi,
I tryed to convert a old project, but the convertion crashed with this Error:

System.ArgumentException: An element with the same key but a different value already exists. Key: Debug|AnyCPU
   at System.Collections.Immutable.ImmutableDictionary`2.HashBucket.Add(TKey key, TValue value, IEqualityComparer`1 keyOnlyComparer, IEqualityComparer`1 valueComparer, KeyCollisionBehavior behavior, OperationResult& result)
   at System.Collections.Immutable.ImmutableDictionary`2.Add(TKey key, TValue value, KeyCollisionBehavior behavior, MutationInput origin)
   at MSBuild.Abstractions.MSBuildWorkspace.DetermineConfigurations(IProjectRootElement projectRootElement) in /_/src/MSBuild.Abstractions/MSBuildWorkspace.cs:line 68
   at MSBuild.Abstractions.MSBuildWorkspace..ctor(ImmutableArray`1 paths, Boolean noBackup) in /_/src/MSBuild.Abstractions/MSBuildWorkspace.cs:line 44
   at MSBuild.Abstractions.MSBuildWorkspaceLoader.LoadWorkspace(String path, Boolean noBackup) in /_/src/MSBuild.Abstractions/MSBuildWorkspaceLoader.cs:line 45
   at MSBuild.Conversion.Program.Run(String project, String workspace, String msbuildPath, Boolean diffOnly, Boolean noBackup) in /_/src/try-convert/Program.cs:line 73

The reason is found is that one of the projects had the propertygroups definationed multiple times.
e.g.

 <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
    <DebugSymbols>true</DebugSymbols>
    <DefineDebug>true</DefineDebug>
    <DefineTrace>true</DefineTrace>
    <OutputPath>..\bin\Debug\</OutputPath>
    <DebugType>full</DebugType>
    <PlatformTarget>AnyCPU</PlatformTarget>    
    <WarningsAsErrors>41999,42016,42017,42018,42019,42020,42021,42022,42032,42036</WarningsAsErrors>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|AnyCPU'">
    <DefineTrace>true</DefineTrace>
    <OutputPath>..\bin\Release\</OutputPath>
    <Optimize>true</Optimize>
    <DebugType>pdbonly</DebugType>
    <PlatformTarget>AnyCPU</PlatformTarget>    
    <WarningsAsErrors>41999,42016,42017,42018,42019,42020,42021,42022,42032,42036</WarningsAsErrors>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
    <DebugSymbols>true</DebugSymbols>
    <DefineDebug>true</DefineDebug>
    <DefineTrace>true</DefineTrace>
    <OutputPath>..\bin\Debug\</OutputPath>
    <DebugType>full</DebugType>
...

It would be nice if these could automaticly merged.
Also if the convertion crashes when converting one project then it would be nice if there is any info about the project currently checked/converted,

Remove EnsureNuGetPackageBuildImports task

It's specified in MSTest projects and probably others.

While there's no guarantee that there isn't a valid task with a different name, the reality is that most of these tasks will be doing the 'ole, "check if there's a binary in the hint paths and error if they're not there" trick. Blegh.

Document support policy

  • Unsupported - this is an OSS project and not a product
  • AS-IS
  • No bugs are guaranteed to be fixed
  • No pull requests are guaranteed to be merged
  • Users of this tool assume full responsibility for its output

Generate a proper log per-project

Generate a log in markdown for users. Default path is the bin directory, like BenchmarkDotNet.

The log should include information about detecting things that aren't directly convertable. Examples:

  • App.config files
  • TODO

FileNotFoundException trying to load assembly System.Configuration.ConfigurationManager

First time I tried, I got:

System.IO.FileNotFoundException: Could not load file or assembly 'System.Configuration.ConfigurationManager, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.
File name: 'System.Configuration.ConfigurationManager, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
   at Microsoft.Build.Evaluation.ToolsetConfigurationReader..ctor(PropertyDictionary`1 environmentProperties, PropertyDictionary`1 globalProperties)
   at Microsoft.Build.Evaluation.ToolsetReader.ReadAllToolsets(Dictionary`2 toolsets, ToolsetRegistryReader registryReader, ToolsetConfigurationReader configurationReader, PropertyDictionary`1 environmentProperties, PropertyDictionary`1 globalProperties, ToolsetDefinitionLocations locations)
   at Microsoft.Build.Evaluation.ProjectCollection.InitializeToolsetCollection(ToolsetRegistryReader registryReader, ToolsetConfigurationReader configReader)
   at Microsoft.Build.Evaluation.ProjectCollection..ctor(IDictionary`2 globalProperties, IEnumerable`1 loggers, IEnumerable`1 remoteLoggers, ToolsetDefinitionLocations toolsetDefinitionLocations, Int32 maxNodeCount, Boolean onlyLogCriticalEvents, Boolean loadProjectsReadOnly)
   at MSBuild.Abstractions.MSBuildWorkspace..ctor(ImmutableArray`1 paths, Boolean noBackup) in /_/src/MSBuild.Abstractions/MSBuildWorkspace.cs:line 23
   at MSBuild.Abstractions.MSBuildWorkspaceLoader.LoadWorkspace(String path, Boolean noBackup) in /_/src/MSBuild.Abstractions/MSBuildWorkspaceLoader.cs:line 45
   at MSBuild.Conversion.Program.Run(String project, String workspace, String msbuildPath, Boolean diffOnly, Boolean noBackup) in /_/src/try-convert/Program.cs:line 73

What am I missing here?

De-duplicate properties

We should recognize the following situation:

  • PropertyGroup A has a property with a value
  • PropertyGroup B has the same property with the same value

We should de-duplicate them.

Example:

<PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>{5549BCD6-A213-463D-8E66-714001D974E1}</ProjectGuid>
    <OutputType>WinExe</OutputType>
    <RootNamespace>WinFormsFxClient</RootNamespace>
    <AssemblyName>WinFormsFxClient</AssemblyName>
    <TargetFrameworkVersion>v4.8</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
    <Deterministic>true</Deterministic>
    <LangVersion>8.0</LangVersion>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <PlatformTarget>AnyCPU</PlatformTarget>
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <LangVersion>8.0</LangVersion>
  </PropertyGroup>

In this case, we'll want to keep LangVersion rather than remove it, since anyone specifying it probably has a good reason to do so. But the current version of the tool will keep the two PropertyGroups and list the <LangVersion>8.0</LangVersion> once under each. Instead, it should be a top-level property.

If NuGet Targets are pressent, then the project can't be converted

Hi,
I noticed, that when a import to NuGet.targets is present, (as was added by EF6.3 install), then the project conversion fails with error 'This project has custom imports in a manner that's not supported.'
The effected line is:
<Import Project="$(SolutionDir)\.nuget\NuGet.targets" Condition="Exists('$(SolutionDir)\.nuget\NuGet.targets')" />
Seems like packages with a path in '' are ignored, maybe the path '\.nuget' should also be ignored?

Handle case where project has already migrated to package references

See the project file here

It is possible to have package references already in legacy project types. We need to be able to handle this case. Today we assume that there is a packages.config file present

System.IO.FileNotFoundException: Could not find file 'C:\source\jmarolf\RssBandit\source\RssBandit.UnitTests\packages.config'.
File name: 'C:\source\jmarolf\RssBandit\source\RssBandit.UnitTests\packages.config'
   at System.IO.FileStream.ValidateFileHandle(SafeFileHandle fileHandle)
   at System.IO.FileStream.CreateFileOpenHandle(FileMode mode, FileShare share, FileOptions options)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
   at System.IO.StreamReader.ValidateArgsAndOpenPath(String path, Encoding encoding, Int32 bufferSize)
   at System.IO.StreamReader..ctor(String path, Encoding encoding, Boolean detectEncodingFromByteOrderMarks)
   at System.IO.File.InternalReadAllText(String path, Encoding encoding)
   at System.IO.File.ReadAllText(String path)
   at PackageConversion.PackagesConfigParser.Parse(String path) in C:\source\dotnet\try-convert\src\PackageConversion\PackagesConfigParser.cs:line 26
   at PackageConversion.PackagesConfigConverter.Convert(String path) in C:\source\dotnet\try-convert\src\PackageConversion\Converter.cs:line 13
   at Conversion.ProjectRootElementExtensions.AddConvertedPackages(IProjectRootElement projectRootElement, String tfm) in C:\source\dotnet\try-convert\src\Conversion\ProjectRootElementExtensions.cs:line 240
   at Conversion.Converter.ConvertProjectFile() in C:\source\dotnet\try-convert\src\Conversion\Converter.cs:line 57
   at Conversion.Converter.Convert(String outputPath) in C:\source\dotnet\try-convert\src\Conversion\Converter.cs:line 35
   at TryConvert.Program.Run(String project, String workspace, String msbuildPath, Boolean diffOnly, Boolean noBackup) in C:\source\dotnet\try-convert\src\try-convert\Program.cs:line 84

Support $(Platform) condition references?

Hi. If csproj contains $(Platform) condition references like:

  <!-- x86 specific referneces -->
  <ItemGroup Condition=" '$(Platform)' == 'x86' ">
    <Reference Include="lib">
      <HintPath>..\tstlib\lib.dll</HintPath>
    </Reference>
    <!-- any additional x86 specific references -->
  </ItemGroup>
  <!-- x64 specific referneces -->
  <ItemGroup Condition=" '$(Platform)' == 'x64' ">
    <Reference Include="lib64">
      <HintPath>..\tstlib\lib64.dll</HintPath>
    </Reference>
    <!-- any additional x64 specific references -->
  </ItemGroup>

then tool will fail with:

System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
   at System.Collections.Immutable.ImmutableDictionary`2.get_Item(TKey key)
   at MSBuild.Conversion.Project.ProjectRootElementExtensions.RemoveOrUpdateItems(IProjectRootElement projectRootElement, ImmutableDictionary`2 differs, BaselineProject baselineProject, String tfm) in /_/src/MSBuild.Conversion.Project/ProjectRootElementExtensions.cs:line 195
   at MSBuild.Conversion.Project.Converter.ConvertProjectFile() in /_/src/MSBuild.Conversion.Project/Converter.cs:line 69
   at MSBuild.Conversion.Project.Converter.Convert(String outputPath) in /_/src/MSBuild.Conversion.Project/Converter.cs:line 28
   at MSBuild.Conversion.Program.Run(String project, String workspace, String msbuildPath, Boolean diffOnly, Boolean noBackup) in /_/src/try-convert/Program.cs:line 85

image

But such, condition references work well in .NET Core too. So, I think try-convert need to transfer them as is...

Specifying Diff-Only on VB project cause failure

If --Diff-Only is specified the Report can't be saved because the directory Project.vbproj does not exist. It doesn't exist because its the Project file not a directory.

This could be related to lack of examples that show how -p and -w are used or my lack of understanding what --diff-only does. Below is the command line I used that worked when I removed --Diff-Only. Without -m it can't find MSBuild.

try-convert.exe -w "WordFinder\WordFinder.vbproj" -m "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\amd64"

Thanks the tool worked very well and is much simpler then doing it manually.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.