resource and namedResource should be moved to buildOptions

Currently, this tool just detects any dnxXYZ tfm's and amends them to the appropriate netXYZ tfm.

However the RC2 tooling only works with net452 minimum, not net451. So this tool should probably automatically change projects that target net45, or net451, to be net 452 autoamtically.

HttpUnauthorizedResult --> HttpUnauthorizedResult

As per https://wildermuth.com/2016/05/17/Converting-an-ASP-NET-Core-RC1-Project-to-RC2

Remove the exclude and publishExclude sections entirely. You can replace them with the standard publishOptions section (or migrate the changes if you made any):

"publishOptions": {
  "include": [
    "wwwroot",
    "Views",
    "appsettings.json",
    "web.config"
  ]
},

Note that this is only including what has to be shipped with a published app instead of excluding what you don’t want. I think it’s simpler

Will allow this to be enabled / disabled when migrating (command line option).

This will automatically add the netStandard (for libraries), or netCoreApp framework (for applications) as well as bring in the relevent dependency.

This will be useful if you want to migrate your application / libraries to target these new frameworks.

If the RC1 project.json file being upgraded is an Application it will have an entry point defined like so:

 "compilationOptions": {
    "emitEntryPoint": true
  },

Applications will have the following added as a dependency, under the netstandard1.5 framework.

"dependencies": {
  "Microsoft.NETCore.App": {
    "version": "1.0.0-rc2-3002702",
    "type": "platform"
  }

If however there is no entry point, then the project is a Library. Library projects should have the following added as a dependency under the netcoreapp1.0 framework.

 "dependencies": {
    "NETStandard.Library": "1.5.0-rc2-24027"
  },

The “Verbose” logging level no longer exists, instead, change it to Debug or one of the other values

Should check for this in any appSettings.json files. and change it to Debug.

"Logging": {
  "IncludeScopes": false,
  "LogLevel": {
    "Default": "Debug",
    "System": "Information",
    "Microsoft": "Information"
  }
}

In rc1, you can use "exclude" to exclude files / paths from compilation.

{
  "exclude":  ["wwwroot","node_modules","shadowed","artifacts", "modules" ] 
}

To migrate this to rc2 it now needs to look like:

{
  "buildOptions": {  
      "compile": {      
          "exclude":  ["wwwroot","node_modules","shadowed","artifacts", "modules" ]
       },
      "embed": {
          "exclude":  ["wwwroot","node_modules","shadowed","artifacts", "modules" ] 
      }
  }
}

RC2 project.sjon format also has a copyToOutput and publishOptions section, but they don't include anything by default so no need to add any exclude in to those.

If the solutions does not contain a LaunchSettings file, a nullref exception is thrown - fix this.

Should probably delete all project.lock.json files after upgrade, so that the old cached stuff doesnt stick around.

After upgrading:

Severity    Code    Description Project File    Line    Suppression State
Error   NU1001  The dependency Autofac >= 4.0.0-rc1-177 could not be resolved.  C:\test\gluon\Gluon.WebApplication\Gluon.WebApplication.xproj   C:\test\gluon\Gluon.WebApplication\project.json 1   


Severity    Code    Description Project File    Line    Suppression State
Error   NU1001  The dependency Autofac.Extensions.DependencyInjection >= 4.0.0-rc1-177 could not be resolved.   C:\test\gluon\Gluon.Core\Gluon.Core.xproj   C:\test\gluon\Gluon.Core\project.json   1   


Severity    Code    Description Project File    Line    Suppression State
Error   NU1001  The dependency Autofac.Mef >= 4.0.0 could not be resolved.  C:\test\gluon\Gluon.Core\Gluon.Core.xproj   C:\test\gluon\Gluon.Core\project.json   1   

Should update this to RC2 version.

According to this: http://stackoverflow.com/questions/37380716/automating-nuget-package-push-with-netcore-rc2

prebuild changed to precompile, and postbuild changed to postcompile. Should rename them if they exist in project.json files.

It would be great if this tool could handle finding and replacing namespaces in source code files, to it could handle for example the namespace changes like the ones document here: https://docs.efproject.net/en/latest/miscellaneous/rc1-rc2-upgrade.html

After converting a hello world project on Windows the project.json file is ONE long line which is difficult to inspect and maintain. It would be nice if it was formatted with line breaks and indent like the source project.json file was.

If the application is an MVC application, the Views folder should be copied to output in RC2, because if it isn't then when you run your application, it will fail to find them..

"copyToOutput": {
      "include": [
        "appsettings.json",
        "views"
      ]
    }

This tool currently migrates and dependencies on the Microsoft.AspNet.IISPlatformHandler package, to the newer Microsoft.AspNetCore.Server.IISIntegration package (which is correct) - but as part of this change there are also implications for startup.cs. In RC2, you now have to create and configure your own host in the entry point Main(args) for your application, and some of the methods to do this configuration are found in a new package - Microsoft.AspNetCore.Hosting which you have to then add. This tool should automatically add this package for you to save you the hassle, whenever it detects a project that references Microsoft.AspNetCore.Server.IISIntegration

The following properties now need to be moved to "packOptions" if they exist in project.json

• repository
• tags
• licenseUrl
• projectUrl

The tool should detect dnxcore50 in the frameworks section of an RC1 application project.json file, and convert it to be

"netcoreapp1.0": {
    "imports": [
      "dotnet5.6",
      "dnxcore50",
      "portable-net45+win8"
    ]
  }

If the project is a library project (i.e doesn't have an entry point defined) then it should replace dnxcore50 with netstandard framework instead.

Should detect NuGet.Config file and ensrue the CI feed is added.

<add key="AspNetCiDev" value="https://www.myget.org/F/aspnetcidev/api/v3/index.json" />

Microsoft.AspNet.FileProviders.* packages were renamed to Microsoft.Extensions.FileProviders.*
At the moment, these are being renamed by a convention to `Microsoft.AspNetCore.FileProviders.* which is wrong.

Fix.

Commands

As per https://wildermuth.com/2016/05/17/Converting-an-ASP-NET-Core-RC1-Project-to-RC2

The commands and tooling have changed a bit and in RC1 they require a little more work. You need to change their versions to an object tag (this is going to be a temporary change until the tooling gets past Preview):

"Microsoft.AspNetCore.Razor.Tools": {
  "version": "1.0.0-preview1-final",
  "type": "build"
},
"Microsoft.EntityFrameworkCore.Tools": {
  "version": "1.0.0-preview1-final",
  "type": "build"
},
"Microsoft.VisualStudio.Web.CodeGenerators.Mvc": {
  "version": "1.0.0-preview1-final",
  "type": "build"
}

You’ll also need to add a new tool called CodeGeneration Tools:

"Microsoft.VisualStudio.Web.CodeGeneration.Tools": {
    "version": "1.0.0-preview1-final",
    "type": "build"
  }

Rename the ‘commands’ to ‘tools’. You’ll need to empty the collection and add the current tools from the preview like so:

"tools": {
  "Microsoft.AspNetCore.Razor.Tools": {
    "version": "1.0.0-preview1-final",
    "imports": "portable-net45+win8+dnxcore50"
  },
  "Microsoft.AspNetCore.Server.IISIntegration.Tools": {
    "version": "1.0.0-preview1-final",
    "imports": "portable-net45+win8+dnxcore50"
  },
  "Microsoft.EntityFrameworkCore.Tools": {
    "version": "1.0.0-preview1-final",
    "imports": [
      "portable-net45+win8+dnxcore50",
      "portable-net45+win8"
    ]
  },
  "Microsoft.Extensions.SecretManager.Tools": {
    "version": "1.0.0-preview1-final",
    "imports": "portable-net45+win8+dnxcore50"
  },
  "Microsoft.VisualStudio.Web.CodeGeneration.Tools": {
    "version": "1.0.0-preview1-final",
    "imports": [
      "portable-net45+win8+dnxcore50",
      "portable-net45+win8"
    ]
  }
}

Need to complete the command line interface so you can run this .exe against your solution, to perform the upgrade from RC1 to RC2.

Something like:

AspNetRC1toRC2UpgradeTool.exe UpgradeSolution --solutionDir "C:/SomeFolder/MySolution/"

The idea is that this tool will detect all projects within the solution directory and upgrade them to RC2.

This means it will:

1. Upgrade the projects (project.json files and xproj files if present)
2. Update the global.json file
3. Any other solution wide actions that I bake in to ease the migration process.

Here's the Weekly Digest for dazinator/AspNetSolutionUpgradeTool:

ISSUES

Last week, no issues were created.

PULL REQUESTS

Last week, no pull requests were created, updated or merged.

COMMITS

Last week there were no commits.

CONTRIBUTORS

Last week there were no contributors.

STARGAZERS

Last week there were no stargazers.

RELEASES

Last week there were no releases.

That's all for last week, please 👀 Watch and ⭐ Star the repository dazinator/AspNetSolutionUpgradeTool to receive next weekly updates. 😃

You can also view all Weekly Digests by clicking here.

Your Weekly Digest bot. 📆

In RC2, you have to explicitly copy appSettings files to the output directory, otherwise when you run your application it can;t find them. You do this by adding this to your project.json file:;

  "buildOptions": {

    "copyToOutput": [
      "appsettings.json",
      "appsettings.Staging.json",
      "appsettings.Production.json"     
    ]
  },

Likewise userSecrets won't work anymore, unless project.json is also copied, (as userSecrets has to read the userSecrets id from the project.json file).

However I don't want the tool to automatically modify project.json files to copy project.json to the output directory because it sounds like that may be in the process of changing: aspnet/UserSecrets#62

Note: the tool already adds appSettings.json to publishOptions, however this logic could do with sprucing up too, as ideally it should add a line for each appSettings file in you project - i.e appSettings.development.json for example.

Implement ugrade for global.json files.

Update version of global.json to match RC2

"version": "1.0.0-rc1-update1" // BEFORE
"version": "1.0.0-rc2-20221" // AFTER

This tool could be a bit fancy, and try to detect and refactor the old RC1 entry point method:

public static void Main(string[] args) => WebApplication.Run<Startup>(args);

To be the RC2 version:

public static void Main(string[] args)
{
    var host = new WebHostBuilder()
        .UseKestrel()
        .UseContentRoot(Directory.GetCurrentDirectory())
        .UseIISIntegration()
        .UseStartup<Startup>()
        .Build();

    host.Run();
}

This may not be a perfect refactoring, but perhaps if the tool comments out the old method rather than removing it, it might mitigate some issues.. I'll let this idea cool down for a bit.

I just tried the tool on a hello world example. It converted well (great) and compiled but when running it stalled instead of serving a web page. The reason was that the applicationUrl was wrong. After changing the Url to "http://localhost:50000/" (50000 is the new default in rc2) it worked.

The following extension methods were moved into a new package for RC2:

app.UseDeveloperExceptionPage();
app.UseExceptionHandler("/Home/Error");

This tool should ensure this package is added to MVC projects.

Some things in razor files need to be changed, due to namespaces changes etc from RC1 to RC2.

For example:

I would like to learn how to parse Razor files programatically, and then if I can do this, I can add some migration actions for razor files to this tool, similar to the Roslyn based C# actions that fixes using statements in C# files.

I'd like to put the re-usable classes to do with upgrading a solution (modifying all project.json etc) into a seperate assembly that can be put on NuGet.

I have a need to re-use this logic in a seperate project.

Should check for an .xproj file alongside the project.json file, and if found, the following changes should be made:

The xproj file has reference to the older RC1 tools, so you’ll need to edit it and change it manually. Find and replace the following strings in it:

\DNX\Microsoft.DNX.Props –> \DotNet\Microsoft.DotNet.Props
\DNX\Microsoft.DNX.targets –> \DotNet.Web\Microsoft.DotNet.Web.targets

Note for non web projects:

\DNX\Microsoft.DNX.Props –> \DotNet\Microsoft.DotNet.Props
\DNX\Microsoft.DNX.targets –> \DotNet\Microsoft.DotNet.targets

You’ll also want to change the BaseIntermediateOutputPath to:

<BaseIntermediateOutputPath Condition="'$(BaseIntermediateOutputPath)'=='' ">.\obj</BaseIntermediateOutputPath>

Finally, add target framework just after the OutputPath:

<OutputPath Condition="'$(OutputPath)'=='' ">.\bin\</OutputPath>
<TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion>

Detect RC1 Serilog dependency and change it to RC2 version which was renamed.

Serilog.Framework.Logging > Serilog.Extensions.Logging version 1.0.0-rc2-10110

At the moment, the tool updates RC1 packages in the top level dependencies section in the project.json files, so if your RC1 dependencies are in a framework specific node - like the following example, hen they are currently ignored by this tool:

"frameworks": {
 "net452": {
      "dependencies": {
        "Microsoft.AspNet.Http.Abstractions": "1.0.0-rc1-final",
        "Microsoft.Extensions.Logging": "1.0.0-rc1-final",
        "Microsoft.AspNet.Http.Extensions": "1.0.0-rc1-final",
        "Microsoft.AspNet.Mvc.TagHelpers": "6.0.0-rc1-final",
        "Newtonsoft.Json": "4.0.1"
      }
    },
    "net40": {
      "dependencies": {
        "Common.Logging": "3.0.0",
        "Microsoft.Bcl.Async": "1.0.168",
        "Microsoft.Owin": "2.1.0",
        "WebActivatorEx": "2.0.0",
        "Newtonsoft.Json": "4.0.1"
      },
      "frameworkAssemblies": {
        "System.Web": "4.0.0.0",
        "System.XML": "4.0.0.0"
      }
    },
}

I should make the tool also run the RC1 to RC2 package upgrade logic against specific framework dependencies section (frameworks relevent to RC1) which are:

• dnx
• dnx45
• dnx451
• dnx452
• dnxcore
• dnxcore50

Some package migrations will add a package if it is not allready present. I need to be sure that when adding packages at this level, it checks the top level dependencies section to see if the package exists (as well as the current framework level depedencies) before adding any new package.

content, contentExclude and contentFiles in the RC1 format project.json, should all be moved to the new include, exclude, and includeFiles property under publishOptions and buildOptions/copyToOutput respectively.

Should detect XUnit in RC1 Library projects, and migrate it to the RC2 format.

In RC1 it looks like this:

 "dependencies": {  
    "xunit": "2.1.0",
    "xunit.runner.dnx": "2.1.0-rc1-build204", 
  },

It may instead be listed under frameworks dependencies for dnx451 like this:

 "frameworks": {
    "dnx451": {
      "dependencies": {      
        "xunit": "2.1.0",
        "xunit.runner.dnx": "2.1.0-rc1-build204"
      }    
    }
  },

And then it has this command:

"commands": {
    "test": "xunit.runner.dnx"
  },

In RC2 it needs to look like this:

{
    "dependencies": {
        "xunit": "2.1.0",
        "dotnet-test-xunit": "1.0.0-*"
    },
    "testRunner": "xunit"
}

tests are then run from command line using:

# Restore NuGet packages
dotnet restore

# Run tests in current directory
dotnet test

# Run tests if tests are not in the current directory
dotnet -p path/to/project test // not yet implemented

Think if the project is a library project, then in RC2 it needs to be turned into an application by giving it an entry point - emitEntryPoint = true under build options.

Should update the "frameworks" section in the project.json file, to the new naming style.

If dnxcore is currently present, then should change that to:

"frameworks": {
  "netcoreapp1.0": {
    "imports": [
      "dotnet5.6",
      "dnxcore50",
      "portable-net45+win8"
    ]
  }
}

If dnx451 is present, then should change that to:

"frameworks": {
  "net452": { }
}

I think this tool is wonderfull but I would like to use it not just for RC1-RC2 but also for RC1/2-1.0.0. The new version 1.0.0 is currently scheduled for 27th of June.

I just looked at the prelimary list of changes 1.0.0 which currently numbers about 15 breaking changes in addition to new version numbers. I therefore think this tool could be quite useful for changing to 1.0.0 also ?

If your RC1 project currently references Microsoft.Extensions.PlatformAbstractions then it's possible that you were using ILibraryManager which is no longer available in RC2 as per aspnet/Announcements#149.

To ease migration, this tool should detect when Microsoft.Extensions.PlatformAbstractions is referenced, and automatically add the Microsoft.Extensions.DependencyModel dependency as part of the migration.

Automate as many of the things as possible, as mentioned here:

aspnet/Announcements#175

I initially dismissed this idea, however I think it would be good to perform some basic analysis of CSharp code files, and do some refactorings like namespace changes as per #11

Never done this kind of thing before but I will experiment with: https://github.com/dotnet/roslyn/wiki/Getting-Started-C%23-Syntax-Analysis
to see if it is viable.

Change the compliationOptions in project.json to buildOptions:

"buildOptions": {
  "emitEntryPoint": true
}

Should check for an migrate the following RC1 EF packages to the RC2 equivalents:

Under the dependencies section:

The following packages should be explicitly migrated to new names, and the packages of package type == build need to be changed to the expanded format that lists the version number and the type:

• Should then detect any packages with a name that starts with "Microsoft.AspNet." and change the package name to be "Microsoft.AspNetCore." with the exception of the "Microsoft.AspNet.WebApi.Client" package which needs to remain.

The following packages can be removed:

Should then apply the following heuristic to update all microsoft RC1 packages to RC2 version numbers:

I think this is a decent heuristic to migrate most of the packages from RC1 to RC2, however there may be exceptions so this won't cover all packages,and this logic may need to be extended in the future.

Here's the Weekly Digest for dazinator/AspNetSolutionUpgradeTool:

ISSUES

Last week, no issues were created.

PULL REQUESTS

Last week, no pull requests were created, updated or merged.

COMMITS

Last week there were no commits.

CONTRIBUTORS

Last week there were no contributors.

STARGAZERS

Last week there were no stargazers.

RELEASES

Last week there were no releases.

That's all for last week, please 👀 Watch and ⭐ Star the repository dazinator/AspNetSolutionUpgradeTool to receive next weekly updates. 😃

You can also view all Weekly Digests by clicking here.

Your Weekly Digest bot. 📆

As per this breaking change announcement: aspnet/Announcements#180

Should add Microsoft.Extensions.Options.ConfigurationExtensions package to MVC projects automatically.