I have installed dotnet core on my Raspberry PI running Ubuntu Server 16.04 as per https://github.com/dotnet/core/blob/RaspberryPi/samples/ARMInstructions.md
I create and publish dotnet core project on Linux Mint 18 running dotnet core version 1.0.0-preview2-1-003177. (Also modifying runtimeconfig.json file to update the version to 1.2.0-beta-001206-00).
I then copy the published application into the Raspberry pi and run the dll.
For console application it works fine.
But when I repeat the steps for a web project and run it I get below error
Unhandled Exception: System.IO.FileLoadException: Could not load file
or assembly 'System.ComponentModel.Primitives, Version=4.2.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The located
assembly's manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040) at
Microsoft.Extensions.FileProviders.PhysicalFileProvider.CreateFileWatcher(String
root) at
Microsoft.AspNetCore.Hosting.Internal.HostingEnvironmentExtensions.Initialize(IHostingEnvironment
hostingEnvironment, String applicationName, String contentRootPath,
WebHostOptions options) at
Microsoft.AspNetCore.Hosting.WebHostBuilder.BuildHostingServices()
at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build() at
WebApplication.Program.Main(String[] args) in
/home/Development/aspCoreDemo3/Program.cs:line 14 Aborted
Check out the changes you need to make in the project.json.
https://github.com/dotnet/coreclr/issues/9168
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.
My XUnit 2.2 tests all pass when run from the command line with dotnet test. When running them from Visual Studio 2017's Test Explorer some of the tests fail with Assembly Binding errors.
My test project targets .Net 4.6.2 and references an ASP.Net Core 1.1 application also targeting .Net 4.6.2. The unit tests were working fine in VS 2015 prior to upgrading to the .NET Core 1.1 release tooling and Visual Studio 2017.
The workaround was to create an app.config file for the test project and add all of the needed binding redirects to it via trial and error. I'm not sure why I have to do this, though.
It appears that when using dotnet test the runtime uses the newer assembly versions without complaint. When running from Visual Studio, the redirects are necessary.
Why is there a difference in the assembly binding behavior between these two methods of running the tests?
Sample assembly binding error:
The operation failed.
Bind result: hr = 0x80131040. No description available.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2017\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\vstest.executionengine.x86.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: DisplayName = Microsoft.Extensions.Configuration.Abstractions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
(Fully-specified)
LOG: Appbase = file:///C:/xx/xx/xx.Tests/bin/Debug/net462
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = C:\Users\xxxxx\AppData\Local\Temp\a1ec4d3c-04ff-4fa0-9e56-129e799dd870
LOG: AppName = a1ec4d3c-04ff-4fa0-9e56-129e799dd870
Calling assembly : Serilog.Settings.Configuration, Version=2.2.0.0, Culture=neutral, PublicKeyToken=24c2f752a8e58a10.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2017\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\vstest.executionengine.x86.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Microsoft.Extensions.Configuration.Abstractions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/xx/xx/xx.Tests/bin/Debug/net462/Microsoft.Extensions.Configuration.Abstractions.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\xx\xx\xx.Tests\bin\Debug\net462\Microsoft.Extensions.Configuration.Abstractions.dll
LOG: Entering download cache setup phase.
LOG: Assembly Name is: Microsoft.Extensions.Configuration.Abstractions, Version=1.1.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
ERR: The assembly reference did not match the assembly definition found.
ERR: Setup failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
And the redirect needed to solve it:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Extensions.Configuration.Abstractions" culture="neutral" publicKeyToken="adb9793829ddae60" />
<bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="1.1.1.0" />"
</dependentAssembly>
It turns out this issue is being tracked at https://github.com/Microsoft/vstest/issues/428
The workaround is to add the following two items to the test project's csproj file:
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
This eliminates the need for manually adding binding redirects.
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've setup a VB.NET desktop application in a Windows 8.1 pro 64-bit PC. After doing server configurations I'm trying to login to the application. It's when I'm getting the following error message:
Could not load file or assembly 'log4net, Version = 1.2.10.0 Culture = neutral, PublicKeyToken = 692fbea5521e1304'or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I've installed SAP Crystal Reports 13.0.3 64-bit yet it's still not working.
What is the reason behind this problem?
Check you Application files in Project Settings,find status of log4net dll whether included or not .Make it included in your project as below :
Problem solved.
The problem raised due to the mismatch in version of the log4net.dll file. My solution had log4net version = 1.2.9.0, while it needed the version = 1.2.10.0, hence the exception occured. I replaced the existing log4net.dll file with the one which has appropriate version and the problem was solved.
I have an application that I am upgrading from the .NET 3.5 to the .NET 4.0 framework. It uses a COM library which is referenced. It works no problem in 3.5 but after converting to 4.0 I have issues getting the COM to work. The COM is from a 3rd party so we didn't develop it ourselves.
I get the following COM error (generic COM error, not specific to the COM object itself): hr = 0x8007000b
CLR gives me: 'The invocation of the constructor on type 'Skype_Business_Launcher.Main' that matches the specified binding constraints threw an exception.' Line number '3' and line position '5'.
And the C# logs:
=== Pre-bind state information ===
LOG: User = \phillip
LOG: DisplayName = Interop.SKYPE4COMLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
(Fully-specified)
LOG: Appbase = file:///bin/Debug/
LOG: Initial PrivatePath = NULL
Calling assembly : Skype Business Launcher, Version=1.0.5.0, Culture=neutral, PublicKeyToken=null.
LOG: This bind starts in default load context.
LOG: Using application configuration file:
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///bin/Debug/Interop.SKYPE4COMLib.DLL.
ERR: Failed to complete setup of assembly (hr = 0x8007000b). Probing terminated.
I removed the pathname for security reasons but I have checked all the path information and it's all correct. Also the COM library file exists where it's pointing to. It's also copied to the OBJ folder within the project as well.
Originally I was getting an error about the COM library not supporting embedded types so I made "Embed Interop Types" false (it was true below) and the error went away but I'm not sure if thats connected to this error or not so I thought I'd mention it just in case.
Again, it works just fine with 3.5.
Thanks,
A shot in the dark: it looks like you are using the x64 version of the framework. Was that already the case with 3.5 ? And is the COM server a DLL or an EXE ?
If the COM server is a DLL, there needs to be a "bitness" match between the DLL and your program.
when you convert your project to 4.0 the IDE can perform a issue to convert COM library into 4.0.
when you convert your project to 4.0 remove com library then Re include it in your project then i thing it should be works.