I am having an old library written in VB.net .net 3.5 using this library as dll or project reference on Xamarin.Android project works fine with linker to "none". Problem starts if I use a linker. When I set the linker as "SDK assemblies only", I am getting the following error message.
Error Java.Interop.Tools.Diagnostics.XamarinAndroidException: error
XA2006: Could not resolve reference to 'System.Void
Microsoft.VisualBasic.MyGroupCollectionAttribute::.ctor(System.String,System.String,System.String,System.String)'
(defined in assembly 'VBLibraryProject, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=null') with scope
'Microsoft.VisualBasic, Version=8.0.0.0, Culture=neutral,
PublicKeyToken='. When the scope is different from the
defining assembly, it usually means that the type is forwarded. --->
Mono.Cecil.ResolutionException: Failed to resolve System.Void
Microsoft.VisualBasic.MyGroupCollectionAttribute::.ctor(System.String,System.String,System.String,System.String)
at Mono.Linker.Steps.MarkStep.HandleUnresolvedMethod(MethodReference
reference) at Mono.Linker.Steps.MarkStep.MarkMethod(MethodReference
reference) at
Mono.Linker.Steps.MarkStep.MarkCustomAttribute(CustomAttribute ca)
at
Mono.Linker.Steps.MarkStep.MarkCustomAttributes(ICustomAttributeProvider
provider) at
Mono.Linker.Steps.MarkStep.MarkEntireType(TypeDefinition type) at
Mono.Linker.Steps.MarkStep.MarkEntireType(TypeDefinition type) at
Mono.Linker.Steps.MarkStep.MarkEntireAssembly(AssemblyDefinition
assembly) at
Mono.Linker.Steps.MarkStep.InitializeAssembly(AssemblyDefinition
assembly) at Mono.Linker.Steps.MarkStep.Initialize() at
Mono.Linker.Steps.MarkStep.Process(LinkContext context) at
MonoDroid.Tuner.MonoDroidMarkStep.Process(LinkContext context) at
Mono.Linker.Pipeline.ProcessStep(LinkContext context, IStep step)
at Mono.Linker.Pipeline.Process(LinkContext context) at
MonoDroid.Tuner.Linker.Process(LinkerOptions options, ILogger logger,
LinkContext& context) at
Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver
res)
I have added AndroidLinkSkip for those libraries like below
<AndroidLinkSkip>Microsoft.VisualBasic;Microsoft.VisualBasic.Core;VBLibraryProject</AndroidLinkSkip>
Despite that it is still failing with the same error?
Project is using the latest XF 4.8 version with Android.Support libraries and target version android 9.0
minimum version 8.0
EDIT:
I have tried with a linker.xml from type of LinkDescription as below but it didnt help.
<linker>
<assembly fullname="Microsoft.VisualBasic">
<namespace fullname="Microsoft.VisualBasic" />
</assembly>
<assembly fullname="Microsoft.VisualBasic.Core">
<namespace fullname="Microsoft.VisualBasic" />
</assembly>
<assembly fullname="VBLibraryProject">
If you need some definitions from the SDK or product assemblies then using an XML file might be your best solution (versus adding code that will ensure the linker won't eliminate what you need).
You could refer to Custom Linker Configuration
Related
Here's a weird one that has me stumped. I have a .NET Core application I deploy to a Service Fabric Cluster as a Reliable Service. This worked great, until I added the last two lines to the CSPROJ file:
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
<PublishSingleFile>true</PublishSingleFile> <-- New
<PublishTrimmed>true</PublishTrimmed> <-- New
This bundles up my program into a single EXE. However, when I deploy it, SF tells me that the Application has stopped with an exit code of 3762504530, which basically means some unhandled exception. However, I can go into the node and go to D:\SvcFab_App\ and see the EXE and run it directly from the command line, and it starts up fine.
I then dug a bit through the Windows Event Log, and I see this error come up:
Application: DeviceSync.exe
CoreCLR Version: 4.700.20.26901
.NET Core Version: 3.1.6
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileNotFoundException: Could not load file or assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.
File name: 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
at System.Reflection.RuntimeAssembly.GetType(QCallAssembly assembly, String name, Boolean throwOnError, Boolean ignoreCase, ObjectHandleOnStack type, ObjectHandleOnStack keepAlive, ObjectHandleOnStack assemblyLoadContext)
at System.Reflection.RuntimeAssembly.GetType(String name, Boolean throwOnError, Boolean ignoreCase)
at System.Reflection.Assembly.GetType(String name, Boolean throwOnError)
at System.StartupHookProvider.CallStartupHook(StartupHookNameOrPath startupHook)
at System.StartupHookProvider.ProcessStartupHooks()
I reverted my changes to the CSPROJ file and published again, it now it works great again.
My Question: When I use PublishSingleFile, why can I run my program just fine from the command line, but Service Fabric throws an exception when running the same app on the same VM?
Remove the <PublishTrimmed>true</PublishTrimmed>. That is still experimental and might trim some valid dependency from standalone package. The reason it works when you run by logging into the node is that time it's outside the SF runtime and probably able to figure out from global.
Keep only the <PublishSingleFile>true</PublishSingleFile>.
If it still does not work, try to add nuget package reference of netstandard in your main host .csproj <PackageReference Include="NETStandard.Library" Version="2.0.3" />
Could not load file or assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' or one of its dependencies. The system cannot find the file specified.
I tried clean and rebuild the solution and deleted bin and obj still I got same error. I'm using sitecore 8.1.
Stacktrace:
[FileNotFoundException: Could not load file or assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' or one of its dependencies. The system cannot find the file specified.]
Sitecore.DependencyInjection.<>c__14`1.<GetRequiredResetableService>b__14_0() +0
Sitecore.DependencyInjection.LazyResetable`1.get_Value() +148
Sitecore.Configuration.Factory.GetConfigNode(String xpath) +72
Sitecore.Resources.Media.UploadWatcher.InitializeIgnoreList() +156
Sitecore.Resources.Media.UploadWatcher..cctor() +85
[TypeInitializationException: The type initializer for 'Sitecore.Resources.Media.UploadWatcher' threw an exception.]
Sitecore.Resources.Media.UploadWatcher..ctor() +0
This could be caused by one of the following:
You added Sitecore.Kernel through Nuget package to your project, and you are referencing a later version (8.2) and its being deployed to the bin folder when you build and publish, You need to check you have the correct Sitecore.Kernel version in your nuget packages
You are overwriting the web.config from your project (which does not include Sitecore default configurations) and pushing it to the root folder, You need to make sure only the correct Sitecore web.config is in your root folder.
You are referencing a later version of "Microsoft.Extensions.DependencyInjection.Abstractions" package in your NuGet packages, Make sure you are referencing version number "1.0.0", as this is the version that sitecore is using.
Hope this helps
My ASP.Net MVC Application works fine when run locally on IIS, but gives the following error when deployed to Azure:
Could not load file or assembly 'Microsoft.Owin, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
This is the piece of the stack trace that led me to believe that SignalR is a potential culprit:
[FileLoadException: Could not load file or assembly 'Microsoft.Owin, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]
Owin.OwinExtensions.MapSignalR(IAppBuilder builder, String path, HubConfiguration configuration) +0
Owin.OwinExtensions.MapSignalR(IAppBuilder builder, HubConfiguration configuration) +12
QuikWorx.O365Web.Startup.Configuration(IAppBuilder app) +169
According to NuGet, I have version 3.0.1 of Microsoft.Owin installed on the application, but apparently something (SignalR) requires version 2.1.0. I would have thought that the following bindingRedirect would force SignalR to use the installed version 3.0.1 (verified present, version 3.0.1 in /bin on Azure):
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" />
</dependentAssembly>
...but alas, this is not the case.
I've also tried the following without success:
Forced reinstall of Microsoft.Owin 3.0.1 with NuGet.
Forced reinstall of the SignalR component (Microsoft.AspNet.SignalR.Core) that requires Microsoft.Owin 2.1.0 with NuGet
Changing the oldVersion of the bindingRedirect for Microsoft.Owin to "0.0.0.0-2.1.0.0" (this makes no sense)
Removing the bindingRedirect for Microsoft.Owin
Deleting all files and folders in the site directory using rd /Q /S in Kudu
Is there anything else that I could attempt?
Would love to get to the root cause of the issue, as in why it works locally, but not in Azure, but based on this answer you should probably try to install Microsoft OWIN itself - via NuGet, directly to the project that's failing.
All,
My Project - (VS 2010 / .NET 4 / ASP.NET application, my web application lives inside Sitefinity as a Sitefinity application)
I have two versions of the MongoDB assemblies. I would like to run these side-by-side in my web application. Here's my setup:
\bin\AuxFiles\[1.8.3.9] assemblies
\bin\[1.4.x.x] assemblies
Web config:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="MongoDB.Bson" publicKeyToken="f686731cfb9cc103" culture="neutral" />
<codeBase version="1.4.2.4500" href="bin\MongoDB.Bson.dll" />
<codeBase version="1.8.3.9" href="bin\AuxFiles\MongoDB.Bson.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="MongoDB.Driver" publicKeyToken="f686731cfb9cc103" culture="neutral" />
<codeBase version="1.4.2.4500" href="bin\MongoDB.Driver.dll" />
<codeBase version="1.8.3.9" href="bin\AuxFiles\MongoDB.Driver.dll" />
</dependentAssembly>
</assemblyBinding>
When the application starts, it loads the 1.4.x.x assemblies by default. When I go to the page that uses the 1.8.3.9 version of assemblies I get an error:
Server Error in '/' Application.
Could not load file or assembly 'MongoDB.Driver, Version=1.8.3.9, Culture=neutral, PublicKeyToken=f686731cfb9cc103' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.IO.FileLoadException: Could not load file or assembly 'MongoDB.Driver, Version=1.8.3.9, Culture=neutral, PublicKeyToken=f686731cfb9cc103' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Source Error: ....
Source File: ...... Line: 18
Assembly Load Trace: The following information can be helpful to determine why the assembly 'MongoDB.Driver, Version=1.8.3.9, Culture=neutral, PublicKeyToken=f686731cfb9cc103' could not be loaded.
=== Pre-bind state information ===
LOG: DisplayName = MongoDB.Driver, Version=1.8.3.9, Culture=neutral, PublicKeyToken=f686731cfb9cc103
(Fully-specified)
LOG: Appbase = file:///C:/DEV/Visual Studio 2010/WebStoreApp/WebStoreApp/
LOG: Initial PrivatePath = C:\DEV\Visual Studio 2010\WebStoreApp\WebStoreApp\bin
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\DEV\Visual Studio 2010\WebStoreApp\WebStoreApp\web.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: MongoDB.Driver, Version=1.8.3.9, Culture=neutral, PublicKeyToken=f686731cfb9cc103
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/d73c4379/cb2aee95/MongoDB.Driver.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/d73c4379/cb2aee95/MongoDB.Driver/MongoDB.Driver.DLL.
LOG: Attempting download of new URL file:///C:/DEV/Visual Studio 2010/WebStoreApp/WebStoreApp/bin/MongoDB.Driver.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
Stack Trace:
[FileLoadException: Could not load file or assembly 'MongoDB.Driver, Version=1.8.3.9, Culture=neutral, PublicKeyToken=f686731cfb9cc103' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]
System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) +51
System.Web.UI.Control.OnLoad(EventArgs e) +92
System.Web.UI.Control.LoadRecursive() +54
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint
UPDATE 1:
I have tried to rename my new 1.8.x.x assemblies from MongoDB.Driver.dll to MongoDB.Driver.exe so the files can co-exist under same directory (the older assemblies have extension .dll, the new version of the assemblies have extension .exe) but the loader seems not to pickup the assemblies. My understanding is that the loader always tries .dlls first, then tries .exes second. I am a bit puzzled.
UPDATE 2:
I have created a console application w/ exactly identical setup of my dual references and the app config entries that you see here,- and the application works, it executes 2 versions of the Mongo dll. The question is now, why doesn't this setup work in my Web application? Are my directories wrong? If you look below at the probing for the assemblies, it never checks my AuxFiles directory, it appears it simply ignores my configuration for side-by-side execution in web.config.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/d73c4379/cb2aee95/MongoDB.Driver.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/d73c4379/cb2aee95/MongoDB.Driver/MongoDB.Driver.DLL.
LOG: Attempting download of new URL file:///C:/DEV/Visual Studio 2010/WebStoreApp/WebStoreApp/bin/MongoDB.Driver.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
UPDATE 3:
Found the issue but I am not sure of the details of this solution. The web.config file has 'configuration' root element w/ the following namespace declaration - 'xmlns=http://schemas.microsoft.com/.NetConfiguration/v2.0'.
The root element is fine but the specified namespace is causing my 'runtime' element to be ignored. Removing the namespace from the configuration element fixes everything.
Found the issue:
The 'configuration' root element in the web.config file contains the following namespace declaration - 'xmlns=http://schemas.microsoft.com/.NetConfiguration/v2.0'. Removing the namespace from the configuration element fixes everything.
Why the ns? It is more of a bug then anything in VS and has really no real purpose but mess up your intellisense and in my case the runtime configuration. Read more about it:
http://weblogs.asp.net/scottgu/archive/2005/12/02/432077.aspx
I am having a problem where an older GAC'd assembly is being used instead of a newer version assembly in the bin.
Server:
Assembly version: ASP.NET MVC 3 RC 1 (3.0.11029.0)
Full name: System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Code base: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Web.Mvc/v4.0_3.0.0.0__31bf3856ad364e35/System.Web.Mvc.dll
Deployment: GAC-deployed
Development machine:
Assembly version: Unknown version (3.0.20105.0)
Full name: System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Code base: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Web.Mvc/v4.0_3.0.0.0__31bf3856ad364e35/System.Web.Mvc.dll
Deployment: GAC-deployed
The newer RTM version (3.0.20105.0) is in the bin directory of the application. However, the application is using the one in the GAC instead of the local bin. My experience from windows applications is the local bin deployed DLL always takes precedence because the GAC is checked only if the DLL isn't found in the same directory as the application. This convention appears to not be the case for a web application.
How can I force it to use my newer version bin deployed DLL (3.0.20105.0)?
Edit:
I actually did try a binding redirect like so:
<assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="3.0.11029.0" newVersion="3.0.20105.0" />
I tried several variations on the oldversion such as 0.0.0.0-4.0.0.0. In all my attempts usually it either loaded the older version, or gave me this exception message:
Could not load file or assembly 'System.Web.Mvc' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference.
The binding log didn't have any errors except this was last two lines:
WRN: Comparing the assembly name resulted in the mismatch: Build Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
Answered is SO Dll in both the bin and the gac, which one gets used? Note, you must run strong name hijack or it will use the GAC version.
I would retag this, it is not MVC specific.
You can modify your .config files to use assembly binding redirection for this and force the runtime to load different versions as you require.