I have a project that is a .NET Core console application with just a model and some seed data. On a development desktop I can go to the application directory, run dotnet ef database update and everything is fine (I need to copy appsettings.json to bin\... directory, but OK).
The problem is when I need to run this in the client environment (with VPN access, and without Visual Studio there). First, I am not sure what exactly I need to copy to the remote machine. But let's say, I copied the whole project. First, when I run, I get the following error:
Unhandled Exception: System.IO.DirectoryNotFoundException: Could not find a part of the path '.nuget\packages.tools\Microsoft.EntityFrameworkCore.Tools'.
I have a directory .nuget\packages\Microsoft.EntityFrameworkCore.Tools but not under .tools. Out of despair I created .tools and copied this directory under it, but now I am getting the following exception:
Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.DotNet.Cli.Utils.ProjectToolsCommandResolver. ResolveCommandSpecFromToolLibrary(LibraryRange toolLibraryRange, String commandName, IEnumerable`1 args, ProjectContext projectContext)
at Microsoft.DotNet.Cli.Utils.ProjectToolsCommandResolver. ResolveCommandSpecFromAllToolLibraries(IEnumerable`1 toolsLibraries, String commandName, IEnumerable`1 args, ProjectContext projectContext)
at Microsoft.DotNet.Cli.Utils.ProjectToolsCommandResolver. ResolveFromProjectTools(String commandName, IEnumerable`1 args, String projectDirectory)
at Microsoft.DotNet.Cli.Utils.ProjectToolsCommandResolver.Resolve (CommandResolverArguments commandResolverArguments)
at Microsoft.DotNet.Cli.Utils.CompositeCommandResolver.Resolve (CommandResolverArguments commandResolverArguments)
at Microsoft.DotNet.Cli.Utils.CommandResolver.TryResolveCommandSpec(String commandName, IEnumerable`1 args, NuGetFramework framework, String configuration, String outputPath)
at Microsoft.DotNet.Cli.Utils.Command.Create(String commandName, IEnumerable`1 args, NuGetFramework framework, String configuration, String outputPath)
at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
at Microsoft.DotNet.Cli.Program.Main(String[] args)
Clearly, my trial and error attempts to find the right way hit a wall. Is there some substantive (not just syntax) documentation as to how to run EF Core commands outside Visual Studio? .NET is version 1.1 if that matters
It seems that you have not removed Entity framework completly hence the error that path: .nuget\packages.tools\Microsoft.EntityFrameworkCore.Tools is not found.
Somewhere in code there must be a reference to this file. If you are using project.json try checking your tools and depenedencies for Microsoft.EntityFrameworkCore.Tools.
If you are using the .csproj SDK version. Check your project file for any of these references and remove them.
Related
I pulled the latest code from https://github.com/aspnet/MusicStore/tree/dev
Without making any changes to the code. I built the application for
dnx version : 1.0.0-rc2-16308 coreclr x64
The application builds successfully , however when I try to run the application,
I get the below error.
System.NullReferenceException: Object reference not set to an instance of an object.
at Xunit.Runner.Dnx.Program.GetAvailableRunnerReporters()
at Xunit.Runner.Dnx.Program.Run(String[] args)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Microsoft.Dnx.Runtime.Common.EntryPointExecutor.Execute(Assembly assembly, String[] args, IServiceProvider serviceProvider)
at System.Threading.Tasks.Task`1.InnerInvoke()
at System.Threading.Tasks.Task.Execute()
Please Note , The same code base worked successfully couple of days back.
We're in the process of migrating from dnx to dotnet. The migration happens on the dev branch so all the code there might not compile or fail at runtime. This is most likely one of those cases.
From the callstack I assume you're trying to run the tests. In the dotnet world, we run tests a little different and we haven't got yet to MusicStore with the conversion.
Sorry for the inconvenience.
RC2 is not stable. Downgrade to RC1
https://github.com/aspnet/MusicStore/releases
I have created a simple ASP.NET 5 project based on the ASP.NET 5 beta 8 Visual Studio template.
I have published the project using this command
dnu publish <path to project.json> --out <path to publish folder> --configuration Release --runtime dnx-coreclr-win-x64.1.0.0-beta8 --wwwroot-out "wwwroot" --no-source
After I run the web.cmd on nano server I received this error:
.\web.cmd : System.DllNotFoundException: Unable to load DLL 'kernel32': The specified module could not be found. (Exception from HRESULT:
0x8007007E)
+ CategoryInfo : NotSpecified: (System.DllNotFo...LT: 0x8007007E):String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
at Microsoft.AspNet.Server.Kestrel.Networking.PlatformApis.WindowsApis.LoadLibrary(String dllToLoad)
at Micros
oft.AspNet.Server.Kestrel.Networking.Libuv.Load(String dllToLoad)
at Microsoft.AspNet.Server.Kestrel.ServerFactory.Start(IFeatureCollection serverFeatures, Func`2 application)
at Microsoft.AspNet.Hosting.Internal.HostingEngine.Start()
at Microsoft.AspNet.Hosting.Program.Main(String[] args)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Microsoft.Dnx.Runtime.Common.EntryPointExecutor.Execute(Assembly assembly, String[] args, IServiceProvider serviceProvider)
at Microsoft.Dnx.ApplicationHost.Program.ExecuteMain(DefaultHost host, String applicationName, String[] args)
at Microsoft.Dnx.ApplicationHost.Program.Main(String[] args)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Microsoft.Dnx.Runtime.Common.EntryPointExecutor.Execute(Assembly assembly, String[] args, IServiceProvider serviceProvider)
at Microsoft.Dnx.Host.Bootstrapper.RunAsync(List`1 args, IRuntimeEnvironment env, String appBase, FrameworkName targetFramework)
at Microsoft.Dnx.Host.RuntimeBootstrapper.ExecuteAsync(String[] args, BootstrapperContext bootstrapperContext)
at Microsoft.Dnx.Host.RuntimeBootstrapper.Execute(String[] args, BootstrapperContext bootstrapperContext)
The same command doesn't throw this error when running on Windows 10. The application works fine on Windows 10.
Nano Server does not have kernel32.dll and advapi32.dll so code that is not linked against default libs won't work. You need to either link your code against onecore.lib or install reverse forwarders.
Reverse forwarders redirect calls to kernel32.dll/advapi32.dll APIs to the counterparts available on Nano Server.
On some OneCore systems (e.g. Win10 IoT Core on Raspberry Pi 2), reverse forwarders are installed by default. This is not the case in case of the Nano Server, since the goal is to make it as small as possible. Hence the need to install reverse forwarders manually if you need them.
To relate this to Asp.Net 5 - both Http Platform Handler and Kestrel (or to be more specific libuv) are linked against default libs. Therefore, to run Asp.Net 5 on Nano, you need forwarders, unless you use WebListener (which should work fine without forwarders).
Hypothesis
You mention that this application is working fine on Windows. How are you running it on Windows? There's a good chance you are using dnx451 and not dnxcore50 (CoreCLR) as your target platform.
This is a problem because you are publishing for CoreCLR. (--runtime dnx-coreclr-win-x64.1.0.0-beta8), and there's a good chance when you are running locally, it is using the full .NET framework.
Does It Work with CoreCLR on Windows 10?
Here's what I'd do: Try to run the web app in the Developer Command Prompt for Visual Studio 2015 using dnx.
Switch to the CoreCLR version of .NET using dnvm:
dnvm use 1.0.0-beta-8 -r coreclr
Restore packages
dnu restore
Run
dnx web
If this fails, we know what is the issue. If this succeeds, there's a chance that Nano doesn't provide the native Windows APIs your code is trying to execute. If that is the case, you have to identify the code that is causing this and use something else.
How to target only CoreCLR in Visual Studio
You can remove the dnx451 target from your project.json so that Visual Studio is forced to use the dnxcore50 (CoreCLR) version. Ideally we want to be running the exact same version / environment we are publishing to.
I have deployed a custom TFS eventpoint to our production webserver. The server does not have the TFS sdk installed so I had to find and bin deploy all dependant dlls. For some reason, when the application tries to contact TFS using the TFS client, it is thrown a missing method exception only on the server. Does anyone know how to get this web service running on a system without installing the full SDK?
The bin deployed TFS dlls
Microsoft.TeamFoundation.Client.dll
Microsoft.TeamFoundation.Common.dll
Microsoft.TeamFoundation.Common.Library.dll
Microsoft.TeamFoundation.dll
Microsoft.TeamFoundation.WorkItemTracking.Client.Cache.dll
Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.dll
Microsoft.TeamFoundation.WorkItemTracking.Client.dll
Microsoft.TeamFoundation.WorkItemTracking.Proxy.dll
The Exception
System.MissingMethodException: Method not found: 'Boolean Microsoft.TeamFoundation.Client.TfsConnection.HandleUnauthorizedException(Microsoft.TeamFoundation.TeamFoundationServerUnauthorizedException)'.
at Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.HandleComException(Int32 hr)
at Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.DatastoreClass.ConnectEx(String connectionString, String defaultCachePath, String instanceId, String userSamName, String userFriendlyName, String userSid, WorkItemServer clientService)
at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore.InitializeInternal()
at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore.Microsoft.TeamFoundation.Client.ITfsTeamProjectCollectionObject.Initialize(TfsTeamProjectCollection teamProjectCollection)
at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore..ctor(TfsTeamProjectCollection teamProjectCollection)
Looks like partly connected to that problem:
http://blogs.msdn.com/b/bharry/archive/2013/02/13/10392771.aspx
unfortunately I'm still unable to locale where to find proper version of "Microsoft.TeamFoundation.WorkItemTracking.Proxy.dll" library.
I have recently encountered some rather baffling behavior while up-converting a VB.NET solution from VS2005 to VS2010. For reference, the solution targets .NET 2.0 and was running without error in the debugger prior to the conversion. In addition to the IDE change, corporate has seen it fit to refresh my device from Win XP (x86) to Win 7 (x64).
Now that I have converted the solution to VS2010, I receive a Socket exception as soon as the debugger loads (details below). This ONLY occurs in the debugger. Building the solution in its Release configuration produces a MSI that correctly installs and runs without error.
The details of the exception received are as follows:
System.Net.Sockets.SocketException was unhandled
Message=An invalid argument was supplied
Source=System
ErrorCode=10022
NativeErrorCode=10022
StackTrace:
at System.Net.Sockets.Socket..ctor(AddressFamily addressFamily, SocketType socketType, ProtocolType protocolType)
at System.Net.Sockets.TcpListener..ctor(IPAddress localaddr, Int32 port)
at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel.SetupChannel()
at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel..ctor(IDictionary properties, IServerChannelSinkProvider sinkProvider, IAuthorizeRemotingConnection authorizeCallback)
at System.Runtime.Remoting.Channels.Tcp.TcpChannel..ctor(IDictionary properties, IClientChannelSinkProvider clientSinkProvider, IServerChannelSinkProvider serverSinkProvider)
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.RegisterChannel(Boolean SecureChannel)
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(String[] commandLine)
at FSASYSTEM.My.MyApplication.Main(String[] Args) in 17d14f5c-a337-4978-8281-53493378c1071.vb:line 81
at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException:
The truly confusing part is that this exception is generated before a single line of my code is executed. The Main method is generated via VB.NET (managed code) and I am not able to breakpoint it, trap errors within it (due to kernel / application context switching, as I understand it), nor symbolically debug into it.
A possible fix for this would be to target another .NET framework version, however I am really interested in understanding WHY this is happening. I fail to understand why such an error would only manifest itself in the debugger and not in the released code. And, yes, I have tried restarting the machine to ensure that there weren't any left-over sockets still listening, causing binding failures.
Thank you in advance for your time and assistance.
After much work and a heaping helping of creative swearing, I was able to resolve my problem. Turns out that the issue had to do with running the code from a network location. Our company is moving to ClearCase, which stores all code in a pseudo-network drive. As it turns out, .NET 4 removed the ability to target assemblies on a 'remote' host by default. Since my code appeared to be on the M: drive, my guess is the runtime was rejecting the load of a particular assembly.
To fix this, I added the following tag to my app.config:
<runtime>
<loadFromRemoteSources enabled="true"/>
</runtime>
This appears to have fixed the issue. However, if anyone knows how that particular error message was generated as a result of resolving assemblies across a virtual network, I would love to hear it. Also, if the internet is to be believed, this security measure was introduced in .NET 4 yet it still caused problems despite the fact that I had explicitly targeted framework 2.0.
Hopefully, this can save someone down the road a good amount of time. And, for your literary pleasure, some supplemental reading:
http://through-the-interface.typepad.com/through_the_interface/2011/07/loading-blocked-and-network-hosted-assemblies-with-net-4.html
Could not load file or assembly HRESULT: 0x80131515 (When adding controller to MVC project that has assembly references on network drive)
If I start up Microsoft Visual Studio, create a standard "WCF Service Library", and compile it, it works perfectly.
However, if I go into Properties..Build and set the "Platform Target" to "x86", it won't compile. I need "x86" because I need to reference some .dll's that simply won't work if I choose "All Platforms".
-----start error-----
System.BadImageFormatException: Could not load file or assembly 'file:///D:\backtest\C#\WCF service\WcfServiceLibrary\bin\Debug\WcfServiceLibrary.dll' or one of its dependencies. An attempt was made to load a program with an incorrect format.
File name: 'file:///D:\backtest\C#\WCF service for\WcfServiceLibrary\bin\Debug\WcfServiceLibrary.dll'
at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.Assembly.Load(AssemblyName assemblyRef)
at Microsoft.Tools.SvcHost.ServiceHostHelper.LoadServiceAssembly(String svcAssemblyPath)
=== Pre-bind state information ===
LOG: User = dr-satellite\Shane
LOG: Where-ref bind. Location = D:\backtest\C#\WCF service for\WcfServiceLibrary\bin\Debug\WcfServiceLibrary.dll
LOG: Appbase = file:///D:/backtest/C#/WCF service for/WcfServiceLibrary/bin/Debug
LOG: Initial PrivatePath = NULL
Calling assembly : (Unknown).
===
LOG: This bind starts in LoadFrom load context.
WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with Assembly.Load().
LOG: Using application configuration file: D:\backtest\C#\WCF service for\WcfServiceLibrary\bin\Debug\WcfServiceLibrary.dll.config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Attempting download of new URL file:///D:/backtest/C#/WCF service for/WcfServiceLibrary/bin/Debug/WcfServiceLibrary.dll.
ERR: Failed to complete setup of assembly (hr = 0x8007000b). Probing terminated.
-----end error-----
Your problem is actually the WCF Test Client complaining that your WCF Service Library is 32bit. This is because by default, the WCF Test Client always runs in 64 bit mode.
Rather than going to the lengths of changing to a WCF Service Application so you can debug, I found the following steps on this blog which makes the WCF Test Client run in 32bit mode - and therefore you will not see the error you have posted.
Copy WcfSvcHost.exe and WcfTestClient.exe from C:\program files (x86)\Microsoft Visual Studio 10.0\Common7\IDE to a local directory. Keep a backup copy of this file, of course.
Start a Visual Studio 2010 Command Prompt (one of the links from the start menu -> Visaul Studio 2010)
"cd" to the directory where your copy of WcfSvcHost is located.
Execute the command "corflags /32BIT+ /FORCE WcfSvcHost.exe"
Execute the command "corflags /32BIT+ /FORCE WcfTestClient"
Copy the files back to where you found it.
Now your WcfSvcHost and WcfTestClient will be running in 32 bit mode, and you can debug away!
I found two good methods to solve this:
Installing the 64-bit version of Matlab means you can compile 64-bit .dll's which are compatible with the 64-bit WCF Service Library. This removes the need to compile in 32-bit mode so it doesn't throw exceptions when it calls the 32-bit assembly. This solution works well.
There are two types of projects you can generate in MSVS 2010: "WCF Service Library" and "WCF Service Application". Although you cannot build and run a "WCF Service Library" in 32-bit mode (it only supports 64-bit), you can build and run a "WCF Service Application" in 32-bit mode.