Unhandled Exception: System.ComponentModel.Win32Exception: The system cannot fin d the file specified

[buraktamturk]

I were having issues with 2.0.0 after updating VS 2017. So, upgraded to 2.0.1, and this issue occurs.

System: Windows 7 Project depends on net461 full framework.

Project File: https://paste.sh/M10hwPxO#UxoJ7NpHgnoDtRavWQoeheIT

Unhandled Exception: System.ComponentModel.Win32Exception: The system cannot find the file specified
   at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start()
   at Microsoft.DotNet.Cli.Utils.Command.Execute()
   at Migrator.EF6.Tools.Program.Dispatch(String[] args)
   at Migrator.EF6.Tools.Program.Main(String[] args)

[mrahhal]

I checked the project file, but I really can't know what's going on like this. I need a minimal repro that I can clone and try. Other than that, I can't do anything.

Try running the sample in this project. Try creating a new a mvc project file and add Migrator.EF6 (recheck the steps), and run it. It should work. Then start editing the project file to match what you have, if you face the problem, you should be able to tell what's causing it.

Question, so what I understood is that you were using this before for aspnetcore 1.0 and it was working, and this started happening after upgrading? Or is this the first time you're using it?

[buraktamturk]

Yes, I have been using this library since it has existed. I just had an error with the 2.0.0 after I have updated the Visual Studio 2017, before the update version 2.0.0 was working. I upgraded it to 2.0.1, I thought it was going to fix the issues that I am experiencing.

However, I just found the error by looking the source code. It tries to execute dotnet-ef.exe from "C:\path\to\project\bin\Debug\net461", but it the file doesn't appear on that folder instead, it appears on "C:\path\to\project\bin\Debug\net461\win10-x64". I copied the folder to parent folder, just to add one migration. I hope I gave the right information.

[mrahhal]

I see. I remember I changed something related to building the path in 2.0.1. And this particular problem is related to Self Contained Deployment. In FDD, it should work. I'll look into it asap.

[mrahhal]

I think the solution to this would be an extra argument that specifies the platform (ex. "win10-x64"). Because there'd be no way to determine that from the project if there are multiple platforms you're building against (which would usually be the case). I have no idea how SCD used to work before 2.0.

So it'll be something like

dotnet ef migrations add Some --runtime win10-x64

Although.. Because you're using this, this using EntityFramework6, you'll be only building for windows. So is <RuntimeIdentifiers>win10-x64<RuntimeIdentifiers> even necessary at all?

[mrahhal]

For now, can you please try this nupkg and check if this solves your problem? (You'll have to use a local nuget feed)

[wh1sp3r]

Hi, your nupgk attached is working fine now with --runtime. By the way, RuntimeIdentifiers is important, when you are using kestrel as it chooses correct libuv.dll.

[buraktamturk]

I didn't had a change to test the nupkg (I had a lot of headache creating local nuget repository, gave up at some point), however, removing "RuntimeIdentifiers" from the project file worked for once (one day), but it broke at some point (and I am sure that I didn't changed anything about the project and its dependencies, it gave an error while loading the assembly in the dotnet cli, I don't remember the details).

Also, I still couldn't figured how, I accidentally make VS to compile on the directory that Migrator.EF6 expects (with RuntimeIdentifiers set on the project!), but again, after one day, suddenly, it began to copy on the win10-x64 folder.

I am currently copying the output to the parent folder, and running this tool, as a workaround.

The entire .NET (core) system driving me crazy.

[mrahhal]

@wh1sp3r thanks.

@buraktamturk

To add a local package feed:

nuget sources add -Name LocalPackages -Source "C:/path/to/folder"

I'm not sure why it would stop working if you've removed the RuntimeIdentifier. In any case, I'll be releasing a new version with the fix in #54. Please try it and let me know if you face any problems.

[mrahhal]

Please try version 2.0.2. Note that you'll need to specify the runtime target using:

dotnet ef ... --runtime win10-x64