@blackdwarf
@livarcocc
Installed VS2017
Opened working solution developed in (and operational in) VS2015 in VS2017
Migration required
Migration fails
That it would actually migrate and work.
Migration fails.
Failed to migrate XProj project XXX.Web. 'dotnet migrate --skip-backup -s -x ... --format-report-file-json' exited with error code 1.
MIGRATE1019::Unsupported Script Event Hook: postbuild is an unsupported script event hook for project migration
Seems like an old issue reported from VS2017 RC with multiple projects in the solution??
Also here: https://developercommunity.visualstudio.com/content/problem/15229/needs-migration-after-migration.html
Opening the solution in VS2017 shows both projects needing migration.
I reverted everything and retried using command line dotnet migrate --skip-backup and it seemed to work successfully but opening the solution projects needed to be re-loaded (and migrated) which failed.
dotnet --info
output:
.NET Command Line Tools (1.0.0)
Product Information:
Version: 1.0.0
Commit SHA-1 hash: e53429feb4
Runtime Environment:
OS Name: Windows
OS Version: 6.1.7601
OS Platform: Windows
RID: win7-x64
Base Path: C:\Program Files\dotnet\sdk1.0.0
project.json
{
"dependencies": {
"Microsoft.EntityFrameworkCore.SqlServer": "1.1.0",
"Microsoft.EntityFrameworkCore.Design": {
"version": "1.1.0",
"type": "build"
},
"Microsoft.AspNetCore.Antiforgery": "1.1.0",
"Microsoft.AspNetCore.Authentication": "1.1.0",
"Microsoft.AspNetCore.Authentication.Cookies": "1.1.0",
"Microsoft.AspNetCore.Authentication.OpenIdConnect": "1.1.0",
"Microsoft.AspNetCore.Diagnostics": "1.1.0",
"Microsoft.AspNetCore.Server.IISIntegration": "1.1.0",
"Microsoft.AspNetCore.Mvc": "1.1.0",
"Microsoft.AspNetCore.Mvc.TagHelpers": "1.1.0",
"Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
"Microsoft.AspNetCore.StaticFiles": "1.1.0",
"Microsoft.AspNetCore.Tooling.Razor": "0.0.1-alpha",
"Microsoft.Extensions.Options.ConfigurationExtensions": "1.1.0",
"Microsoft.Extensions.Configuration.Json": "1.1.0",
"Microsoft.Extensions.Logging": "1.1.0",
"Microsoft.Extensions.Logging.Console": "1.1.0",
"Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.1.0",
"Newtonsoft.Json": "9.0.1",
"Sendgrid": "5.1.0",
"Serilog": "2.3.0",
"Serilog.Extensions.Logging": "1.3.1",
"Serilog.Sinks.Literate": "2.0.0",
"Serilog.Sinks.File": "3.2.0",
"Serilog.Sinks.RollingFile": "3.2.0",
"XXX.Data": "*",
"WindowsAzure.Storage": "5.0.0",
},
"tools": {
"Microsoft.AspNetCore.Razor.Tools": "1.0.0-preview2-final",
"Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.0.0-preview2-final",
"Microsoft.EntityFrameworkCore.Tools.DotNet": "1.0.0-preview3-final"
},
"frameworks": {
"net451": {}
},
"buildOptions": {
"emitEntryPoint": true,
"preserveCompilationContext": true
},
"runtimeOptions": {
"configProperties": {
"System.GC.Server": true
}
},
"publishOptions": {
"include": [
"wwwroot",
"**/*.cshtml",
"appsettings.json",
"web.config"
],
"exclude": [
"node_modules",
"bower_components",
"**.xproj",
"**.user",
"**.vspscc"
]
},
"scripts": {
"postbuild": "grunt build",
"postrestore": [ "npm install", "bower install" ],
"postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]
},
"version": "1.0.0-*",
"webroot": "wwwroot"
}
I worked around this manually.
This is how I got there:
This was a scenario that should have been handled for me without having to research this all myself.
I got the same issue. I just had to remove the SDK version specification from the "global.json" file.
This is an event that was not supported in preview2, we did support an event called precompile and if you replace prebuild with precompile migration should work fine.
Also, the reason why you had to clean the xprojs and the project.json files manually is because you passed the --skip-backup option to the migrate command.
The reason why we don't handle the prebuild event is because migration was built to support valid preview2 project.json files and do a best effort on pre-preview2, as there as no good set of options available to us to map those project.json to csproj.
Most helpful comment
I worked around this manually.
This is how I got there:
This was a scenario that should have been handled for me without having to research this all myself.