We Keep Coding

Could not load file or assembly Microsoft.Data.SqlClient, Version=5.0.0.0

Facing following issue after deploying app to azure app service:
Unhandled exception. System.IO.FileNotFoundException: Could not load
file or assembly 'Microsoft.Data.SqlClient, Version=5.0.0.0,
Culture=neutral, PublicKeyToken=***********'. The system cannot find
the file specified.
Locally everything works as fine.
Microsoft.Data.SqlClient presented in site/wwwroot
Runtime Stack: Dotnetcore - 6.0
Main app and all class libs on .net6
Server Operating System: Linux
Microsoft.Data.SqlClient presented as reference from Microsoft.EntityFrameworkCore.SqlServer (v.7.0.2)
Tried different kinds of Nuget Packages versions - still have same issue
Tried to install Microsoft.Data.SqlClient (latest version & 5.0.0.0) directly into projects - still the same

The solution for us was to:
Locate the actual DLL file (Microsoft.Data.SqlClient.dll) on the developer's desktop filesystem (easy to find; once you're referenced it using NuGet it gets copied to multiple places)
Add it to the web project (we placed it right in the root)
Mark it (via Properties tool window) as Copy Always
Step 3 results in our .csproj file looks like this:
<ItemGroup>
<None Update="Microsoft.Data.SqlClient.dll">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</None>
</ItemGroup>

"Not a valid framework" (MM0140) error when trying to build Xamarin native bindings library for framework targeting net6-macos

I have working native bindings library targeting old xamarin.mac (xamarin.full net framework 4.8) built with mono.
It is binding ScritptingBridge.framework, not a static library. It is builds and works as expected.
Note: full project for experiments may be found here: https://github.com/snechaev/net6nativeBindingsError
Now I'm trying to migrate to newest net6-macos. To do so I do the following
converted main app project to the sdk style and target net6-macos. If I will temporary remove native bindings dependencies, this will build fine.
converted native bindings project to the sdk style and perform the following fixes suggested by the comiler errors
changed version to avoid wildcards
replaced [assembly: LinkerSafe] with AssemblyMetadata("IsTrimmable", "True")]
added explicit NativeReferecnce to the framework I'm trying to bind.
Final csproj content for native bindings project:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net6-macos</TargetFramework>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
<RootNamespace>NativeBindingsLib</RootNamespace>
<AssemblyName>NativeBindingsLib</AssemblyName>
<IsPackable>false</IsPackable>
<AllowUnsafeBlocks>false</AllowUnsafeBlocks>
<IsBindingProject>true</IsBindingProject>
<NoBindingEmbedding>true</NoBindingEmbedding>
</PropertyGroup>
<ItemGroup>
<ObjcBindingApiDefinition Include="ApiDefinition.cs" />
<ObjcBindingCoreSource Include="StructsAndEnums.cs" />
<NativeReference Include="/System/Library/Frameworks/ScriptingBridge.framework" Kind="Framework" />
</ItemGroup>
</Project>
When I trying to build the only bindings library with dotnet build it builds without errors.
But when I try to build the application project (app.csproj in the sample repository), which is referencing (via the the ProjectReference) the binding library, I got the following errors:
ILLINK: Error MM0140: File '/Users/user/work/MonoBindingTest/net6/app/obj/Debug/net6.0-macos/osx-x64/linker-cache/NativeBindingsLib.resources/ScriptingBridge.framework/ScriptingBridge' is not a valid framework. (MM0140) (app)
ILLINK: Error MM2342: The linker step 'Extract Binding Libraries' failed during processing: File '/Users/user/work/MonoBindingTest/net6/app/obj/Debug/net6.0-macos/osx-x64/linker-cache/NativeBindingsLib.resources/ScriptingBridge.framework/ScriptingBridge' is not a valid framework. (MM2342) (app)
I double checked the framework path and it is ok. I also tried to add ScriptingBridge.framework into the XCode project and verified that the path is the same.
I also will be happy to get any samples of working net6-macos targeted native bindings projects for frameworks (not a static libraries) for further experiments on my own.
Full project mey be found here (both mono-targeted and net6-targeted): https://github.com/snechaev/net6nativeBindingsError

Finally, I posted the issue in the xamarin repo on github https://github.com/xamarin/xamarin-macios/issues/15485.
And ducting the discussion and experiments we concluded the following:
MM0140 is because the ScriptingBridge is the system framework and this is the special case.
you should not use NativeReference for the system frameworks as it will try to copy the framework into your bundle and this is not what you want for the system framework
initially I was missleaded by the following error
MSBuild : error MM7068: Can't create a binding resource package unless there are native references in the binding project.
so I decided to add NativeReference pointing ScriptingBridge.
So, the final solution is that the "at least one NativeReference" compiler check is excessive and it will be removed it net7 (https://github.com/xamarin/xamarin-macios/issues/15489).
The temporary workaround for net6 is to add the fake NativeReference to the empty static library to make compiler happy.
<NativeReference Include="/Users/sergey/work/MonoBindingTest/net6/test.dylib" Kind="Static"/>
I believe that it is possible to specify NativeReference to point to the source code (C++) instead of binary file and provide an additional command to build such a C++ code into the binary during the build process of native bindings library.
Additional note: the MM0140 error was called MT0140 in the previous versions of xamarin. So, this note may help other to find this post.

.NET 5 TargetFramework issue with referenced project when publishing WPF App over ClickOnce

I'm trying to publish a WPF app with Target Framework net5.0-windows using ClickOnce (Built in VS2019), which has a Project Reference to another .NET5 Class Library.
But I always run into the following exception:
Publish has encountered an error.
Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details.
The diagnostic log shows me the exact exception:
System.AggregateException: One or more errors occurred. ---> Microsoft.WebTools.Shared.Exceptions.WebToolsException: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details.
--- End of inner exception stack trace ---
---> (Inner Exception #0) Microsoft.WebTools.Shared.Exceptions.WebToolsException: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details. <---
Microsoft.WebTools.Shared.Exceptions.WebToolsException: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details.
The issue can be easily reproduced:
Create new Solution with a WPF project (.NET5)
Create new Class Library (.NET5) in this solution
Reference the ClassLibrary from the WPF App
Try to publish the WPF App with ClickOnce (right-click the WPF App project -> Publish -> ClickOnce, ...)
Here's a Demo project, which I've created followed the steps above:
PublishDemo.Core (Class library)
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
</Project>
PublishDemo.Wpf (WPF App)
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>net5.0-windows</TargetFramework>
<UseWPF>true</UseWPF>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\PublishDemo.Core\PublishDemo.Core.csproj" />
</ItemGroup>
</Project>
The Build output displays the following error:
Metadata file 'C:\work\source\unmanaged\PublishDemo\PublishDemo\PublishDemo.Core\bin\Release\net5.0-windows\PublishDemo.Core.dll' could not be found
When using the Release-build configuration it tries to referece to the path \bin\Release\net5.0-windows which I think does not make any sense because the Class library targets the framework type net5.0. Also after checking the folders the Class library indeed puts the built files into a folder called net5.0.
Problem is I don't know where I can change that or if there is a workaround for that issue.
I have already updated to the newest VisualStudio version (16.9.0), since I thought maybe it's because ClickOnce way newly implemented in Vs, but this did not solve the issue.
Publishing to a Folder works. Azure I don't have, so I cannot try that.
Can anybody help me with this issue?
Also if you need more information, I'm happy to provide it.

I have found this reported issue and the error looks like yours:
https://developercommunity.visualstudio.com/t/clickonce-publish-for-net-core-31-and-net-50-may-f/1275937
Copied with little changes from the thread above:
It seems the publish command seeks the files in the same target runtime as the published project, even though it could be different (and builds succesfully outside the publish command).
The issue occurs even when the app targets net5.0-windows and the class library is net5.0.
The workaround is to select a specific Target Runtime (i.e. win-x64) on the Configuration page of the Publish Wizard instead of using the default Portable.

SignalR HubConnection.StartAsync exception: GetStreamItemType in Microsoft.AspNetCore.SignalR.Client.Core, v1.1.0.0 does not have implementation

Using .Net Core Signal R, Azure SignalR. Code used to work. Stopped working.
Fails at await MyHubConnection.StartAsync();
Throws exception System.TypeLoadException: 'Method 'GetStreamItemType' in type 'ConnectionState' from assembly 'Microsoft.AspNetCore.SignalR.Client.Core, Version=1.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' does not have an implementation.'
Microsoft.AspNetCore.SignalR.Client v 1.1.0
Microsoft.Azure.SignalR 1.0.7
How to to fix this?
Thanks!
Adam Leffert
www.leffert.com

In case anyone else runs into this problem, I'm posting the answer here.
I was able to work around this problem by updating all SignalR and related NUGet packages to their version 3.x pre-release versions.

I recently migrated a .net core 2.2.x app to framework 3.1. I experienced the same issue. the problem is version mismatch between Microsoft.AspNetCore.SignalR and Microsoft.AspNetCore.SignalR.Client.
To work properly the server must have SignalR 1.1.0
https://www.nuget.org/packages/Microsoft.AspNetCore.SignalR/1.1.0
In terms of the client, it must be the most recent one, even when the previous one still works:
https://www.nuget.org/packages/Microsoft.AspNetCore.SignalR.Client/3.1.1
Other combinations of the client and server don't work or they have some unexpected behaviors.

Solution for NET 5 console app is just to use the meta-reference for ASP.NET 5.
Open your project and add this meta-reference (don't forget to remove old ASP.NET refs):
<ItemGroup>
<FrameworkReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>

Can't Find Tuple Method

I have a Net 4.6.2 console app which uses a Net Standard 2.0 library I've written. One of the methods in the library returns a tuple:
public (ScanStatEntry scanEntry, DateTime nextScan) Run()
{
The routine is called from within the console app as follows:
(ScanStatEntry scanEntry, DateTime nextScan) = _scanner.Run();
This all worked fine for quite some time...until suddenly I started getting the following exception when the console app ran:
System.MissingMethodException: Method not found:
'System.ValueTuple`2<Olbert.CommunityScanner.Data.Entities.ScanStatEntry,System.DateTime>
Olbert.CommunityScanner.Scanner.Run()'. at
Olbert.CommunityScanner.ScannerService.RunAndWait() at
Olbert.CommunityScanner.ScannerService.Start() in
C:\Programming\CommunityScanner\CommunityScannerTopShelf\ScannerService.cs:line
70 at
Olbert.CommunityScanner.Program.<>c.b__0_2(ScannerService tc) in
C:\Programming\CommunityScanner\CommunityScannerTopShelf\Program.cs:line
20 at
Topshelf.ServiceConfiguratorExtensions.<>c__DisplayClass2_0`1.<WhenStarted>b__0(T
service, HostControl control) at
Topshelf.Builders.DelegateServiceBuilder`1.DelegateServiceHandle.Start(HostControl
hostControl) at Topshelf.Hosts.ConsoleRunHost.Run()
I don't know what I did to cause this problem to appear. Also, everything compiles fine, with no errors; it just crashes as soon as execution tries to enter the method within which the _scanner.Run() call is located (e.g., the containing class' constructor executes just fine).
In researching this, I realized that I had never installed the System.ValueTuple NuGet package for the console app...which I thought was a requirement when using tuples in Net 4.6.2, although, if so, I don't know why the app used to run fine.
So I tried adding the package. No joy; same compile okay but crash on execution claiming the method can't be found.
Calling another method in that same Net Standard 2.0 library works fine. It's just the method that returns a tuple that causes the problem. I could work around this by returning an object rather than a tuple, but I'm curious as to what's causing the problem, and why it appeared after everything was working fine for so long.

Several more hours researching this problem online led me into discussions about problems associated with automatic binding redirects. Apparently, those can arise when you are mixing net standard and net traditional assemblies, which themselves depend upon other assemblies that may depend on different versions of other assemblies.
In my net traditional console app automatic redirect was set in the csproj file (old style format, first PropertyGroup):
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<ProjectGuid>{B64EE74D-F171-4438-8E7A-ACAE7B40C6C8}</ProjectGuid>
<OutputType>Exe</OutputType>
<RootNamespace>Olbert.CommunityScanner</RootNamespace>
<AssemblyName>CommunityScannerTopShelf</AssemblyName>
<TargetFrameworkVersion>v4.6.2</TargetFrameworkVersion>
<FileAlignment>512</FileAlignment>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<NuGetPackageImportStamp>
</NuGetPackageImportStamp>
</PropertyGroup>
Setting AutoGeneratedBindingRedirects to false solved the problem of the application crashing, and let me step into the Net Standard class library method that was returning a tuple.

I know it's a late answer, but if someone still have this problem and come by this thread, we solved it by adding multiple framework targets to the csproj file of the .net-standard project.
That way the compiler compiles a version for each framework and links the correct one.
<PropertyGroup>
<TargetFrameworks>net472;net5.0;netstandard2.0</TargetFrameworks>
</PropertyGroup>
PS: note that it's TargetFrameworkS, plural.