2016-12-20 22:19:37 +00:00
|
|
|
// Copyright (c) .NET Foundation and contributors. All rights reserved.
|
|
|
|
// Licensed under the MIT license. See LICENSE file in the project root for full license information.
|
|
|
|
|
|
|
|
using System;
|
|
|
|
using System.Collections.Generic;
|
|
|
|
using System.IO;
|
|
|
|
using System.Linq;
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
using System.Text;
|
2016-12-20 22:19:37 +00:00
|
|
|
using Microsoft.DotNet.Internal.ProjectModel.Utilities;
|
|
|
|
|
|
|
|
namespace Microsoft.DotNet.ProjectJsonMigration
|
|
|
|
{
|
|
|
|
internal class MigrationBackupPlan
|
|
|
|
{
|
2017-01-20 20:21:04 +00:00
|
|
|
private const string TempCsprojExtention = ".migration_in_place_backup";
|
|
|
|
|
2016-12-20 22:19:37 +00:00
|
|
|
private readonly FileInfo globalJson;
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
private readonly Dictionary<DirectoryInfo, IEnumerable<FileInfo>> mapOfProjectBackupDirectoryToFilesToMove;
|
|
|
|
|
|
|
|
public DirectoryInfo RootBackupDirectory { get; }
|
|
|
|
public DirectoryInfo[] ProjectBackupDirectories { get; }
|
|
|
|
|
|
|
|
public IEnumerable<FileInfo> FilesToMove(DirectoryInfo projectBackupDirectory)
|
|
|
|
=> mapOfProjectBackupDirectoryToFilesToMove[projectBackupDirectory];
|
2016-12-20 22:19:37 +00:00
|
|
|
|
|
|
|
public MigrationBackupPlan(
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
IEnumerable<DirectoryInfo> projectDirectories,
|
2016-12-20 22:19:37 +00:00
|
|
|
DirectoryInfo workspaceDirectory,
|
|
|
|
Func<DirectoryInfo, IEnumerable<FileInfo>> getFiles = null)
|
|
|
|
{
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
if (projectDirectories == null)
|
|
|
|
{
|
|
|
|
throw new ArgumentNullException(nameof(projectDirectories));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!projectDirectories.Any())
|
2016-12-20 22:19:37 +00:00
|
|
|
{
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
throw new ArgumentException("No project directories provided.", nameof(projectDirectories));
|
2016-12-20 22:19:37 +00:00
|
|
|
}
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
|
2016-12-20 22:19:37 +00:00
|
|
|
if (workspaceDirectory == null)
|
|
|
|
{
|
|
|
|
throw new ArgumentNullException(nameof(workspaceDirectory));
|
|
|
|
}
|
|
|
|
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
MigrationTrace.Instance.WriteLine("Computing migration backup plan...");
|
2016-12-20 22:19:37 +00:00
|
|
|
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
projectDirectories = projectDirectories.Select(pd => new DirectoryInfo(pd.FullName.EnsureTrailingSlash()));
|
2016-12-20 22:19:37 +00:00
|
|
|
workspaceDirectory = new DirectoryInfo(workspaceDirectory.FullName.EnsureTrailingSlash());
|
|
|
|
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
MigrationTrace.Instance.WriteLine($" Workspace: {workspaceDirectory.FullName}");
|
|
|
|
foreach (var projectDirectory in projectDirectories)
|
|
|
|
{
|
|
|
|
MigrationTrace.Instance.WriteLine($" Project: {projectDirectory.FullName}");
|
|
|
|
}
|
2016-12-20 22:19:37 +00:00
|
|
|
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
var rootDirectory = FindCommonRootPath(projectDirectories.ToArray()) ?? workspaceDirectory;
|
|
|
|
rootDirectory = new DirectoryInfo(rootDirectory.FullName.EnsureTrailingSlash());
|
|
|
|
|
|
|
|
MigrationTrace.Instance.WriteLine($" Root: {rootDirectory.FullName}");
|
|
|
|
|
|
|
|
globalJson = new FileInfo(
|
2016-12-20 22:19:37 +00:00
|
|
|
Path.Combine(
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
workspaceDirectory.FullName,
|
|
|
|
"global.json"));
|
2016-12-20 22:19:37 +00:00
|
|
|
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
RootBackupDirectory = new DirectoryInfo(
|
|
|
|
GetUniqueDirectoryPath(
|
|
|
|
Path.Combine(
|
|
|
|
rootDirectory.FullName,
|
|
|
|
"backup"))
|
|
|
|
.EnsureTrailingSlash());
|
2016-12-20 22:19:37 +00:00
|
|
|
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
MigrationTrace.Instance.WriteLine($" Root Backup: {RootBackupDirectory.FullName}");
|
2016-12-20 22:19:37 +00:00
|
|
|
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
var projectBackupDirectories = new List<DirectoryInfo>();
|
|
|
|
mapOfProjectBackupDirectoryToFilesToMove = new Dictionary<DirectoryInfo, IEnumerable<FileInfo>>();
|
|
|
|
getFiles = getFiles ?? (dir => dir.EnumerateFiles());
|
2016-12-20 22:19:37 +00:00
|
|
|
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
foreach (var projectDirectory in projectDirectories)
|
|
|
|
{
|
|
|
|
var projectBackupDirectory = ComputeProjectBackupDirectoryPath(rootDirectory, projectDirectory, RootBackupDirectory);
|
|
|
|
var filesToMove = getFiles(projectDirectory).Where(NeedsBackup);
|
2016-12-20 22:19:37 +00:00
|
|
|
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
projectBackupDirectories.Add(projectBackupDirectory);
|
|
|
|
mapOfProjectBackupDirectoryToFilesToMove.Add(projectBackupDirectory, filesToMove);
|
|
|
|
}
|
2016-12-20 22:19:37 +00:00
|
|
|
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
ProjectBackupDirectories = projectBackupDirectories.ToArray();
|
|
|
|
}
|
2016-12-20 22:19:37 +00:00
|
|
|
|
|
|
|
public void PerformBackup()
|
|
|
|
{
|
|
|
|
if (globalJson.Exists)
|
|
|
|
{
|
2016-12-21 00:03:00 +00:00
|
|
|
PathUtility.EnsureDirectoryExists(RootBackupDirectory.FullName);
|
2016-12-20 22:19:37 +00:00
|
|
|
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
globalJson.MoveTo(
|
|
|
|
Path.Combine(
|
|
|
|
RootBackupDirectory.FullName,
|
|
|
|
globalJson.Name));
|
2016-12-20 22:19:37 +00:00
|
|
|
}
|
|
|
|
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
foreach (var kvp in mapOfProjectBackupDirectoryToFilesToMove)
|
|
|
|
{
|
|
|
|
var projectBackupDirectory = kvp.Key;
|
|
|
|
var filesToMove = kvp.Value;
|
|
|
|
|
|
|
|
PathUtility.EnsureDirectoryExists(projectBackupDirectory.FullName);
|
|
|
|
|
|
|
|
foreach (var file in filesToMove)
|
|
|
|
{
|
|
|
|
var fileName = file.Name.EndsWith(TempCsprojExtention)
|
|
|
|
? Path.GetFileNameWithoutExtension(file.Name)
|
|
|
|
: file.Name;
|
|
|
|
|
|
|
|
file.MoveTo(
|
|
|
|
Path.Combine(
|
|
|
|
projectBackupDirectory.FullName,
|
|
|
|
fileName));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2016-12-20 22:19:37 +00:00
|
|
|
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
private static DirectoryInfo ComputeProjectBackupDirectoryPath(
|
|
|
|
DirectoryInfo rootDirectory, DirectoryInfo projectDirectory, DirectoryInfo rootBackupDirectory)
|
|
|
|
{
|
|
|
|
if (PathUtility.IsChildOfDirectory(rootDirectory.FullName, projectDirectory.FullName))
|
2016-12-20 22:19:37 +00:00
|
|
|
{
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
var relativePath = PathUtility.GetRelativePath(
|
|
|
|
rootDirectory.FullName,
|
|
|
|
projectDirectory.FullName);
|
|
|
|
|
|
|
|
return new DirectoryInfo(
|
|
|
|
Path.Combine(
|
|
|
|
rootBackupDirectory.FullName,
|
|
|
|
relativePath)
|
|
|
|
.EnsureTrailingSlash());
|
|
|
|
}
|
|
|
|
|
|
|
|
// Ensure that we use a unique name to avoid collisions as a fallback.
|
|
|
|
return new DirectoryInfo(
|
|
|
|
GetUniqueDirectoryPath(
|
|
|
|
Path.Combine(
|
|
|
|
rootBackupDirectory.FullName,
|
|
|
|
projectDirectory.Name)
|
|
|
|
.EnsureTrailingSlash()));
|
|
|
|
}
|
|
|
|
|
|
|
|
private static bool NeedsBackup(FileInfo file)
|
|
|
|
=> file.Name == "project.json"
|
|
|
|
|| file.Extension == ".xproj"
|
|
|
|
|| file.FullName.EndsWith(".xproj.user")
|
|
|
|
|| file.FullName.EndsWith(".lock.json")
|
|
|
|
|| file.FullName.EndsWith(TempCsprojExtention);
|
|
|
|
|
|
|
|
private static string GetUniqueDirectoryPath(string directoryPath)
|
|
|
|
{
|
|
|
|
var candidatePath = directoryPath;
|
2017-01-20 20:21:04 +00:00
|
|
|
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
var suffix = 1;
|
|
|
|
while (Directory.Exists(candidatePath))
|
|
|
|
{
|
|
|
|
candidatePath = $"{directoryPath}_{suffix++}";
|
2017-01-20 20:21:04 +00:00
|
|
|
}
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
|
|
|
|
return candidatePath;
|
|
|
|
}
|
|
|
|
|
|
|
|
private static DirectoryInfo FindCommonRootPath(DirectoryInfo[] paths)
|
|
|
|
{
|
|
|
|
var pathSplits = new string[paths.Length][];
|
|
|
|
var shortestLength = int.MaxValue;
|
|
|
|
for (int i = 0; i < paths.Length; i++)
|
|
|
|
{
|
|
|
|
pathSplits[i] = paths[i].FullName.Split(new[] { Path.DirectorySeparatorChar });
|
|
|
|
shortestLength = Math.Min(shortestLength, pathSplits[i].Length);
|
|
|
|
}
|
|
|
|
|
|
|
|
var builder = new StringBuilder();
|
|
|
|
var splitIndex = 0;
|
|
|
|
while (splitIndex < shortestLength)
|
|
|
|
{
|
|
|
|
var split = pathSplits[0][splitIndex];
|
|
|
|
|
|
|
|
var done = false;
|
|
|
|
for (int i = 1; i < pathSplits.Length; i++)
|
|
|
|
{
|
|
|
|
if (pathSplits[i][splitIndex] != split)
|
|
|
|
{
|
|
|
|
done = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (done)
|
|
|
|
{
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
builder.Append(split);
|
|
|
|
builder.Append(Path.DirectorySeparatorChar);
|
|
|
|
splitIndex++;
|
|
|
|
}
|
|
|
|
|
|
|
|
return new DirectoryInfo(builder.ToString().EnsureTrailingSlash());
|
2017-01-20 20:21:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
public static void RenameCsprojFromMigrationOutputNameToTempName(string outputProject)
|
|
|
|
{
|
|
|
|
var backupFileName = $"{outputProject}{TempCsprojExtention}";
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
|
2017-01-20 20:21:04 +00:00
|
|
|
if (File.Exists(backupFileName))
|
|
|
|
{
|
|
|
|
File.Delete(backupFileName);
|
2016-12-20 22:19:37 +00:00
|
|
|
}
|
Create backup folder in the directory where 'dotnet migrate' is executed (#5306)
* Create backup folder in the directory where 'dotnet migrate' is executed
With this change, 'dotnet migrate' will create the backup folder in the workspace directory rather
than the parent of the workspace directory. This solves two problems:
1. It makes it easier for the user where the backup is -- it's in the directory they targeted with
'dotnet migrate'.
2. It solves a problem of file oollisions with global.json files when migrating multiple projects.
Consider the following directory structure:
root
|
project1
|
global.json
|
src
|
project1
project2
|
global.json
|
src
|
project2
Prior to this change, running 'dotnet migrate' project1 and then running it again in project2
would have caused an exception to be thrown because the migration would try to produce a backup
folder like so:
root
|
backup
| |
| global.json
| |
| project1
| |
| project2
|
|
project1
|
src
|
project1
project2
|
src
|
project2
Now, we produce the following structure, which has no collisions:
root
|
project1
|
backup
| |
| global.json
| |
| project1
|
src
|
project1
|
project2
|
backup
| |
| global.json
| |
| project2
|
src
|
project2
In addition, to help avoid further collisions, a number is appened to the backup folder's name if
it already exists. So, if the user runs dotnet migrate again for some reason, they'll see backup_1,
backup_2, etc.
* Fix test helper
* Fix foolish bug causing infinite loop
* Fix up a couple more tests
* Rework MigrationBackupPlan to process all projects at once
* Fix up tests
* Still fixing tests
* Compute common root folder of projects to determine where backup folder should be placed
* Fix typo
* Fix test to not look in backup folder now that it's in a better location
2017-01-21 09:58:28 +00:00
|
|
|
|
2017-01-20 20:21:04 +00:00
|
|
|
File.Move(outputProject, backupFileName);
|
2016-12-20 22:19:37 +00:00
|
|
|
}
|
|
|
|
}
|
2016-12-21 00:03:00 +00:00
|
|
|
}
|