I have a project that I'm publishing as ARM64 variant (along with x64 and x86) but users are getting an error when loading the app.
An attempt was made to load a program with an incorrect format. (0x8007000B)
System.BadImageFormatException
at MS.Win32.PresentationCore.UnsafeNativeMethods.MilCoreApi.RenderOptions_ForceSoftwareRenderingModeForProcess(Boolean fForce)
at System.Windows.Media.RenderOptions.set_ProcessRenderMode(RenderMode value)
at Myapp.App.App_Startup(Object sender, StartupEventArgs e) in App.xaml.cs:line 156
at System.Windows.Application.OnStartup(StartupEventArgs e)
at System.Windows.Application.<.ctor>b__1_0(Object unused)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
The line that triggers the issue has a call to the Util.dll to load and parse settings, which contains a bunch of Type.GetType() and Activator.CreateInstance() calls, but the exception is not triggered there.
My publishing settings are this:
When checking each published DLLs, I noticed that not all are ARM64:
MyApp.exe (and other DLLs): Arm64
MyApp.dll: x86 (this one is automatically generated)
SharpDX.DXGI.dll: x86 (the only nuget package installed)
Accessibility.dll: x86 (from .NET)
mscorlib.dll: x86
netstandard.dll: x86
As far as I understand, an ARM64 device should load x86 DLLs without issues.
Is that right?
How can I detect what's triggering this issue?
Related
The same executable that uses some proprietary DLLs, after being compiled with Mono, works natively on Windows, but doesn't work using Mono on Windows or Linux.
hello_onbase.cs:
using Hyland.Unity;
using Hyland.Types;
using System;
public class HelloOnBase
{
public static void Main(string[] args)
{
var auth = Application.CreateOnBaseAuthenticationProperties("app_server_url", "user", "password", "data_source");
var app = Application.Connect(auth);
Console.WriteLine ("OnBase connection successful!");
}
}
Proprietary DLLs Hyland.Unity.dll and Hyland.Types.dll are in the same directory as the file hello_onbase.cs. Unfortunately I can't share those files since they're the IP of our vendor, I'm very sorry...
I opened Mono x64 Command Prompt in Windows and compiled the file successfully with Mono:
C:\Users\apanasenco\git\docaccess\services\doc\onbase>csc -r:Hyland.Types.dll -r:Hyland.Unity.dll hello_onbase.cs
Microsoft (R) Visual C# Compiler version 3.6.0-4.20224.5 (ec77c100)
Copyright (C) Microsoft Corporation. All rights reserved.
The executable Mono compiled executes just fine natively in Windows:
C:\Users\apanasenco\git\docaccess\services\doc\onbase>hello_onbase.exe
OnBase connection successful!
However, running the executable with mono causes the following error:
C:\Users\apanasenco\git\docaccess\services\doc\onbase>mono hello_onbase.exe
Unhandled Exception:
System.TypeLoadException: Could not set up parent class, due to: Could not set up parent class, due to: Could not load type of field 'Hyland.Types.EncryptedServiceObject:_scp' (2) due to: Could not load file or assembly 'Hyland.Security.Legacy, Version=0.2.2.0, Culture=neutral, PublicKeyToken=e169a6a902bdd7a6' or one of its dependencies. assembly:C:\Users\apanasenco\git\docaccess\services\doc\onbase\Hyland.Types.dll type:EncryptedServiceObject member:(null) assembly:C:\Users\apanasenco\git\docaccess\services\doc\onbase\Hyland.Types.dll type:ParameterizedObject member:(null)
at Hyland.Unity.OnBaseAuthenticationProperties.ConnectNormalMode (Hyland.Unity.Services.IConnectServiceAccess connectServiceAccess) [0x00000] in <80532c8c2f134d0daba2ee8243cb5721>:0
at Hyland.Unity.OnBaseAuthenticationProperties.ConnectAndGetIntegrationApplicationOptions (Hyland.Unity.Services.IConnectServiceAccess connectServiceAccess) [0x00020] in <80532c8c2f134d0daba2ee8243cb5721>:0
at Hyland.Unity.Application.Connect (Hyland.Unity.AuthenticationProperties connectProperties) [0x00020] in <80532c8c2f134d0daba2ee8243cb5721>:0
at HelloOnBase.Main (System.String[] args) [0x0001b] in <73b1617068fa44e792f55cccc5974b17>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: Could not set up parent class, due to: Could not set up parent class, due to: Could not load type of field 'Hyland.Types.EncryptedServiceObject:_scp' (2) due to: Could not load file or assembly 'Hyland.Security.Legacy, Version=0.2.2.0, Culture=neutral, PublicKeyToken=e169a6a902bdd7a6' or one of its dependencies. assembly:C:\Users\apanasenco\git\docaccess\services\doc\onbase\Hyland.Types.dll type:EncryptedServiceObject member:(null) assembly:C:\Users\apanasenco\git\docaccess\services\doc\onbase\Hyland.Types.dll type:ParameterizedObject member:(null)
at Hyland.Unity.OnBaseAuthenticationProperties.ConnectNormalMode (Hyland.Unity.Services.IConnectServiceAccess connectServiceAccess) [0x00000] in <80532c8c2f134d0daba2ee8243cb5721>:0
at Hyland.Unity.OnBaseAuthenticationProperties.ConnectAndGetIntegrationApplicationOptions (Hyland.Unity.Services.IConnectServiceAccess connectServiceAccess) [0x00020] in <80532c8c2f134d0daba2ee8243cb5721>:0
at Hyland.Unity.Application.Connect (Hyland.Unity.AuthenticationProperties connectProperties) [0x00020] in <80532c8c2f134d0daba2ee8243cb5721>:0
at HelloOnBase.Main (System.String[] args) [0x0001b] in <73b1617068fa44e792f55cccc5974b17>:0
Mono version on Windows and Linux: 6.12.0
The older versions of these two files used to work on Mono before... I'm wondering if there's some Mono setting I can tweak to relax some assembly checks to match native .NET behavior?
Turns out the vendor does provide a file Hyland.Security.Legacy.dll that was alluded to in the error message. Including that file resolved the issue.
I am Dynamically creating a TextBox Control and I have Subscribed the TextBox LosingFocus Event and Its working fine on Local Machine but it is giving exception on Virtual Machine.
Getting the Following Error:
Unable to cast object of type 'Windows.UI.Xaml.Controls.TextBox' to
type 'Windows.UI.Xaml.IUIElement5
and The Stacktrace is:
at System.StubHelpers.StubHelpers.GetCOMIPFromRCW_WinRT(Object objSrc, IntPtr pCPCMD,
IntPtr& ppTarget) at
Windows.UI.Xaml.UIElement.add_LosingFocus(TypedEventHandler`2 value) at
System.Runtime.InteropServices.WindowsRuntime.WindowsRuntimeMarshal.NativeOrStaticEventRegistrationImpl.AddEventHandler[T](Func`2
addMethod, Action`1 removeMethod, T handler)
at
System.Runtime.InteropServices.WindowsRuntime.WindowsRuntimeMarshal.AddEventHandler[T](Func`2
addMethod, Action`1 removeMethod, T handler)
_XamlTypeInfo.XamlUserType.ActivateInstance()
Please Help me To Solve That Issue.
Thanks.
The LosingEvent has been introduced in the Windows API contract V4 (Windows build 15063+).
It is not available on the Windows build you are using in your VM (14393).
You can see the minimal OS/API contract version in the LosingEvent documentation
Additional features and requirements
Device family : Windows 10 Creators Update (introduced v10.0.15063.0)
API contract : Windows.Foundation.UniversalApiContract (introduced v4)
Since you're minimal target is Windows build 10240 (API contract V1), you need to perform a runtime check before registering to this event.
if (ApiInformation.IsApiContractPresent("Windows.Foundation.UniversalApiContract"), 4, 0)
{
// This device supports all APIs in UniversalApiContract version 4.0
}
This is the only way to validate if the API is available. You will have a detailed explanation about how to target multiple Windows version here
If the event is absolutly mandatory for what you want to do, you will need to upgrade the minimum target platform to 15063. By doing this, your application will no longer be able to run on older OS builds.
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.
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 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)