Just wanted to say I am also having this issue. Everything migrates over just fine, but will not build.
Of course there is no way to add this reference since this reference should automatically be included in anything targeting .NET 4.5 (Target Framework is 4.6.1). I have tried a complete rebuild and packages have no issues restoring.
I'll open up an issue on GitHub and reference this post and provide a bit more info.
When I try using the 1.0.0-preview2-1-003177 I get the error from the original post:
System.IO.FileLoadException was unhandled
Message: An exception of type 'System.IO.FileLoadException' occurred in mscorlib.dll and wasn't handled before a managed/native boundary
Additional information: Could not load file or assembly 'System.IO.FileSystem, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I also went and removed the x86 version of the dotnet SDK and I still receive the same error. Later this weekend I may try from and remove all of the dotnet sdk and install everything again just to see what happens. As I am pretty confused as to why I can't run this template but pretty much any else that is dotnet CORE I can build and run without any issues (in both VS 2015 and VS 2017 RC).
I do. One thing I noticed is that the project seems to want to use the 32-bit versions. Under Programs Files (x86) I have a "1.0.0-preview2-1-003177"
Under Program Files/dotnet/sdk I have both "1.0.0-preview2-1-003177" and "1.0.0-preview2-003131"
Does that sound right or is something off? If I try to use the "1.0.0-preview2-003131" one in my global.json file it complains that it can't find that SDK version in my Programs Files(x86) folder.
Ok so this computer didn't have Visual Studio update 3 or the .NET Core Tools for Visual Studio 2015 so I went through that process, so this test was done on a pretty much clean machine for .NET Core.
After trying to run the default template it started up and run without any problem. Intriguing. So this does lead me to believe it's an issue on the other computer though I can't figure out what it is. I have all dependencies. Hmm...I am really confused now what it could be. Especially because the first time it didn't run I uninstalled all my .NET Core stuff to start from the beginning (just like I had to do with this).
I have not yet gotten to try it on a different machine. I won't be able to try that until Tuesday. I will try it then and then get back with you to let you know of the results.
Thanks for that link. I updated my global.json file to have it use the preview2 CLI version. When I went to run it it went back to throwing the original exception that I described in the original post. So pretty much I am back to the original issue of still not being able to run the default Core Template will nothing changed to it.
Exception:
System.IO.FileLoadException was unhandled
Message: An exception of type 'System.IO.FileLoadException' occurred in mscorlib.dll and wasn't handled before a managed/native boundary
Additional information: Could not load file or assembly 'System.IO.FileSystem, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Hey, sorry for the late reply.
I have yet to find a solution for this. I just tried again on another brand new template and it still will not run. The error is now different though:
New Error:
FatalExecutionEngineError occurred
HResult=-2146233082
Message=Exception of type 'System.ExecutionEngineException' was thrown.
InnerException:
Additional Information: The runtime has encountered a fatal error. The address of the error was at 0x72091a09, on thread 0x231c. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.
This exception is thrown in the Configure method in the Startup class where ABP Framework is initialize (app.UseAbp())
The only difference in my machine since then is that I updated Visual Studio 2017 which I believe did have an update for .NET Core.
I was about to post something on GitHub in hope to garner more attention and discussion on this to see if we can get this solved.
The password that is seeded in the database by default is already hashed. The default password for admin is 123qwe. So try giving that as the password.